Update on SmartThings Classic Shutdown

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.

3 Likes

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)

3 Likes

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.

3 Likes

Yes it is cloud dependent, and one might wonder why would you do this in a local home assistant instance? For me, I have a very stable internet provider. I consider Smartthings to be reliable with few outages (As a former Wink user my bar is lower then others here), and this is a hobby with no critical uses. Worse case scenario is I have to get up and flick a switch if something doesn’t work. So, cloud dependency isn’t as much a concern for me as it probably is for others. I also bought the Smartthings hub first though before installing Home Assistant, so I might as well put it to use for now. Anyone else reading this on here probably already owns a Smartthings hub too.

As far as using a cloud hub with a local Home Assistant server, The zigbee and zwave integrations historically in Home Assistant have not been great using local zwave/zigbee sticks. The cost to buy both a zigbee and zwave stick is comparable to buying a Smartthings hub. So, it could make sense (he did it and explains why in this video https://youtu.be/BfGz4RJMl_Q )

The equation could quickly shift though with the new recent zwavejs2mqtt improving local zwave Integration in Home Assistant, and what happens with the future of custom code here on Smartthings.

Getting back to this thread, the death of the classic app and loss of functionality it had is what drove me to install Home Assistant in the first place. I’m just in a wait and see on what Smartthings does next before doing anything else

3 Likes

I just checked quickly, maybe if you are upgrading from a v1 Hub to a v3 with the extra discount coupon.

An Aeotec Gen5 Zwave stick plus a CC2531 dongle with printed cover and antenna, roughly 65 EURO.

(The version of the Aeotec stick, I haven’t checked it, might be the early generation which is not compatible with a RPi4 - funny, the USB standard was not followed by Aeotec. The Zigbee stick is only CC2531, not a CC2652 or ConBee, they would add an extra 20 EURO, plus shipping.)

I should say the prices were comparable before the Aetotec deal, at least in the US where a hub was $60-70 for most of last year. Maybe they will be comparable again after the supply issues iron out and hopefully prices comes down.

I don’t understand why the Aeotec hub is so much more expensive in Europe though.

Price likely includes EU vat

I am guessing the Aeotec hub will be priced at ~$120 USD, and will not see heavy discounts. SmartThings sold the hardware as a means of getting user data…that was and still is their main product. Aeotec, on the other hand, does not get access to user data, and thus needs to make a profit on every piece of hardware that they sell. Thus, I believe they will keep the prices much closer to full retail, as they have always done with their own hardware.

2 Likes

I ended up moving all my automations to Node Red based on the statement Smart Lighting was going away at some point and webcore having an uncertain future. I tested some devices by moving them locally to zigbee2mqtt and zwavejs2mqtt off of Smartthings using USB sticks I already had. After comparing the two ways myself (local connection vs cloud Smartthings connection) I was shocked at how much noticeably faster it was to use the USB sticks. I have to admit now you were right @ogiewon , it really doesn’t make sense to run automations locally with devices running through the Smartthings cloud versus a local zigbee/zstick. It might have in the past but with the nice UI interface for zwave control in zwavejs2mqtt, it doesn’t anymore. It was a pain to setup, but once I added the zwave devices to zwavejs they just worked. Parameters and associations were just instantly recognized automatically with no complex Groovy custom device handler necessary. If you’re going to go through the trouble to setup a local server you might as well just move everything over locally, which is what I ended up doing.

If Smartthings solution to ending Groovy smartapps is “host the code yourself”, I’m afraid that will leave them with a lot of people running to the alternatives. A hybrid option is both complicated to setup and not as fast. I do think Smartthings is still much easier to use and has a place, especially for someone starting out and not really needing custom code. But if you want to do a lot more, and have the time to invest, there are definitely better alternatives.

4 Likes

Now that you have that setup, i’d be curious to see z-wave/zigbee NodeRed local vs Smart Things Automation local (once its out of beta).

4 Likes

May sound like a daft question, but do you need to be enrolled in Beta firmwares to get local automations?

I believe the local stuff started appearing in 35.x, so my hub shows up at 36.x but any automation I create in the new app with all local devices i.e. local button and local outlet I don’t get the ‘L’ local indicator on the automation

yes you do, but it isn’t directly tied to the firmware. it’s apparently enabled by a setting in the SmartThings cloud

2 Likes