I had found that when doing the ‘turn off after motion’, it would migrate the rules to cloud based. To combat this, I have a smart lighting rule to turn the light on and then a separate webCoRE rule to turn the light off when motion stops, after X minutes. This leaves the on action as local and instant.
Latency or delays when turning the light off if there is no motion should not be a concern, therefore, while clunky, it can live in a separate rule/smartapp.
I was trying to keep my lights running local, and thought I was doing well based on ide labels. I don’t want to use webcore for basic things like turn a light off after x minutes. Looks like turning on and off after x minutes in one instance, does run local, so I’ll be busy redoing most of my Smart Lighting instances.
While I agree it should just work and we shouldn’t be forced to do work-arounds, especially those that may be unreliable; and I understand you found a potential fix…I’m still not sure why a cloud-based ‘off’ is a serious problem?
In that scenario (cloud based ‘light off’ statement), unless you’re running Metal Halide lights in your house instead of LEDs, the ‘consequence’ of the lights not automatically turning off are pretty…non-existent? In the end, sure it raises your electric bill slightly, but I wouldn’t consider it being anywhere near the inconvenience of you trying to have lights turn on with motion and that failing. To each their own, however.
I wasn’t even thinking about increase in electric bill, just a slight decrease in convenience. Your lights come on but you have to manually turn them off (in absence of internet). In my home people don’t know what those white things on the wall are, let alone that they have to touch them to turn the lights off It was disappointing to find out that the label in ide is not accurate, or otherwise I would not have used separate instances to turn OFF the lights. I could have set them up in one instance from the beginning, x years ago
In order for a device to be locally controlled through the smart lighting app, the device also has to have a local DTH. Therefore, you could still use the ST app and click the ‘off’ button for the light in the app. No need to manually visit the switch at all!
Either way, glad you found a solution! I may go play with mine again to see if I have similar luck.
That’s not what “local operation” means in a smartthings context.
If your Internet is out, the app will not work to control anything. Everything that is done through the app is done through the cloud, including just toggling a device or notifications. Even if your phone is on the same local Wi-Fi as your hub.
What local operation means is that the ZIgbee and zwave and a few LAN devices like the hue bridge Can still communicate with the hub. And the hub can run smartlighting automations from the official smart lighting feature (only those, and a few bits of smart home monitor) without having to talk to the cloud.
So basically if you have a zigbee motion sensor set up to trigger a Z wave light switch and everything is eligible to run locally and you created the automation in the official smart lights feature, then that will still work.
But not app control.
This is easy to test. Just unplug your ethernet and see what happens with the app.
Manual, on-demand control of a device or SmartApp through the SmartThings mobile app always requires an internet connection to the cloud and cannot be performed locally.
So your statement is not true! You cannot use the app without internet. What I am highlighting and warning others about, is that even IF the device is local and the Smart Lighting is listed as running local (in ide), is disqualified from “local processing” because the timer that runs after the inactive motion event, is running in the cloud, so might as well use webcore and not the clunky Smart Lighting app
@HA_fanatic/@JDRoberts wow - learn something new every day. I had no idea that the app, in it’s entirety, is considered cloud based. Now I do have a slightly different opinion to smartthings as a whole! And to think all these years I’ve been living under false assumptions lol.
@HA_fanatic - I agree with the webcore piece, as I said earlier. I use SL for ON actions only. WC does all my off statements.
@HA_fanatic I finally got around to trying this. I have a Smart Lighting automation set up to turn on a light when motion is detected and turn off 5 minutes after motion stops. I unplugged the Ethernet cable and walked into the room. The light turned on as I expected and turned off 5 minutes later. So Smart Lightning with timers is fully local.
Have you tried setting one up only for motion inactive event? Like when motion stops, wait 5 min then turn off? That was the instance that failed on me during my outage (see picture in first post). However, I have since tried to replicate what happened during the outage and things worked local as expected. So not sure what happened during the outage and didn’t have the time to further investigate.
“On with motion and then off”, is confirmed to run local (if your devices are also local). Just the “when motion stops turn off in 5 min” is listed as “beta”/non local in the Classic app, however, I have tested previously and was actually running local despite the Classic app’s label. That appeared to have changed, or at least something happened during my internet outage and lights didn’t turn off as expected, which led to my conclusion that my instance is no longer local.
@HA_fanatic If I create a new automation with motion ‘stops’ as the trigger, I do see the warning in the new app. I’m not home to try it but I will as soon as I get a chance to see if it’s also working.