State trigger suddenly fails, but condition is true

I have several IKEA motion sensors paired with my Conbee II (deConz) ZigBee integration. They have all served me well for years. 100% stable.
Suddenly, two of them fail to trigger the automations upon state motion cleared.
They trigger correctly the automation for motion detected though.
I have not made any changes to the automations. All my other IKEA motion sensors triggers correctly on both detected and cleared.
When I inspect the state from HA, it changes correctly. Below is a snapshot from the history graph:
image

Below is a snapshot from the automation panel.It seems this problem began yesterday, but why? (the lower is state:detected, and the upper is state:cleared)
image

If all my IKEA motion sensors had suddenly stopped, I would have suspected the Conbee II ZigBee coordinator or the deConz integration, but no. If I had made any changes to any of the automations, I would know what to look for, but no. If HA failed to report the state change correctly, I wouldnā€™t expect the automation to trigger, but the state change is correctly detected and logged.
Any help in my debugging effort is highly appreciated. Iā€™m lost!

when you go to the automation traces, do you get a trace at all for the time when the motion cleared and it should run? if so, download the trace and post here.

also post your automation.

Hi, and many thanks for coming to the rescue.
I found the problem - and as always, itā€™s mainly my own mistakes;
My expectation/interpretation/understanding of ā€œtraceā€ (being a former programmer) is that it should be possible to see each step of the execution chain, almost what we used to call ā€œsingle steppingā€. Thus I expected the automation to always trigger when the trigger criteria took place (event), and then if the following condition(s) which Iā€™d added manually were not met, execution would break out and halt.
Not so, as it turns out. HA seems to evaluate the condition(s) before the trigger (event) is added to the event bus. Thus if the conditions are not met, nothing at all happens.

Effectively, this means there is no way to test added condition(s) in real time as the result of the conditional evaluation is never presented anywhere unless true.
This lead me to mistakenly believe that it was the trigger(event) mechanism that failed while in reality it was the condition I had added that evaluated to false.

I think this makes the term ā€œtraceā€ somewhat misleading or incomplete.
Anyway, thanks for stepping in.

No. That is not how automations work.

After a trigger occurs any defined conditions will be evaluated.

You will see this in the trace. e.g. triggered but stopped in second condition:

Screenshot 2024-09-06 at 19-24-36 Settings ā€“ Home Assistant

The only time you wonā€™t see a trace is if the automation is not triggered.

No, Iā€™m refering to this condition:

image

Unless met (true) there is no trigger at all.

It is always triggered based on the trigger, then the conditions are evaluated and if true, the action is performed.
Can you share your automation and the real state of your sensor in developer tools - states.

Thatā€™s not correct.

trigger ā†’ variables calculated ā†’ conditions checked ā†’ actions ran.

Please post your trace.

Yes that is exactly what I am referring to. HA does not:

it evaluates them after the trigger. As can be seen in the image I posted.

Iā€™m not sure exactly what youā€™re asking for, but here the state:

image

And hereā€™s the automation:

trigger:
  - platform: state
    entity_id:
      - binary_sensor.bad_1
    to: "off"
    for:
      hours: 0
      minutes: 5
      seconds: 0
condition:
  - condition: numeric_state
    entity_id: sensor.humidity_bad_1
    below: 55
action:
  - data: {}
    target:
      entity_id: light.bad1_light
    action: light.turn_off
mode: single

Hereā€™s a summary of what happened:
The above is one (1) of several identical automations that turns off the lights in our bathrooms (ā€˜badā€™ means bathroom in my language). These automations has worked well for years.
The condition is the humidity in the bathroom. It was always set to 52% which was found to be a reasonable value. If above that, itā€™s an indication that someone is taking a shower behind glass walls (PIR does not penetrate glass), hence leave the lights on.

Yesterday, we had a very rare weather phenomena. Despite being September, the outside temperature rose to almost 30 degrees celcius accompanied by significant humidity. Consequently, the humidity indoor never dropped below 52% and the trigger failed (as can be seen by the post above here).
When I finally realised why, and changed the threshold to 55% after noticing that the humidity was constantly 53%, then the trigger began working again.

So, clearly the automation was never triggered unless the condition was met. I saw this when I made a dummy automation with no condition at all, using the same trigger. It would trigger every time, while the real automation never triggered until I changed the condition.

Viking. Please. Post. The. Trace.

{
  "trace": {
    "last_step": "condition/0/entity_id/0",
    "run_id": "b130bfdfb5ee48cdc9040e416c670ac5",
    "state": "stopped",
    "script_execution": "failed_conditions",
    "timestamp": {
      "start": "2024-09-06T09:43:09.200233+00:00",
      "finish": "2024-09-06T09:43:09.200487+00:00"
    },
    "domain": "automation",
    "item_id": "1657483920721",
    "trigger": "state of binary_sensor.bad_1",
    "trace": {
      "trigger/0": [
        {
          "path": "trigger/0",
          "timestamp": "2024-09-06T09:43:09.200302+00:00",
          "changed_variables": {
            "this": {
              "entity_id": "automation.bad_1_turn_off_light_after_10_min",
              "state": "on",
              "attributes": {
                "id": "1657483920721",
                "last_triggered": "2024-09-06T03:13:49.365381+00:00",
                "mode": "single",
                "current": 0,
                "friendly_name": "Bad 1 turn off light"
              },
              "last_changed": "2024-09-06T06:50:01.568490+00:00",
              "last_reported": "2024-09-06T06:50:01.568490+00:00",
              "last_updated": "2024-09-06T06:50:01.568490+00:00",
              "context": {
                "id": "01J731HMZ0PT30BX8Z55VCP2F9",
                "parent_id": null,
                "user_id": null
              }
            },
            "trigger": {
              "id": "0",
              "idx": "0",
              "alias": null,
              "platform": "state",
              "entity_id": "binary_sensor.bad_1",
              "from_state": {
                "entity_id": "binary_sensor.bad_1",
                "state": "on",
                "attributes": {
                  "on": true,
                  "dark": true,
                  "device_class": "motion",
                  "friendly_name": "Motion Sensor Bad 1"
                },
                "last_changed": "2024-09-06T09:31:52.145003+00:00",
                "last_reported": "2024-09-06T09:35:09.213448+00:00",
                "last_updated": "2024-09-06T09:31:52.145003+00:00",
                "context": {
                  "id": "01J73ASZYHHH2VM7CMT7X8YX4N",
                  "parent_id": null,
                  "user_id": null
                }
              },
              "to_state": {
                "entity_id": "binary_sensor.bad_1",
                "state": "off",
                "attributes": {
                  "on": true,
                  "dark": true,
                  "device_class": "motion",
                  "friendly_name": "Motion Sensor Bad 1"
                },
                "last_changed": "2024-09-06T09:38:09.198758+00:00",
                "last_reported": "2024-09-06T09:38:09.198758+00:00",
                "last_updated": "2024-09-06T09:38:09.198758+00:00",
                "context": {
                  "id": "01J73B5G5EEHYP5R9TTXVQGFFK",
                  "parent_id": null,
                  "user_id": null
                }
              },
              "for": {
                "__type": "<class 'datetime.timedelta'>",
                "total_seconds": 300
              },
              "attribute": null,
              "description": "state of binary_sensor.bad_1"
            }
          }
        }
      ],
      "condition/0": [
        {
          "path": "condition/0",
          "timestamp": "2024-09-06T09:43:09.200355+00:00",
          "result": {
            "result": false
          }
        }
      ],
      "condition/0/entity_id/0": [
        {
          "path": "condition/0/entity_id/0",
          "timestamp": "2024-09-06T09:43:09.200395+00:00",
          "result": {
            "result": false,
            "state": 75.34,
            "wanted_state_below": 55
          }
        }
      ]
    },
    "config": {
      "id": "1657483920721",
      "alias": "Bad 1 turn off light",
      "description": "SlƄ av alt lyset etter 4 min dersom ingen er pƄ badet eller i dusjen",
      "trigger": [
        {
          "platform": "state",
          "entity_id": [
            "binary_sensor.bad_1"
          ],
          "to": "off",
          "for": {
            "hours": 0,
            "minutes": 5,
            "seconds": 0
          }
        }
      ],
      "condition": [
        {
          "condition": "numeric_state",
          "entity_id": "sensor.humidity_bad_1",
          "below": 55
        }
      ],
      "action": [
        {
          "data": {},
          "target": {
            "entity_id": "light.bad1_light"
          },
          "action": "light.turn_off"
        }
      ],
      "mode": "single"
    },
    "blueprint_inputs": null,
    "context": {
      "id": "01J73BEN4G2071PJ58CCJ6KKF7",
      "parent_id": "01J73B5G5EEHYP5R9TTXVQGFFK",
      "user_id": null
    }
  },
  "logbookEntries": []
}

The trigger triggered and it was off for 5 minutes before triggering.

There you go. The state was 75.34 and your condition wants it below 55.

Yes, since the trace only shows when it actually triggered, after I changed the condition to 55%
I donā€™t have any traces from where it never triggered (at condition 50%) because it never triggered because the condition was ā€˜falseā€™.

No thatā€™s not how it works. The trigger occurs before the condition is checked and a trace will be generated if a trigger occurs. You have this wrong.

Well, all I know is this:
The automation overview never showed that it triggered. See this screencap:
image

If it had triggered, I expected it to report the time passed since last triggered. This one says ā€˜yesterdayā€™ and of course there wasnā€™t any traces to inspect.

Well, it didnā€™t trigger. So that means it wasnā€™t a full 5 minutes. Remember, the UI rounds to the nearest minute for relative time.

No, I was fully aware of that and carefully waited much more than 5 minutes. I even removed that delay - just incase, and it still didnā€™t trigger.
But as soon as I changed the condition or even removed it completely, then it triggered immediately.

Then thereā€™s something off with the entity thatā€™s doing the triggering, and thatā€™s where you should focus your attention. The issue is not with the condition or the trigger in the automation.

ā€œThe entityā€ - do you mean the PIR sensor itself?

  1. after changing the condition, it works perfectly again.
  2. Is it likely that 4 PIR sensors simultaneously failed with the exact same failure? No way!

Listen, you can drop your sarcasm at the door. Thanks.

Post the history of your PR sensors with timestamps of the state changes.

Again, the condition is not checked before a trigger. If you arenā€™t willing to except that, then this conversation is over and Iā€™ll close the thread because thereā€™s no reasoning with adamant incorrect information.