Update on SmartThings Classic Shutdown

That’s not good news. Smart Lighting has been very reliable and also benefits from running locally.


I was going to ask if Automations (assuming that’s what Brad meant by “custom automations” ran locally. I guess I have my answer :frowning:

In my experience custom automations are even more reliable and there is also work well underway to allow them to run locally.

1 Like

I don’t see any other option to mirror a device off another by custom automation. I’ve only seen this in Smartlighting. Button presses and recognizing any button beyond button 1 also doesn’t work outside of Smartlighting or Webcore. If it’s deprecated without a solution to these items that’s a pretty big problem for a lot of people.

1 Like

A little clunky, but mirroring works. And I can confirm the local execution is pretty awesome.

Thanks, I have a dimmer though, can it set the level of one based on the level of the other?

Yeah, that’s the plan as far as anyone can tell, kill off groovy smartapps without adequate replacements, because apparently groovy isn’t scalable and uses too much cloud computing resources.

Now, why you can’t just make the existing smartapps run locally on the hub, I don’t know. The thing never goes very high on cpu usage anyway. The fact that zwave and zigbee devices rely on the cloud also never made sense from the very beginning, the architecture of SmartThings in a way seems like it was designed by committee.

They’re rebuilding the entire infrastructure from the ground up when the obvious solution was already invented by another company a few years ago.

The other nonsensical part about all this is the push towards local execution of automations, etc. while simultaneously discontinuing hardware offerings and moving to a a cloud api-based hub optional business model. These two ideas seem to be mutually exclusive.

So my impression is they’re trying to do everything and support too many use cases simultaneously and therefore they accomplish nothing.

The lack of focus is because they have no CEO and are owned by a foreign company that has a reputation both in Korea and abroad of being completely out of touch with its customers.


Totally disagree. This is working MUCH better than the Official App automation. The official App. automation is unreliable and sometimes don’t execute. While Smart Lightning always works. Please don’t deprecate it… Let the users decide what’s good for them or not.
I have it since I had it in the classic app. But new users in Israel don’t…


Wait until you would hit the behaviour limit of the Automations. Those are a hell of a lot…

Otherwise, can you try to quickly turn on and off one of your switches physically if there any option for it. I am curious, that can you hit an infinite loop with it. (Because I cannot see any debounce option.)

1 Like

These control switches, so I have never tried to match a dimmer. I took a quick look and don’t see a way to match a dimming level, and didn’t see one. This may be a use case of the Rules API as opposed to the automation creator.

Ya, I’ve heard there is a limit on the number of rules, but havent hit it yet. It took 3 rules in Smarr Lighring, so it wasn’t terrible to change it to six rules within automations. I have a 2 year old daughter who tests all my automations, I can guarantee she has pressed the button more times in a row than I would ever find a need for, there must be something causing it to not loop on the back end.

It looks like a similar situation to the STHM status/control automations. The infinite loop is prevented because only state changes are getting propagated around.

1 Like

About a year ago some people were hitting race conditions by mirroring switches.

So, it seems like there is a light at the end of the tunnel for that issue.

@BrianRain, have you managed to solve that infinite loop issue? There is some hope when local automations will be released publicly it can be solved.

I haven’t tried a “two way” mirror lately. All I’m doing with smartlighting right now is to set one switch on/off (switch 1 mimics switch 2), including the level based on another, but last I tried to do it in reverse (switch 2 also mimics switch 1) it created a race condition where the light would rapidly switch on and off at times. In Homeassistant, I was able to do a template that compared the value of last changed and last updated between the switches to eliminate the race (last_updated>last_changed). Not sure how that would be possible on Smartthings.

The new automations part of the app doesn’t allow a set level to be duplicated to another switch, and even as pointed out above just to do simple on/off requires multiple automations, where the “mirror” in smartlighting was just one.

As for the rules API, based on the webcore community post here - webCoRE Optional Update v0.3.111.20210130 - Announcements - webCoRE Community Forum , it is still limited and only supports if/then, every, and sleep rules so doesn’t appear to be a solution for complex automations yet.

The bottom line is Smartlighting and Webcore are still essential to anything beyond a simple automation. A lot of their functions aren’t replicted in the existing automations of the new app or rules API. If these programs are phased out with no replication of the automations elsewhere, I’d have to move all automations to Home Assistant and Node red, and my Smartthings hub would just be a glorified Zwave/Zigbee stick only.


Just a reminder that if both switches are Zwave at the same security level and support association, you can use Z wave direct association, and that’s normally a good solution for mirroring light switches. It’s very fast, it’s very reliable.

The annoying thing is that at present smartthings is one of the only certified Zwave hubs which doesn’t offer a native UI method for creating associations. :rage: they have long had a design preference for hiding anything which was protocol-specific from their customers. But then not always offering an alternative protocol-agnostic method for doing the same thing.

The other issue with Z wave direct association is you can’t put any filter logic around it. Once it’s set up, it always happens. That can be an issue for motion triggered lighting, but it’s usually fine just for mirroring two light switches.

So I know that doesn’t always apply depending on the specific brand and model of the switches being used, but it will work for both on/off and dim level between 2 zwave switches of the same security level as long as they support Association. And since you yourself have recently updated the zwave tweaker to work with the new V3 app, it remains an option as long as we can still use custom Z wave DTHs. :sunglasses:

@jamesonrw @orangebucket @GSzabados

[BETA] Z-Wave Tweaker (See post #209 for new V3 app version)


That’s happened as well.

If you look at the comments, setLevel throws a value in and that triggers the light to turn on again.

The way how HA handles Automations that is amazing. Especially the run type Single, Restart, Queued, Parallel.

Otherwise has the SmartThings integration updated for the new SmartThings API or still uses the Groovy code?

Indeed. No Zwave commands out of the DHs, nor Zigbee commands.

1 Like

Its using the API, so will continue working after Groovy, and works very well. Its a great way to link Smartthings and Home-assistant together. SmartThings - Home Assistant

1 Like

A cloud connected one then…

1 Like

Yea, I’d have to say that it really doesn’t make a whole lot of sense to me to use a ST Cloud connection to Home Assistant for Zigbee and Z-Wave devices. I would much rather use an all local solution at that point, and not have to deal with multiple cloud hops just to control a local mesh network device.