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.
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.
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).
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.
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.