Thanks for the work in developing this. This is a very useful tool. Yesterday, I used the create a new virtual device feature, which appears to have worked fine, but I’ve got one question: I created a color adjustable dimmer switch. In the IDE, it shows up as place holder, which make sense. I was expecting a new Edge driver, but still only have three installed (zigbee switch, z-wave switch, and z wave button). Is it in one of these? When I clicked the virtual device, the normal edge driver dialog does not show up. Is this device done differently than physical devices? Thanks
Those virtual devices do not have a “driver” - they are supported through the platform itself. So yes, they are a bit unique in that respect.
Not exactly sure what you mean by this; you certainly should be able to get to a Controls screen like any other device. Be aware that these virtual devices are somewhat limited in functionality, but if they meet your needs, great. Alternatively, if you are looking for expanded capabilities in virtual devices, you might be interested in my vEdge driver.
It worked well enough for my kludge to replicate the color coordinator.
Is there some magic ingredient required to connect? I get an HTTP 403 error when trying to connect using my SmartThings Personal Access Token.
Check your token’s scopes. Make sure it has at least read authority for just about everything- at least for locations and devices.
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.
2 Likes
NO, already asked, it can’t be done because there is no API command that does it.
1 Like
Thanks for the reply. That’s unfortunate, could really use a feature like that for remote control of your hub(s).
1 Like
When it is an available API endpoint I will surely add it!
7 Likes
There’s a thread specifically on Life After the IDE: Life after the IDE: Questions and Answers - Wiki / How-To - SmartThings Community
1 Like
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.
1 Like
@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.
FAQ: I have no idea what Edge is. Is that a new developer tool? (2022)
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.
2 Likes
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.
1 Like
@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.
1 Like