Weird automation behavior

I am having a heck of a time with some Automation behavior that I can’t figure out.

I had reported yesterday, that it seems local execution of Automations does not recognize smoke or water sensors as an IF, while the cloud execution does:

Now I’m noticing that local execution of motion sensors appears to have a different response to the cloud execution…:

I have two Automations based upon an IF motion is detected on a specific motion sensor.

The locally executed Automation triggers when motion is both detected AND STOPS from the motion sensor.

The cloud-executed Automation triggers when motion is detected from the motion sensor only.

The IF conditions of the two are identical.

Any ideas?

Always good to provide as many details as possible such as which devices for the water/smoke and include brand/model. Perhaps attach screenshots of the two automations (local and cloud).

Which hub?

v2 hub

I will share the two Automations I have for the motion sensor to see if that gives any insight.

See next reply. Thanks.

Which devices and integrations are being used?

I’d be particularly watching out for custom device handlers incorrectly set to run locally.

See two automations.

One called “ALARM AWAY”. This one is simply a notification and runs fully in the cloud based on the indicator in the app.

The other is called “ALARM AWAY actions”. This one manipulates multiple divorces. This one runs fully locally based on the indicator in the app.

Both run when the conditions have been met (ie, AWAY switch is on and motion is detected on either of the two motion sensors).

“ALARM AWAY actions” also runs when the AWAY switch is on and motion stops on one of the motion sensors. This is the unexpected behavior. Nowhere do I have an IF for motion stopping.

In the example above, all are “stock” devices and handlers (z-wave motion sensors, z-wave/zigbee outlets, z-wave siren). The only virtual are a couple of virtual switches using the “stock” virtual switch from the IDE.

For my issue with the smoke and water sensors - both are Monoprice contact sensors repurposed. They do have slightly customized handlers that are operating locally. It’s just strange that their cloud execution works just fine but their local execution will not.

Think I figured it out, but still not clear why cloud and local are different or if it’s fixable.

My automation is based on an OR condition (“any condition below is met”) for two motion sensors. If the baseline state is both ON (motion detected) and one turns OFF (no motion), the local Automation makes the IF (both ON changes to one ON, one OFF) and executes. The cloud automation does not make the IF and never executes.

I would have imagined it working like the cloud automation - that unless either of the two motion sensors changes to ON, the automation would not execute. This is the way I’ve configured most of my Webcore pistons, and I guess I got used to the functionality of Webcore. Or at least be consistent between the cloud and local execution.

I’ve been able to reproduce this with Automations using other devices. Always happens with two conditions configured as “OR” with two different devices.

This doesn’t explain my experience with the water and smoke sensors, though - I believe that’s something different, but again inconsistency between cloud and local execution.

That could well be the issue, though it depends on what is ‘slightly customized’ about them. Local handlers are native to the firmware. Nothing you add to a custom handler changes the code that actually runs when the device is running locally. You can twiddle with the metadata but that is about it.

They were the z-wave door/window sensor modified to replace open/closed with smoke/clear.

OK, so that is only going to work when the driver is actually running in the cloud and not locally.

1 Like

OK, so the Automations for water and smoke I “forced” in to the cloud by adding a notification to the other actions in the execution list.

Still not clear why my local vs. cloud execution of multiple device conditions is behaving differently.

I’d imagine it working more like webCoRE without an explicit trigger, evaluating the conditions any time a motion event is received. I’d expect it to work the same for cloud and local though.

Any customization of a Groovy DTH will then require it to run in the cloud, although the IDE may allow you to leave it marked as still local. it sounds like that’s what you did.

(Custom Edge Drivers can run local, which is one of the big improvements of the new platform.)

Anyway, there’s a warning in the IDE when you go to edit a DTH,

Changing to a custom DTH may impact the execution location (cloud or local) of the DTH and cause certain rules to not behave as expected. Please proceed with caution.

Based on previous reports in the forum, I think once you have a custom DTH marked as operating local, lots of weird unpredictable stuff can happen.

So I think as far as troubleshooting, the first thing you need to do is make sure all the customized DTHs are marked for cloud execution. :thinking:

1 Like

So I resolved my issues with the smoke and water Automations by modifying the DTH further to have it be ‘false’ for running and executing locally.

Still can’t understand why the subject Automations are not working as expected when run locally. There are no custom DTHs involved in the motion sensors or devices controlled.

Feels like the behavior of conditions is different between cloud and local. OR the specific behavior of “when any condition below is met” (the OR operator) is different between cloud and local. That’s my conclusion anyway. I believe the condition evaluation should be happening as it is when the execution is cloud based.