I want to make a rule that tells me if a light gets turned on while I am at work. Using the RM4.0 app I intuitively thought I could set the trigger to be once per hour I am at work. I set the Action to notify me and I set 4 conditions on the action like work days, time between work hours, not present, and any light on.
It didn't work and just sends the notification every hour. Are the conditions not ANDs or does this just not work at all like I am thinking it should work.
Also, the RM documentation shows all kinds of programming logic as if there is a way to access the actual programming of rules, is that a thing? Even in the RM condition area there is a switch with some "%random%" wording and other % sign references as if there is custom programming that can be done but I don't see anywhere to do it. What am I missing?
This is a rule I use to check doors, but you could use similar logic for a light. It is much more complex, and it uses presence sensors. There are delays so it waits until we have really left the area (5 minute delay) and will cancel the rule if we are home or come back home.
You've received some excellent advice above (good community, isn't it? ). However, I thought I'd expand on this specifically. Hubitat is event-driven. When you're creating an automation, including a rule, the best approach to take is usually how you can respond to events. Doing things in a loop--checking something every so often when it's likely nothing has changed--is usually an inefficient (waste of hub resources) way to accomplish some goal. It's better to think of what event would happen (or what state would change) to cause you to then (maybe) want to do something.
In your case, as suggested, the bulb turning on or off (in RM, this is best done by "Switch" trigger with "changed") would be the best trigger. Again as suggested, you could check in your actions whether you're away or what the day/time is or whatever you want, then (maybe) do something if your conditions are met. (Technically, if you just want to be notified right when it turns on, you could use an "on" instead of "changed" trigger, but say you want to delay a minute or two, then...well, maybe you've seen some examples in the docs of cancellation by now.) Besides being more efficient, you'll also get notified faster--you don't have to want a random amount of time between 0 and 60 minutes (and wonder where in this interval your notification happened). It will happen whenever you want.
tl;dr My general advice is that if you're thinking of writing a never-ending loop every x minutes to check something, that is almost never the best approach.
Thanks for the info. I was just going to do an hourly trigger/check while I am at work. I agree that loops by the minute would be a waste of processing power. Mine is 10 checks per work day now so I could just do the first check to make sure I didn't leave anything on and then have a state change trigger active during the rest of that time to save resources. I made an "all lights" switch device that goes on if any of my lights are on and I run the check against that switch. Thanks!
Now that I'm playing with the Switch changed trigger it seems like that would execute this rule check every single time any light is switched any time, all the time. Sure I could constrain the conditional action to my time of interest but won't that run the rule far more than my 10 hourly checks since there will be far more light switches touched per day?
If you have a presence device, you could again use an event as a trigger instead of still looping (not sure if that's what you mean) or checking at a specific time (even if it's a special day when you are home, for example): when the presence sensor changes to "not present," run your actions (which again would be constrained by time range).
I don't think we have the ability to profile the performance and say for sure. Once per hour is certainly not the craziest interval. I can say that it is far more typical to see rules with a "changed" trigger as suggested. It will indeed wake the rule to run the actions, but if written as I suppose you'd write it, it would fail a conditional check and then pretty much be done, so not a big use of resources. Hubitat hasn't ever mentioned anything this specific to my knowledge, but on the similar SmartThings platform, it is generally recommended to keep the number of subscriptions on any device event to a minimum to ensure best performance, and it's reasonable to assume the same is true here. So, you're definitely not way off track, especially if you have a lot of automations that trigger based on this switch state. But otherwise, I'd consider this not likely to be a significant difference either way, and if it were me, I'd want the notification when I specify, not after a random delay.
This also raises the question: why are lights getting turned on when you aren't there? If they spontaneously turn on, that is something I'd recommend fixing instead. If you're not sure what app might be doing this, the "In use by" section on the device page will show you what apps use the device and may help. Or if you have a problem with the device, it may be worth investigating (Z-Wave or Zigbee mesh issues?). If lights aren't getting turned off when you leave (or even when you're home but not in that area), you may consider other options like adding motion sensors and turning lights off after a timeout--this is a very common automation scenario and easy to do with Hubitat. I don't want to distract from your actual question, but it does sound like this might be a workaround for a problem that could actually be solved. Just some other ideas to think about!
Wow that is much more complex than what I ended up with, and better. I will have to stare at that a while and try to understand the variables. To answer bertabcd1234, my lights shouldn't change while I am not home. I just wanted to make something and thought it would be fun to know if we left a light on. Then I figured it may as well repeat so id know if someone got into the house while I am gone, which I'd probably know from my existing Nest Cams anyway but what the heck.
If you break down the rule it is not really complex.
The first IF checks whether the current invocation of the rule is due to the switch turning on or off. That's what the Last Event Device conditions are checking.
The code following the first IF sets a local variable (Switch-Changed) every time the switch turns on or off.
The code following the ELSE runs only if the trigger was NOT a switch change, i.e. it was a periodic trigger. Here's where you send the message (but only if Switch-Changed is true).
BTW there is a bug in the rule -- it will send a switch-changed notification at 9:01 AM if there was any switch activity overnight. You will need to add a time-of-day check to exclude that first notification.