Hey guys so i just received this email from Smartthings.
Hello,
For those running local executable rules, please be advised of the following changes for SmartThings.
As of Friday, May 21, the (L) icon found next to a locally executable rule in the SmartThings app will no longer be displayed. This change is in preparation for a new indicator to be released soon along with the general release of locally executable rules.
As of Monday, May 24, locally executed rules will now require a hub version of 36.XX higher. All SmartThings 2015 (V2), 2018 (V3), Connect Home, and WiFi hubs currently have this firmware version available.
The removal of the app indicator is purely informational, all your locally executed rules will still be running locally provided your hub is on the correct firmware version.
This message was intended specifically for current hub firmware beta participants and is likely to cause confusion to those not in the beta.
Only the firmware beta users will have seen the (L) next to locally executing automations so only those users will be impacted by the removal of the (L). Mainly we did not want those users to think that their locally running automations are no longer doing so which is not true, they will continue to execute locally just without the indicator until a new indicator is released.
I just have to say that as a non-beta firmware user, I’m very patiently waiting for the day when Automations can run local on the public release firmware. Because my #1 issue (which I’ll admit doesn’t happen too often) is when the STHM is Armed, and the network is down. There is currently no way to Disarm the STHM since the STHM settings are only available in Automations.
So, I sure hope that the SmartThings programmers are doing everything they can to bring local execution of Automations to the public firmware SOON!
@Brad_ST, can you give us some hint what is this new indicator will be? I guess, it will be animated, because that fits most to the current awesome UX design, and the L must have been so boring…
Is there a special event scheduled by Samsung as well or will the news distributed only by the paid news agents to get the well earned publicity of the new indicator?
That’s very SAD news! I really need local execution access to the STHM for those times when the STHM is Armed and the SmartThings App can’t do anything because either my internet is down, or their SmartThings Cloud is down which has happened more often recently.
Right now, the only mitigation for the STHM being Armed with no way to Disarm it, is too unplug the Hub and loose all of the SmartThings Security & Smart Home capabilities altogether until whichever outage situation is resolved. I can easily do that when the STHM is in Armed Stay mode, but obviously cannot do that when it’s in Armed Away mode until I get inside.
I’d hate to think that at some point customers (maybe like me) might just choose to unplug it and never plug it back in.
Local arm/disarm of STHM from the app would require a pretty significant shift in the app architecture. Currently, the mobile app only communicates with the SmartThings cloud. There’s no control over your LAN. Hopefully some day there is some kind of local arm/disarm option, whether it’s with a hub connected device or the app.
What about a button controller that runs local, with the button press set to turn Off/On a Virtual Switch that runs local with the Virtual Switch as trigger to run an Automation that runs local to Arm/Disarm the STHM. Won’t that work?
As STHM runs in the cloud, the real problem is that if the internet fails, you don’t have STHM, it is as if were already disarmed.
To somewhat compensate for this problem, in addition to STHM, automations can be made with the smart lighting app, which is local, to activate the siren, which is also local, with some sensors in the house when the location mode is away.
If one day STHM goes to local execution … ??? and the internet fails, I think a local button can be used to deactivate or activate STHM.
Currently, I think you cannot use “virtual switch” to enable and disable STHM. It goes crazy and turns armed and disarmed continuously. Must be use “simulated switch”, that run cloud.
Today I tried again to change to virtual switch, in case the problem had been solved and it is still wrong.
Yep, I do have some Smart Lighting Routines setup to backup the STHM Response actions. But, I assumed that when the STHM is Armed, it would still set off the Response actions even when the network is down. However, from these responses it appears that is not the case so it’s a really good thing that I setup some Smart Lighting Routines as a backup for the STHM Response apparently.
I’m currently using a Virtual Switch that runs local (confirmed in the IDE) to trigger the Automations I have configured to Arm/Disarm the STHM which work without any issues.
Well, with virtual dimmer, to be exact, it doesn’t work for me. I have to use simulated dimmer.
I’ll try virtual switch tomorrow.
What dth do you use the original or one published by you in IDE?
That sounds like the pairs of Automations that were popular with ActionTiles, where the switches were used to provide both the status and the switching action for STHM. They were always flirting with being infinite loops.
When the Automations were implemented as Rules the only thing stopping them being infinite loops was lost. Switching to Simulated Switches, which do not behave the same, put it back in a different place.
So nothing was actually wrong, except for ST not announcing what they were doing, perhaps because it was not recognised that there could be breaking changes.
Another question about the Beta local Automation execution. Since it seems the STHM is essentially a SmartApp that doesn’t run local itself and can’t be controlled even with local Automations, can local Automation execution at least change the SmartThings Location Mode without being online?
