Thank you. I thought that I had created a token with authorisation to do everything - i.e. all boxes ticked. I tried again and this time it worked. I assume that something was missing the first time.
Hi @TAustin. I’m not sure if this has already been asked, but is it possible to add a way for your web api browser to reboot a hub that is being looked at? That would be a nice feature to have to take the place of that function from the IDE once it’s shut down completely. I had to use the reboot utility in the IDE tonight to help solve tonight’s z-wave issue with the hub update push.
NO, already asked, it can’t be done because there is no API command that does it.
Thanks for the reply. That’s unfortunate, could really use a feature like that for remote control of your hub(s).
When it is an available API endpoint I will surely add it!
There’s a thread specifically on Life After the IDE: Life after the IDE: Questions and Answers - Wiki / How-To - SmartThings Community
Hi TAustin - thank you for the helpful work on your API+ tool… Do you know if ZWave devices expose their firmware version in the api and is that something is available in your tool? If so, where do we find it. In the IDE ZWave devices running on DTH showed the firmware in the raw description
|Data||* networkSecurityLevel: ZWAVE_S2_AUTHENTICATED|
|Raw Description||zw:Ss2a type:0701 mfr:027A prod:7000 model:E001 ver:1.30 zwv:7.13 lib:03|
As I mentioned in the other topic, @philh30 has a driver called the Z-Wave Explorer that exposes Z-Wave information not generally found in other drivers for normal use. I loaded it for one of my GE Dimmer Switches and it does show the firmware version. Just a note, if the device is used in a Routine, it will be deleted from that Routine since the Explorer driver doesn’t have all the capabilities and presentations defined like in the device specific drivers.
@TAustin, I see that the Z-Wave Explorer driver exposes z-wave route. Does that mean that the API Browser+ could do the same?
No, there is currently no method to get the Z-Wave info from the device driver on your hub into the cloud to be retrieved via the APIs nor is there an API defined to retrieve it.
@JDRoberts Somehow my post disappeared and also I can’t see your reply anymore (unfortunately I hadn’t been able to read it until the end)
SmartThings is still largely a cloudbased system.
For one thing, the SmartThings app always requires the cloud, even if it’s connected to the same Wi-Fi as your hub. They didn’t have to design it that way, but they did.
Here’s the official schematic:
On top of that, smartthings engineers have posted in this forum that the system does expect the hub to be connected to the Internet most of the time. Otherwise, some things won’t work at all (like scenes) and somethings will stop working overtime, probably, including updating “sunrise“ and “sunset.“
And any devices which require connecting to their own cloud still require that.
Edge drivers are designed to give the system more local processing, not solely local processing. The hope is that that will in turn mean faster, more reliable processing, but we will have to wait and see on that one.
Almost all Samsung smart entertainment devices, including the smart television models, do require the cloud. I don’t know if that’s true for that specific soundbar model or not.
You can read more details about how edge drivers work in the community FAQ.
Anyway, any more discussion on this,p would probably get pretty far off topic for this thread, and even more so since the original post isn’t here anymore. So why don’t you start a new topic if you still have edge questions after reading the FAQ.
Thank you @JDRoberts ! I also found this other approach for Samsung sound devices: Samsung WAM - Implementations . Maybe in my case this is then the better approach I should look into first since this soundbar will be the only Samsung device I’ll be dealing with. Otherwise I may then stick with the cloud based integration in Home Assistant if it’s too complicated and/or too unrealistic to achieve my goal.
@TAustin I just noticed that when looking at Devices the total of all devices when filtering by Device Type (in my case 426) does not match the count when no filter is applied (430). I will try and eyeball where the difference it but it’s a big list. Just though I’d let you know in the meantime (and maybe you even know why that might happen/what’s missing in filters).
Thanks for bringing it to my attention. I’ll have a look at it and let me know if you learn anything more.
It might perhaps be the BLE_D2D used for SmartTags as that isn’t in the filter list.
I don’t have any SmartTags.
Possibly: if I recall there were a couple types I didn’t include in the filter options thinking they were obsolete, but that might have been a bad idea…
What about EDGE_CHILD, ENDPOINT_APP or MQTT?
I don’t believe so.
I am still scanning through trying to find the culprits.
I have pulled the non-filtered list in to Excel and confirmed that count is correct.