Routines and smartapps no longer operating on Leviton/Hue combo

OK, this is a weird one.

There are two devices involved here:

  • a Leviton wifi light switch/dimmer
  • a Philips Hue Edison bulb

For 2 years, I have linked these two devices together using the “smart lighting” smartapp in the smartthings environment to mirror the behavior of the Hue light to the command from the wifi switch. It has worked flawlessly.

About 3-4 weeks ago, the Hue light stopped responding to the mirroring behavior. In fact, the creation of either a routine (formerly “automation”) or a webcore piston fails to control the Hue from the wifi switch behavior.

Now this is where it gets weirder:

  • both the wifi switch and the Hue bulb work with their own, respective apps
  • both the wifi switch and the Hue bulb can be 100% controlled from the smartthings app directly
  • both the wifi switch and the Hue bulb can be controlled from Google Home via GH’s connection to smartthings
  • other Hue lights in my environment remain controllable from smartthings smartapps, routines, scenes and webcore

I have tried many things and cannot get this mirror effect to occur again.suggestions?

Question… when you control these devices through their apps, is the correct status displayed in the ST app? For example, if you turn on the Leviton wifi switch, does the ST app show it as turned on… and same when you turn it off?

I should also note for the record that both Smart Lighting and webcore will be phased out when groovy is shut down so you may want to start planning a move to Routines.

Thanks for the warning about smart lighting, but was surprised to find webcore is being shut down. I’d happily move to routines, but they don’t mirror behavior well yet.

Anyway, to answer your question: yes the state in the smartthings app changes to reflect the change of the device from it’s native application

This was an incorrect response. See my second reply

Actually, I want to correct what I wrote. Your guess is correct @jkp - flipping the physical Leviton switch does not change it’s state in the smartthings app.

If I use the smarthings app to change the state of the Leviton device, then the light state changes, the smartthings app state changes and the webcore routine fires correctly and activates the other light appropriately.

So the Leviton linked service is not reporting it’s state change to smartthings. Suggestions?

Ok, just to conclude. Once @jkp alerted me to the idea that it was the Leviton - smartthings linkage, I dug around a bit.

I signed out of the Leviton app, disconnected the linked service from smartthings, signed back into Leviton app, then relinked the service.

All is now right with the world. Thanks folks.

1 Like

For what it’s worth, which may not be much, I have found with a couple of different cloud linked services now that when there is an update on the manufacturer side things just go wonky on the smartthings side until I’ve signed out and signed in again. :thinking:

1 Like

That is apparently the case here. The Leviton side updated around the same time the routines stopped working.

Pretty annoying.

I’m curious about @jkp 's comment that webcore is going away. Do we know if that’s true? It seems to be actively being worked on, and I get responses from the author when I reach out to him. Also, since webcore is now part of smartthings business-wise , it seems like it has a secure future. Is that not the case?

It’s true because the Samsung-hosted free Groovy cloud is going away. And that’s where webcore runs for smartthings.

All the custom Groovy code that runs on the old platform, including DTH‘s and smartapps, will have the same issue.

It seems likely that Webcore will continue to run for Hubitat and that’s why you continue to see work being done on it, because that version runs locally and doesn’t use the Samsung cloud.

Smartthings staff have said in the past that they believe that by the time it goes away the combination of routines in the smartthings app and the rules API will have comparable functionality, but we won’t know for sure until it happens.

They’ve said stuff like that before on other major transitions and it didn’t happen. :thinking:

1 Like

Be careful who you listen to :slight_smile:

Chances are high that the current version of webCoRE for ST will cease when groovy is shut down on the ST platform UNLESS the community steps in and modifies the code to work with the new Rules API. No one has stepped up to do that or no one has mentioned they will take on the task. This would be a major rewrite of the code and most likely require users to redo all their pistons as I doubt a migration tool would be available.

As for webcore being actively worked on… not really. There have been no updates in almost a year. There is active development on the branch of webcore for another platform.

1 Like

And just for clarity. It’s not that “Groovy” will be shut down, it’s that the “free Samsung-hosted Groovy cloud” will be shut down.

Groovy is an independent programming language not owned by Samsung. (It had a complex history, but now resides under the Apache software foundation, so open source nonprofit.)

So there will continue to be groovy projects for other platforms. Again, like Hubitat.

Well, actively worked on as I have been in touch with the author and he made a few adjustments to the dashboard caching based on some issues I was dealing with… so I know he’s still working on it, and he’s on Samsung’s payroll, last I knew.

Yup, I understood that.

I believe he left in November, check Linked In.

Ahhh…interesting… my conversation with him was in October.

1 Like