I've got some GE Enbrighten outdoor outlets that right now are turning on at Sunrise and Sunset. I'm guessing the rule construction in Rule Machine may be the cause, so I wanted to make sure I understand Predicates in Rule 5.0.
A Predicate surrounds an entire rule and prevents the evaluation of any Action based on a Trigger if the Predicate is false.
But the same effect CAN be achieved if the rule is simple using a trigger and conditional actions.
That is, in both cases, the bug zapper should only turn on if the deck lights turn on between sunrise and sunset. The difference is that in the first example, the trigger will not cause an evaluation of the rule, while in the second the trigger will always cause the rule to be evaluated but the switch will not be set on because the condition will evaluate to False.
The thing I'm fundamentally trying to debug is why, at sunrise and then later sunset, both my outdoor Enbrighten outlets turned on. I have a similar rule for the Flood Lights.
I'm going to try switching them over to an unconditioned trigger (i.e., no predicate) but with a conditional action and see if I get the result I want.
1 Like
I'm trying desperately to upload images of the rules I created to explain the 'Bug Zapper' reference above. But I keep getting told I can't embed media items. I'm guessing it's because I just opened/created my account here in the Community section that I can't.
There we go! Sorry for the spam, all. But now I can explain what I'm on about. Above is the Predicate-based variant of the Bug Zapper rule.
Then there's the standard conditional action version.
These should operate in a similar fashion, though the actual way they'll be executed will vary.
Here's the log of both outlets coming on at sunset.
And the rule construction for the Flood Lights, the other thing on the same type of Enbrighten outdoor outlet.
Thanks! Yeah, these are the two variants I have above. So at least I'm not off my rocker with my approach. 
I just need to figure out why they keep switching themselves on. I'm going to switch the Bug Zapper rule over to the standard conditional and leave the Flood Lights rule, then turn on all logging options for both and see what shows up come morning.
More or less, but it's important to note that when the predicate is false, the rule will not trigger at all. (This won't matter in your case but would affect things like "Wait" actions whose behavior is impacted by a trigger. It also allows the use of predicate conditions to capture specific state transitions, which again isn't something you appear to be trying to do.) To do this, a predicate condition has to create a subscription to the device in the predicate condition. When it becomes true, the trigger events are (re)suscribed to, and the opposite when false--perhaps for reasons of efficiency, though also because it shouldn't be necessary (they don't matter then). If any of the trigger events happen after the predicate condition becomes true (and before it becomes false again), then your actions will run as specified.
For a rule without a predicate condition, your rule actions run any time any trigger event fires. In your case, the rule without a predicate condition wraps the entire actions section in a conditional that says nothing should happen outside of that condition, so the outcome in either case should be identical. (These conditions are evaluated at the time of execution--no subscriptions to device events.)
If it's not, I suspect you might have a bit of a race going on in the rule with the predicate condition: say the time becomes sunset, making the predicate condition true and causing the rule to re-subscribe to the GE switch turning on. But then the GE switch, it sounds like, is also programmed to come on at sunset, and it's possible that this event happens before the rule is done re-subscribing to your triggers. (If you repeat these events enough times, you may find that sometimes these happen in the other order and your rule may actually trigger, though if the events are nearly simultaneous, there are no guarantees.)
I would probably use the second variation of your rule; that way, you don't have to worry about the above. In general, I'd probably recommend that most people stick to "traditional" conditionals unless there's a reason they truly need a predicate. In most cases, you could write rules with identical outcomes either way, so it doesn't really matter except from a "purist" point of view. 
But if my description of the sequence of events above accurately describes your situation, I'd say you've run into a case where it does matter.
3 Likes
Funny thing here, I actually don't have any kind of schedule or event controlling the Deck Lights dimmer switch. It should only operate by hand. So that's what's perplexing me so much: there's some phantom event triggering the action. It should be the case, as you note, that when the Predicate becomes true, it then re-subscribes to the trigger event on the switch. Then when I activate the switch by hand, the rule is evaluated and the light turns on. What sort of seems to be happening is that the changing state of the Predicate itself is being treated as a trigger.
I can absolutely use a standard conditional here, but I like the idea of a Predicate preventing needless rule evaluation. It struck me as more efficient. So I figured I'd see if I can debug this first.
Oddly, the rules using Predicates absolutely still seem to function properly in terms of the effects, I want. It's just that I'm also getting weird extraneous activations of the Bug Zapper and Flood Lights.
Nice explanation there.
Where I see the value of predicates is to (possibly more cleanly) act like Private Boolean without having to use PB. I don't think it was meant to supersede conditionals at all. And I have seen quite a few posts trying to do so.
I think there is a place for each, and I think predicates are going to take some good examples either here in the community and/or in documentation to tell when they may be better or worse than a conditional.
1 Like
Nothing says that there isn't a bug with Rule 5. I would turn on all logging, and see if you can get a good (working) log VS one that has those extra activations.
OK, I see that this is a question--why it's happening--not something you wanted. The rule certainly isn't a bad guess, but if there is a bug with the way that works, I haven't seen it documented yet. I suppose it would be easy to test with a virtual switch.
A more likely guess: some other app is using this device and turning it on at this time, triggering the rule. Try checking the "in use by" section on the device page, and see if anything looks like it might be the cause. If your event descriptions are accurate, it says "digital," which means it's coming from the hub (not "physical," from the switch), but I suppose that was never really in question. You might also want to verify that you're using the best driver for this device by cross-referencing Hubitat's Compatible Device List, which lists drivers for (usually) specific model numbers. Old Z-Wave switches were bad at reporting status back to the hub, but if you have polling or something enabled (a good think to ask!) or the driver does something weird, I could see it going bonkers and maybe generating phantom events...
1 Like
I realized, I should explain what I'm after:
I have an Enbrighten Dimmer Switch hooked up to the lights on my beck deck. Then, through Hubitat, I also have it controlling two Enbrighten Outdoor Outlets. To one outlet is connected a Bug Zapper. To another is connected a set of Flood Lights for the back yard.
I want the following rules to hold:
- When I turn the Deck Lights on between Sunset and Sunrise, I want the Bug Zapper to come on, too.
- If the Deck Lights are already on when Sunset comes around, I want the Bug Zapper to turn on.
- If the Deck Lights switch is Double Tapped up between Sunset and Sunrise, turn on the Flood Lights.
- If the Deck Lights switch is Double Tapped down at any time, turn off the Flood Lights.
So the RM images I've pasted above are rules 1 and 3 from the list, here. Rule 2 looks like the following:
I don't have any other events or triggers tasked on the Deck Lights Dimmer.
Here's the Dimmer's subscription set.
The Bug Zapper.
The Flood Lights.
OK, got a report in the log this morning. It does appear that the Predicate Condition itself got evaluated as a trigger.
app:64 is the "Turn Flood Lights on" instance of the Rule 5.0 app. The actual trigger should be a button and not the time-change. But it appears the whole thing gets evaluated when the state of the Predicate Condition changes values and, rather than altering the subscription to the trigger, it actually runs the action.
Interesting. I created a rule with a predicate condition of "time is between sunset and sunrise" to test something closer to yours, but will have to wait until sunset to see what it does. (This is my test hub...so I'll think about just changing my location to see if I can speed up that process. Maybe.) In the meantime I used a specific time to see if I could replicate the behavior:
I created this a few minutes before 12:23 PM (so my predicate condition was false), then waited for 12:23 PM to see if anything happened. As expected, nothing did. (I didn't really need a trigger event here but assumed it was good to have one to get something closer to what you have; this event should never really happen on my hub.)
I will wait to see what my sunset/sunrise rule does in case there is something unusual about that particular case. If it's your "Turn on flood lights" rule that is doing this, that seems particularly odd to me because you do not have a "certain time" trigger in that rule.
My "sunrise to sunset" predicate rule:
...did not do any actions at sunset either, as I expected--at least when I changed my location to something slightly north of Antarctica to get a sunset around now. (And yes, I went in and hit "Done" in the rule afterwards, but since it subscribes to the actual sunrise/sunset events and not an offeset, it should be good either way.)
Confusingly, it did register this interesting log event:
I say "confusing" because at 12:42 (sunset), the predicate, in fact, became true, not false (and that is correctly reflected on the rule page if I refresh it now). Seems like the log is saying the opposite...
Anyway, I'm putting my hub back to my regular location and whatnot to see if anything happens tonight. Otherwise, part of me suspects there is still some app/rule turning on this device--but your logs do look suspicious if it says that your "Turn on flood lights" rule is triggering at a specific time, since it definitely shouldn't be. If you click the "info" text in that log entry, it will take you to the app (rule) in question. Can you verify that it's the same one you suspect (that shouldn't be doing it)?
This will happen if there is a trigger for one of the conditions in the Predicate Conditions, but not for the Predicate Conditions themselves otherwise. Please show the rule for which you think this happened, app 64.
app:64 is the Turn on Flood Lights rule
Though since this morning, I've modified it to use a standard conditional action. I can return it to a Predicate for further testing, though.
Would you please post the App Status page for that app. This is linked by the gear icon on the app page, or to the left of the app name in the Apps list. I need to see the whole thing, and that may take a few screenshots.
Never mind. I can see the bug...
This will be fixed in the next hotfix release. Thanks for bringing it to my attention. As far as I can tell, this only affected a Between Two Times for sunrise or sunset.
7 Likes
@bravenel, I ran into the same problem -- predicate based on sunrise & sunset also treated as a trigger.
Do I obtain hotfixes the same way or do any other release, or is it a separate process?
Thanks!
marc
This was fixed in 2.2.8.156. What release are you on?
I'm not sure you have "the same problem". Could you show the rule in question?
I am on 2.2.8.156.
I'll try to reproduce it again to make sure that I am not mistaken about what I saw.
Marc
