I like the predicate idea - seems any rule that starts with if and has no else - that would be a predicate condition... so I tried it with my front door motion rule... and it failed to fire.
Interestingly, when I open the rule, the predicate condition says TRUE, but the title still shows false - weird.
Are you on the latest version? I think one of the early releases of 2.2.8 had an issue with that.
I have a rule with a predicate of sunrise to sunset and it seems to be working well. I do not use any offset, so maybe that is the difference.
[edit]also noticed yours is sunset to sunrise, mine is sunrise to sunset.
I second the above regarding the actual problem. For this question in particular:
That is certainly one use! They are implemented differently, so it may matter if you particularly care about those details: while the predicate is false, the trigger events are un-subscribed to, so the rule will not wake for them. In your case, I'd say this is probably a good tradeoff--now nothing at all happens when motion is active during the day (it would otherwise have to wake, check the conditions you're using in your actions, and then probably do nothing). The main functional thing predicates can do now that was more difficult before is capturing specific state changes, e.g., mode X to mode Y, which I think was also the impetus for their creation--but, as you note, they can be used more generally, too.
Of course, in your case, it seems to maybe not be re-subscribing to the trigger events when it should, or in any case there's likely a problem somewhere. 
You can check the "App Status" page (gear icon) when the predicate should be true to see what subscriptions you have; one should be there for your doorbell/motion sensor. You'll probably also have a time-related one for sunrise or sunset (with offset) at any given time as well so it can check the predicate.
Turning on trigger and action logging for the rule may also give you clues, in case it really is triggering but the actions aren't working as you expect (predicate logging doesn't exist, nor does anything else I know capture these condition changes, but does seem like it would also be helpful here 
). Otherwise, the above may help you make some good guesses.
Yes, on the latest 2.2.8.141.
I also suspect the sunset to sunrise may be the issue as the date change has to be accounted. Wonder if I can throw a "not" in there and fix it.
I grabbed this one before sunrise today... sorry you can't see the filter from the screenshot.
Here it is now - and curious why one is sunsettime and other is sunrise - seems odd.
I still think it is weird - my first screenshot shows the predicate as TRUE but next to the name it says FALSE.
I also checked logs for the app - the only one was this morning when I did a "run actions". I had tested this last night and did have an event on my notification for motion at the front door but NO event log for this rule before this morning's forced run.
I would agree that is the issue. "Between Sunrise and Sunset" is easy. "Between Sunset and Sunrise" is a whole different animal.
Okay - so still not sure why the predicate showed TRUE but the title said Predicate FALSE - but the subscriptions made me curious. This is interesting... i literally rebuilt the app from scratch:
And now there is a subscription to the motion detector:
AND - the predicate is still FALSE (should be right now) but I am getting log entries when motion is detected:
Which is interesting because the trigger IS causing evaluation of predicate each time. So the rule does fire on the trigger if but only to determine if predicate is T/F.
No, it's just telling you why it didn't run the rule.
It saw the event (first log entry), that would trigger the rule, but the Predicate is false, so it doesn't trigger the rule (second log entry). The Predicate itself is only evaluated at Sunset-20 and Sunrise (and when Done or Update Rule is hit in the app).
Hey Bruce, glad you were watching. I'm 99% sure at this point that I had created the rule (few days ago) in an earlier edition and it has since been fixed. Think it's all good!
Is this a failsafe, or does the predicate becoming false not unsubscribe from the trigger events as I thought it did when I did some (admittedly minimal...) testing of this when 2.2.8 was new?
Yes. It doesn't remove the event subscriptions when Done or Update Rule is hit, only when the events that trigger Predicate evaluation happen. Perhaps it could, but it doesn't right now. So, between hitting Done and the first time the Predicate evaluation happens, those events fire and are rejected.
OHHH, now I understand. It adds/removes the trigger subscription when the predicate conditions change. Until the first time the predicate changes it evaluates predicate on each trigger. Maybe add logic to adjust the subscriptions when it hits a trigger and proves false? Just a thought.
No, it doesn't evaluate the predicate. It simply observes its existing truth state that was set when you hit Done. So the only 'work' its doing is logging that it's false.
So if a rule is paused when it's predicates change and then unpauses after, is it possible that it might trigger even though the predicate is False.
I think that is why the rule I asked about here has fired twice after the predicate had changed and it should not.
When a rule is paused, nothing happens with the rule, including Predicate Conditions evaluation. And resuming the rule does not cause Predicate Conditions evaluation. Pause simply takes it completely out of service, and resume places it back in service.
OK, I will need to re-think my strategy on that one.
Download the Hubitat app
