Help with local variable guard on reboot


Background (maybe too much but oh well):

  • I have a bunch of security cameras that are well tuned with motion zones that fire when stuff move towards to house (Blue Iris).
  • I have a dusk lights that are set to 10% at dark.
  • I have other inside+outside lights that could be used to scare people off.

I would like the dusk lights to go to 100% and the scare lights to go on when any of the cameras determine approaching motion, stay on while there is continual motion, and stay on for another 5 mins after motion stops. Much like "Hey... House here... I see you. Behave."

I would the setup to work even if I reboot the hub.

The last one is the kicker since my dusk lights don't seem to work properly after a reboot, and my RM4 rule below gets stuck since my rule guard gets stuck in running=true and thus bails on line 1 and never recovers. I need this guard or something like it (cancelable?) since otherwise I get multiple running RM logics running in parallel every time motion is detected.

Any ideas?

Could you not create another rule that triggers on reboot to set the variable to false so that it is able to run again?

Have you tested this for sure? Normally you'll only get a trigger that matches if there is actually a state change (which, after motion becomes active, there would normally not be until after it becomes inactive, which you are doing a "Wait" for and should be good with). I see you're using ZMC, however, so I'm not sure if that forces a state change in every change as a result of "member" sensors. Even if it did, the only potentially undesirable thing I could see is that it would do your "Log" action every time, even if the lights were already on (turning on a light that is already on is generally harmless).

Again, you know more about your specific situation, of course, but I just wanted to make sure you aren't trying to solve a problem that doesn't exist.

Well hmmm testing now. This thing has evolved over time and it actually looks like ZMC has a timeout I can use instead of doing my own. Good reality check. Will see if I can just do without the local variable now, thanks!

Didn't think you could have two apps accessing the same variable. If so, that could be a solution too, thanks!

I don't see a "timeout" in your rule above (that would include something like a "Delay 0:01:00 (cancelable)" after your "Wait for event: mZone inactive" action and a cancellation towards the top of your rule), so I'm not sure if you meant that or if that you were manually manipulating the ZMC device somehow (which you can't do directly since it doesn't have commands, but, again, it's not clear to me what you meant). As-is, your rule will dim the lights back down immediately when the ZMC sensor goes inactive.

Either way should work--doing all the "timeout" period you want in the ZMC app, or using the ZMC sensor with low or no timeout and then doing the "timeout" work in the rule. I don't see a reason to prefer one over the other unless you're using the sensor for other things and those would influence your preferences too.

Good luck!