Hoping I look like a newbie and this is a simple fix, but two days ago I started getting a lot of error messages for sending commands to devices — lights, mainly. This only applies to SharpTools rules; SmartThings rules or rules in Alexa work, even for the same devices which report failure in SharpTools.
A couple of examples are attached. Note that these rules all worked for months without error.
Any ideas or suggestions?
Is it for
setLevel() commands? And are they TP-Link Kasa or Globe Electric devices?
@Pierre_Berger reported a similar issue and I’m actively trying to supply the SmartThings engineering team with supporting data to help them troubleshoot. Do you have a ticket open with SmartThings?
Agree, it looks like to be the same problem than the one I have with the SetLevel command and my TpLink and Globe dimmer Switch!
Wow, sure enough! TP Link wifi bulbs and also Lutron Caseta in-wall dimmers.
I don’t have a ticket open with SmartThings. Is that something I should do?
Thanks for the additional details. I’ve shared them with the SmartThings team as well.
I’m waiting on confirmation if they need tickets created or if the details I’ve passed on so far are sufficient.
Another device to add to the list is Zooz ZEN 77 in-wall paddle dimmers…
Thanks for the help, @josh ! Let me know how I can assist.
Just circling back as this one is surprising to me. All the devices reported so far seem to be ones that are using cloud-to-cloud connections. I would have thought the Zooz ZEN77 would be using a Groovy Device Handler though – are you by change using Edge Drivers for these or some other way of connecting them to SmartThings?
Additional Details / Backstory (tap to expand)
SmartThings is basically running two platforms simultaneously right now – the next generation platform (Cloud-to-Cloud, Edge) and the Groovy platform. There’s a shim layer between these two platforms so events/commands from Groovy make their way to the next-gen platform and vice-a-versa with events/commands/metadata.
Up until now, it’s been a really seamless shim and I don’t think most people even realized it existed. In the Groovy platform, you send a command by specifying the device ID and the command… in the next-gen platform you specify the device ID and command, but you also have to specify the capability and component. The shim layer takes care of inferring which capability a command is associated with so commands from Groovy can be effectively forwarded on to the next-gen platform.
I suspect that something with this shim layer or something about going between the two layers is where the issue is. We’ll have to wait for analysis from SmartThings engineering to confirm though.