Rule condition shows TRUE in UI but Rule never transitions to SET — survives full restart

[noelab]

Build: latest-26221-b25bb3e3, Docker on Synology.

Hi, I have a Rule whose Trigger/Constraints reference other Rules via Rule State ... is TRUE. At some point it stops firing.
Expanding the rule's condition tree in the UI shows every Trigger and Constraint condition green/TRUE — confirmed live by walking into the room and watching Motion go true in real time. Rule History shows no new SET, just old reset entries.
Tried, on the same rule, same evening: recreating the trigger conditions with fresh IDs, recreating the constraint conditions with fresh IDs (flat and wrapped in a new Group — wrapping in a Group produced one SET, but it didn't reproduce on repeat attempts with the same structure), and finally a full container restart with a verified-correct saved rule. Still no SET, even with a fresh live motion event right after the restart.
Separately, I found that this rule (and its 10 per-room clones) share identical internal condition/group IDs with each other — leftover from a batch clone done months ago, never regenerated. Not sure if that's related, since fixing the IDs didn't reliably fix the symptom either.
Has anyone seen a Rule State condition show TRUE in the UI without the Rule ever producing a SET, surviving a clean restart?
Thanks in advance

[tunnus]

@noelab are constraints also true (or empty)?

[noelab]

@tunnus Hi, also constraints are true

[toggledbits]

A couple of things here...

• Editing the rule will cause re-evaluation, which is likely why you have repeated RESETs in the history with no SETs between.
• As hard as I try, and I keep looking, finding, and fixing, the UI can get out of sync with the running engine/service, so always hard-refresh when the UI isn't making sense.
• If a Rule has been edited, especially multiple times, and it's not performing as expected, reset the Rule. There's button for that: Even restarting Reactor doesn't do what this button does.
• Beyond that, it would also be handy to see the top part of the screen shot that has been cut off (the Triggers group heading and stuff above it).

[noelab]

Thanks for the reply. I tried again, the rules driving DLT have the same logical structure in every room and no one is working.
Tried the Reset Rule button specifically (not just re-editing conditions), plus a hard refresh (F5) beforehand, plus Reset Rule on every rule this one depends on (the Motion/PresenceMode rule, the Lux rule, the OccupancyMode rule, the Debounce rule) — not just the affected rule itself.
Clicked Reset Rule, got a fresh reset entry in Rule History, then a genuine motion event ~10s later. The condition tree updated correctly in the UI (Trigger OR-group and Constraints both show true, timestamped at the motion event). The rule's SET action turns lights on directly. That light did not physically turn on. Also if the UI can be out of sync with the display, a physical device action should be executed. Rule History still shows no SET after the reset entry.

I'm trying to put some logs

22:12:46.474 Rule:NOTICE  vH_DLT_20_Auto_ON (rule-mo5edh1o in H) stopping
22:12:46.475 Rule:NOTICE  vH_Motion_00_LastSeen (rule-mo5wsh4z in H) stopping
22:12:46.476 Rule:NOTICE  vH_PresenceMode_MotionSensor_ID (rule-mo5adtot in H) stopping
...
22:13:07.864 app:null     Shutdown complete, process ID 1
22:14:39.639 app:null     Reactor build latest-26221-b25bb3e3 starting
...
22:16:12.239 Rule:NOTICE  vH_DLT_20_Auto_ON (rule-mo5edh1o in H) starting
22:16:12.240 Rule:NOTICE  vH_Motion_00_LastSeen (rule-mo5wsh4z in H) starting
22:16:12.240 Rule:NOTICE  vH_PresenceMode_MotionSensor_ID (rule-mo5adtot in H) starting
22:16:13.214 Rule:INFO    vH_DLT_20_Auto_ON (rule-mo5edh1o in H) started
22:16:13.215 Rule:INFO    vH_Motion_00_LastSeen (rule-mo5wsh4z in H) started
22:16:13.215 Rule:INFO    vH_PresenceMode_MotionSensor_ID (rule-mo5adtot in H) started

22:18:29.766 Rule:INFO    vH_PresenceMode_MotionSensor_ID (rule-mo5adtot in H) starting rule state evaluation; because predicate-state-changed
22:18:29.766 Rule:INFO    vH_PresenceMode_MotionSensor_ID (rule-mo5adtot in H) evaluated; rule state transition from RESET to 'SET'
22:18:29.779 Rule:INFO    vH_Motion_00_LastSeen (rule-mo5wsh4z in H) starting rule state evaluation; because predicate-state-changed
22:18:29.779 Rule:INFO    vH_Motion_00_LastSeen (rule-mo5wsh4z in H) evaluated; rule state transition from RESET to 'SET'
   -- rule-mo5edh1o: NOTHING --

22:19:02.407 Rule:INFO    vH_PresenceMode_MotionSensor_ID (rule-mo5adtot in H) starting rule state evaluation; because predicate-state-changed
22:19:02.408 Rule:INFO    vH_PresenceMode_MotionSensor_ID (rule-mo5adtot in H) evaluated; rule state transition from SET to 'RESET'
22:19:02.419 Rule:INFO    vH_Motion_00_LastSeen (rule-mo5wsh4z in H) starting rule state evaluation; because predicate-state-changed
22:19:02.419 Rule:INFO    vH_Motion_00_LastSeen (rule-mo5wsh4z in H) evaluated; rule state transition from SET to 'RESET'
   -- rule-mo5edh1o: NOTHING --

Thanks in advance

[toggledbits]

In the first image, the triggers show true as of 9:42:09. The constraints show true 10 seconds later. That's a not pass. The constraints have to be true at the instant the triggers are also true (or before), or the rule does not SET. If the constraints become true later, that doesn't matter, the rule does not SET.

Your third image shows the same. Triggers true at 10:31:53, but constraints didn't go true until 10:32:12 (19 seconds later).

From the docs:

[noelab]

This post is deleted!

[noelab]

@toggledbits Trigger OR was the problem and not identical internal condition/group ID as I suspected. AND is the fix. With the old OR setup, the problem was that the trigger had already fired, registering as "true" for a different reason (Lux), minutes earlier. So the photo captured by the trigger was outdated.
Thanks again for the push in the right direction!