State triggered every hour although unchanged

[dantist]

I have some Fibaro wall plugs and the following trigger for one of them:

- alias: Record player stopped
  trigger:
    platform: numeric_state
    entity_id: sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9
    below: 1
  action:
    - service: media_player.turn_off
      entity_id: media_player.denon_avr_x1100w

Although theres no power consumption the whole day, the state triggers every full hour.

I understand that the plug sends a status update each hour, but why does the trigger run if the state doesn’t change? Is there a way to prevent the trigger if it “changes” from “0.0” to “0.0”?

[freshcoast]

This is because the zwave component for the sensor entity implements a property called force_update that always returns True. According to the dev docs, this property when True forces an update to the state machine whenever the entity is updated, regardless of existing state. Updates to the state machine can trigger automations, regardless of whether the state changes or not. If your fibaro sensor is sending periodic values that don’t change, normally they would be ignored, but with this force_update on, it triggers the automations, saves history, etc.

Some components like the MQTT sensor have a configuration setting to turn this on or off per entity.

If you want some history on the topic, the change was introduced with this PR. I also found another issue that was submitted with some discussion. I don’t quite understand the reasoning behind the PR, but it stands to this day.

Sounds like you will need to change your automation to get the desired behavior. For example, you could use a template trigger and check that the trigger.from_state value is >= 1.

[pnbruckner (Phil)]

But I don’t think that can explain it. The numeric_state trigger remembers if the value has satisfied the condition (in this case below 1), and therefore triggered, and won’t trigger again (normally) until the condition is no longer met (in this case becomes 1 or more), and then is met again (below 1.) It doesn’t matter if it’s forced to update with the same value. It would be the same as if the value was 2, 0, 0.1, 0.9, it would only trigger once, even though it updated but remained below 1.

I said “normally” because I believe it will forget it has triggered if the state becomes a non numeric value (e.g., ‘unavailable’, ‘unknown’, etc.)

You should look at the history of the entity, and you may need to query the database to see the actual state transitions, especially around that once per hour event.

[dantist]

Thank you both for analyzing the issue. I’m a HASS newbie and have no idea how to check the states with database queries.

Isn’t there a way to re-phrase the automation? Actually the state is exactly “0.0” when the power is off, so I don’t really need a “below 1”. I don’t know if you can avoid the issue with a normal state instead of numeric_state?

[pnbruckner (Phil)]

Actually, given what @freshcoast mentioned, that the state update is forced (even when the state doesn’t change), a state trigger would be worse (for your use case) than a numeric_state trigger.

You really need to understand how the entity’s state is changing in order to write the correct trigger for how you want your automation to work.

If you can’t get enough detail from the entity’s history, and you don’t know how to query the database, then the next best thing might be to do this:

logger:
  default: info
  logs:
    homeassistant.core: debug

This will add debug messages for homeassistant.core to home-assistant.log, including a message with details of all state changes in the system. Then you can search it for state changes for this entity. Look for lines including state_changed and sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9.

[freshcoast]

Thank you both for analyzing the issue. I’m a HASS newbie and have no idea how to check the states with database queries.

You can look in the logbook, if you’re not excluding it. It will show you all the updates. For, example, here’s the same situation with my zwave smoke alarm. It broadcasts updates every hour. HA logs these because of the force_update.

Isn’t there a way to re-phrase the automation? Actually the state is exactly “0.0” when the power is off, so I don’t really need a “below 1”. I don’t know if you can avoid the issue with a normal state instead of numeric_state?

You want to use a template trigger. The trigger value will evaluate to true or false. So just write a template statement that manually compares the value to 0, or something small enough. If the template returns False each time, it will never execute the automation.

[pnbruckner (Phil)]

@freshcoast

You want to use a template trigger. The trigger value will evaluate to true or false. So just write a template statement that manually compares the value to 0, or something small enough. If the template returns False each time, it will never execute the automation.

Not sure how this is any different from a numeric_state trigger. They both remember if the condition is met or not and will only trigger again when it goes false then true.

EDIT: Of course, in a template trigger you can have it assume a value if it isn’t numeric, which isn’t possible with a numeric_state trigger (which just assumes the condition is not met if the state is not numeric.)

@freshcoast

Sounds like you will need to change your automation to get the desired behavior. For example, you could use a template trigger and check that the trigger.from_state value is >= 1.

Actually the trigger.from_state might be useful, but that would apply equally well to a numeric_state trigger as it does to a template trigger, seeing as this would be done in the condition, not the trigger.

Still, to know how to write the trigger/condition he needs to understand what the state of the entity is doing. The Logbook might be helpful, at least as a start. It would certainly be easier to use than the detailed log. But, in the end, it might be necessary to see all the details.

[dantist]

I just noticed that for whatever reason the hourly triggers stopped a couple of hours ago. I will leave the debug mode running over night and will hopefully have some results tomorrow.

[freshcoast]

Not sure how this is any different from a numeric_state trigger. They both remember if the condition is met or not and will only trigger again when it goes false then true.

Well, as I originally said, use trigger.from_state. Something like this (template code untested, might need float conversions?):

- alias: Record player stopped
  trigger:
    platform: template
    value_template: "{{ (trigger.from_state.state > 1) and (trigger.to_state.state <= 1) }}"

I’m not sure why the template trigger would “remember” the previous value, it only cares about what value_template evaluates to.

Using a condition template is exactly the same thing.

- alias: Record player stopped
  trigger:
    platform: numeric_state
    entity_id: sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9
    below: 1
  condition:
    condition: template
    value_template: "{{ trigger.from_state.state > 1 }}"

Adjust the comparisons as necessary.

I don’t see where the numeric_state automation code has a “memory” about previous states. As far as I can tell, it simply compares the current state value to the given above and below values. Maybe you could point me to the code that handles this? I’ll admit I could have missed it. If force_state is causing state machine updates, which then causes numeric_state to handle the event, if it only cares about comparing the to state value to the above/below values, why wouldn’t it trigger? Given that issue I linked to, I’m a bit confused why numeric_state would have different behavior than state trigger when it comes to forced updates.

[pnbruckner (Phil)]

@freshcoast

use trigger.from_state

The trigger variable does not exist while evaluating the template trigger’s value_template. It only exists in the automation’s condition & action sections.

@freshcoast

I’m not sure why the template trigger would “remember” the previous value, it only cares about what value_template evaluates to.

By design it will trigger the first time the template evaluates to true. Then after that it will only trigger when the template evaluates to false (actually anything but true) and then back to true. Also note that the template is only evaluated when one of the referenced entities changes state.

@freshcoast

Using a condition template is exactly the same thing.

No, again, because the trigger variable doesn’t exist inside the trigger.

@freshcoast

I don’t see where the numeric_state automation code has a “memory” about previous states.

It definitely does.

@freshcoast

Maybe you could point me to the code that handles this?

Sure:

home-assistant/core/blob/0439d6964c7adf56ae32e019de08d64541631b04/homeassistant/components/automation/numeric_state.py#L104-L107

[freshcoast]

@pnbruckner

The trigger variable does not exist while evaluating the template trigger’s value_template . It only exists in the automation’s condition & action sections.

You’re right, I swear I knew this before… Besides a single sentence that says “This makes it possible to adjust your condition and action based on the information of the trigger.” (template docs), I was unable to find any documentation to the contrary.

BTW, I meant to write this as a trigger:

 trigger:
    platform: template
    value_template: "{{ (trigger.from_state.state > 1) and (states('sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9') <= 1) }}"

Not sure if there’s a technical reason why it couldn’t work, but it seems pretty reasonable to me!

    if not matching:
        entities_triggered.discard(entity)
    elif entity not in entities_triggered:
        entities_triggered.add(entity)

I saw this, but didn’t make sense of it, but now I get it. Basically, if the state matches the condition (value <= 1 in this case), it will check the list of already triggered entities. Only if the entity is not in the list will it call the template action. Once the state doesn’t match (> 1), it’s discarded from the list and will be ready to trigger again… Thanks for the correction.

[pnbruckner (Phil)]

@freshcoast

Not sure if there’s a technical reason why it couldn’t work, but it seems pretty reasonable to me!

Other than what we’ve been discussing. That is, the trigger variable does not exist when evaluating the template trigger. That would be a technical reason why it wouldn’t work.

But I also think it’s reasonable to define the trigger variable (with the exception of the for field) during the template trigger evaluation. I’ve wanted to use that before. And I even went so far as to figure out how to implement it (which wouldn’t be difficult.) However, I’m not sure it would be clear to most users what the trigger variable would contain at that point, so it might be too confusing.

@freshcoast

Basically, if the state matches the condition (value <= 1 in this case), it will check the list of already triggered entities. Only if the entity is not in the list will it call the template action. Once the state doesn’t match (> 1), it’s discarded from the list and will be ready to trigger again… Thanks for the correction.

Yep, except for one minor thing - below: 1 means < 1, not <= 1.

[dantist]

It took a while until the hourly triggers appeared again, but now I can finally deliver the log output:

2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9, old_state=<state sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9=0.0; node_id=7, value_index=4, value_instance=1, value_id=72057594160365634, power_consumption=0.0, unit_of_measurement=W, friendly_name=Plattenspieler, icon=mdi:flash-red-eye @ 2019-12-18T08:57:15.169635+01:00>, new_state=<state sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9=0.0; node_id=7, value_index=4, value_instance=1, value_id=72057594160365634, power_consumption=0.0, unit_of_measurement=W, friendly_name=Plattenspieler, icon=mdi:flash-red-eye @ 2019-12-18T09:57:15.216457+01:00>>
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=script, service=add_logbook_entry, service_data=button_name=Plattenspieler, message=gestoppt, entity=sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9, domain=binary_sensor>

The device values don’t change at all.

[pnbruckner (Phil)]

So based on the automation in your OP I don’t see where the one state_changed event you show would have triggered it. I’m pretty sure it wouldn’t. Well, unless it was the first state_changed event for that entity. Also you don’t show the the log message that indicates that the automation was triggered.

If you still have the log (or you can capture another one with the unexpected trigger), then I have a script that can analyze it and extract the state_changed events for the sensor and the automation that should hopefully explain why the automation is triggering. I can either give you the script if you can run it from the command line. Or you could share your log with me and I can run the script. I’ve done this for others. It’s up to you.

FYI, you’d run the script like this (from the HA config directory):

python3 state_updates.py home-assistant.log sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 automation.record_player_stopped last_triggered

And it will print out all state changes for those entities (as well as the last_triggered attribute for the automation), and will look something like this:

$ python3 state_updates.py home-assistant.log binary_sensor.hf_motion automation.house_front_snapshot last_triggered
entity_id                       | log time            | last_changed                     | state | attributes
--------------------------------|---------------------|----------------------------------|-------|-----------
binary_sensor.hf_motion         | 2019-12-12 11:12:52 | 2019-12-12T11:12:52.532841-06:00 | off   |
automation.house_front_snapshot | 2019-12-12 11:12:52 | 2019-12-12T11:12:52.553618-06:00 | on    | last_triggered=2019-12-12T15:18:33.498360+00:00
=============================== | 2019-12-12 11:12:55 | ===== Home Assistant Start ===== | ===== | ==========
binary_sensor.hf_motion         | 2019-12-12 11:20:10 | 2019-12-12T11:20:10.002304-06:00 | on    |
automation.house_front_snapshot | 2019-12-12 11:20:10 | 2019-12-12T11:12:52.553618-06:00 | on    | last_triggered=2019-12-12T11:20:10.033007-06:00
binary_sensor.hf_motion         | 2019-12-12 11:24:34 | 2019-12-12T11:24:34.286860-06:00 | off   |
                                | 2019-12-12 14:37:35 | 2019-12-12T14:37:35.136842-06:00 | on    |
automation.house_front_snapshot | 2019-12-12 14:37:35 | 2019-12-12T11:12:52.553618-06:00 | on    | last_triggered=2019-12-12T14:37:35.181365-06:00
binary_sensor.hf_motion         | 2019-12-12 14:41:53 | 2019-12-12T14:41:53.359418-06:00 | off   |

[dantist]

Here’s the results:

pi@RPiSmartHome:/home/homeassistant/.homeassistant $ python3 state_updates.py home-assistant.log sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 automation.record_player_stop                                                   ped last_triggered
entity_id                                           | log time            | last_changed                     | state | attributes
----------------------------------------------------|---------------------|----------------------------------|-------|-----------
=================================================== | 2019-12-17 21:03:26 | ===== Home Assistant Start ===== | ===== | ==========
sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 | 2019-12-17 21:03:26 | 2019-12-17T21:03:26.998060+01:00 | 0.0   |
                                                    | 2019-12-17 21:04:10 | 2019-12-17T21:04:10.289266+01:00 | 0.0   |
                                                    | 2019-12-17 21:57:14 | 2019-12-17T21:57:14.959147+01:00 | 0.0   |
                                                    | 2019-12-17 22:57:14 | 2019-12-17T22:57:14.976712+01:00 | 0.0   |
                                                    | 2019-12-17 23:57:14 | 2019-12-17T23:57:14.993576+01:00 | 0.0   |
                                                    | 2019-12-18 00:57:15 | 2019-12-18T00:57:15.039967+01:00 | 0.0   |
                                                    | 2019-12-18 01:57:15 | 2019-12-18T01:57:15.036650+01:00 | 0.0   |
                                                    | 2019-12-18 02:57:15 | 2019-12-18T02:57:15.055088+01:00 | 0.0   |
                                                    | 2019-12-18 03:57:15 | 2019-12-18T03:57:15.071890+01:00 | 0.0   |
                                                    | 2019-12-18 04:57:15 | 2019-12-18T04:57:15.092470+01:00 | 0.0   |
                                                    | 2019-12-18 05:57:15 | 2019-12-18T05:57:15.100241+01:00 | 0.0   |
                                                    | 2019-12-18 06:57:15 | 2019-12-18T06:57:15.137404+01:00 | 0.0   |
                                                    | 2019-12-18 07:57:15 | 2019-12-18T07:57:15.182500+01:00 | 0.0   |
                                                    | 2019-12-18 08:57:15 | 2019-12-18T08:57:15.169635+01:00 | 0.0   |
                                                    | 2019-12-18 09:57:15 | 2019-12-18T09:57:15.216457+01:00 | 0.0   |
                                                    | 2019-12-18 10:57:15 | 2019-12-18T10:57:15.208720+01:00 | 0.0   |
                                                    | 2019-12-18 11:57:15 | 2019-12-18T11:57:15.229153+01:00 | 0.0   |
                                                    | 2019-12-18 12:57:15 | 2019-12-18T12:57:15.228134+01:00 | 0.0   |
                                                    | 2019-12-18 13:57:15 | 2019-12-18T13:57:15.248665+01:00 | 0.0   |
                                                    | 2019-12-18 14:57:15 | 2019-12-18T14:57:15.288768+01:00 | 0.0   |
                                                    | 2019-12-18 15:57:15 | 2019-12-18T15:57:15.304776+01:00 | 0.0   |
                                                    | 2019-12-18 16:57:15 | 2019-12-18T16:57:15.319338+01:00 | 0.0   |
                                                    | 2019-12-18 17:57:15 | 2019-12-18T17:57:15.348459+01:00 | 0.0   |
                                                    | 2019-12-18 18:57:15 | 2019-12-18T18:57:15.363387+01:00 | 0.0   |

Also, here’s a more complete snippet from the log when the trigger happens:

2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9, old_state=<state sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9=0.0; node_id=7, value_index=4, value_instance=1, value_id=72057594160365634, power_consumption=0.0, unit_of_measurement=W, friendly_name=Plattenspieler, icon=mdi:flash-red-eye @ 2019-12-18T08:57:15.169635+01:00>, new_state=<state sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9=0.0; node_id=7, value_index=4, value_instance=1, value_id=72057594160365634, power_consumption=0.0, unit_of_measurement=W, friendly_name=Plattenspieler, icon=mdi:flash-red-eye @ 2019-12-18T09:57:15.216457+01:00>>
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event automation_triggered[L]: name=Plattenspieler gestoppt, entity_id=automation.plattenspieler_gestoppt>
2019-12-18 09:57:15 INFO (MainThread) [homeassistant.components.automation] Executing Plattenspieler gestoppt
2019-12-18 09:57:15 INFO (MainThread) [homeassistant.helpers.script] Script Plattenspieler gestoppt: Running script
2019-12-18 09:57:15 INFO (MainThread) [homeassistant.helpers.script] Script Plattenspieler gestoppt: Executing step call service
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=script, service=add_logbook_entry, service_data=button_name=Plattenspieler, message=gestoppt, entity=sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9, domain=binary_sensor>
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_management_5, old_state=<state sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_management_5=254; node_id=7, value_index=11, value_instance=1, value_id=72057594161414321, power_consumption=0.0, unit_of_measurement=, friendly_name=Fibaro Plug - Plattenspieler Power Management @ 2019-12-18T08:57:15.231036+01:00>, new_state=<state sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_management_5=254; node_id=7, value_index=11, value_instance=1, value_id=72057594161414321, power_consumption=0.0, unit_of_measurement=, friendly_name=Fibaro Plug - Plattenspieler Power Management @ 2019-12-18T09:57:15.308334+01:00>>
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event script_started[L]: name=Add Logbook Entry, entity_id=script.add_logbook_entry>
2019-12-18 09:57:15 INFO (MainThread) [homeassistant.helpers.script] Script Add Logbook Entry: Running script
2019-12-18 09:57:15 INFO (MainThread) [homeassistant.helpers.script] Script Add Logbook Entry: Executing step call service
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=logbook, service=log, service_data=name=Plattenspieler, message=gestoppt, entity_id=sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9, domain=binary_sensor>
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event logbook_entry[L]: name=Plattenspieler, message=gestoppt, domain=binary_sensor, entity_id=sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9>
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=script.add_logbook_entry, old_state=<state script.add_logbook_entry=off; last_triggered=2019-12-18T08:57:15.265201+01:00, friendly_name=Add Logbook Entry @ 2019-12-17T21:03:10.532672+01:00>, new_state=<state script.add_logbook_entry=off; last_triggered=2019-12-18T09:57:15.313057+01:00, friendly_name=Add Logbook Entry @ 2019-12-17T21:03:10.532672+01:00>>
2019-12-18 09:57:15 INFO (MainThread) [homeassistant.helpers.script] Script Plattenspieler gestoppt: Executing step call service
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=media_player, service=turn_off, service_data=entity_id=['media_player.denon_avr_x1100w']>
2019-12-18 09:57:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=automation.plattenspieler_gestoppt, old_state=<state automation.plattenspieler_gestoppt=on; last_triggered=2019-12-18T08:57:15.535433+01:00, friendly_name=Plattenspieler gestoppt @ 2019-12-18T09:13:55.143201+01:00>, new_state=<state automation.plattenspieler_gestoppt=on; last_triggered=2019-12-18T09:57:15.585421+01:00, friendly_name=Plattenspieler gestoppt @ 2019-12-18T09:13:55.143201+01:00>>

[pnbruckner (Phil)]

Ah, I see you already have a copy of my state_updates.py script. But did you get a recent version – i.e., within the last couple of hours? I had to modify it to handle new_state equal to None, which it didn’t before. Can you grab a new copy and run it again?

EDIT: https://github.com/pnbruckner/homeassistant-config/blob/master/tools/state_updates.py

Also, is the entity_id of the automation not automation.record_player_stop? How is the automation currently defined?

[dantist]

I googled your script shortly before I posted the results, so it’s up to date Made a diff to the version you just linked, they are identical. And sorry for the confusion regarding the automation name. The one in the log is correct.

- alias: Plattenspieler gestoppt
  trigger:
    platform: numeric_state
    entity_id: sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9
    below: 1
  action:
    - service: script.add_logbook_entry
      data:
        button_name: 'Plattenspieler'
        message: 'gestoppt'
        entity: 'sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9'
        domain: 'binary_sensor'
    - service: media_player.turn_off
      entity_id: media_player.denon_avr_x1100w

[pnbruckner (Phil)]

Ok. Then please try running this and let me know the results:

python3 state_updates.py home-assistant.log sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 automation.plattenspieler_gestoppt last_triggered

I wonder if the automation is getting turned off and back on, which would reinitialize the trigger. Hmm.

[dantist]

Here we go:

pi@RPiSmartHome:/home/homeassistant/.homeassistant $ python3 state_updates.py home-assistant.log sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 automation.plattenspieler_gestoppt last_triggered
entity_id                                           | log time            | last_changed                     | state        | attributes
----------------------------------------------------|---------------------|----------------------------------|--------------|-----------
automation.plattenspieler_gestoppt                  | 2019-12-17 21:03:11 | 2019-12-17T21:03:11.386675+01:00 | on           | last_triggered=2019-12-17T20:39:00.523315+01:00
=================================================== | 2019-12-17 21:03:26 | ===== Home Assistant Start ===== | ============ | ==========
sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 | 2019-12-17 21:03:26 | 2019-12-17T21:03:26.998060+01:00 | 0.0          |
automation.plattenspieler_gestoppt                  | 2019-12-17 21:03:30 | 2019-12-17T21:03:11.386675+01:00 | on           | last_triggered=2019-12-17T21:03:29.972025+01:00
sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 | 2019-12-17 21:04:10 | 2019-12-17T21:04:10.289266+01:00 | 0.0          |
                                                    | 2019-12-17 21:57:14 | 2019-12-17T21:57:14.959147+01:00 | 0.0          |
                                                    | 2019-12-17 22:57:14 | 2019-12-17T22:57:14.976712+01:00 | 0.0          |
                                                    | 2019-12-17 23:57:14 | 2019-12-17T23:57:14.993576+01:00 | 0.0          |
                                                    | 2019-12-18 00:57:15 | 2019-12-18T00:57:15.039967+01:00 | 0.0          |
                                                    | 2019-12-18 01:57:15 | 2019-12-18T01:57:15.036650+01:00 | 0.0          |
                                                    | 2019-12-18 02:57:15 | 2019-12-18T02:57:15.055088+01:00 | 0.0          |
                                                    | 2019-12-18 03:57:15 | 2019-12-18T03:57:15.071890+01:00 | 0.0          |
                                                    | 2019-12-18 04:57:15 | 2019-12-18T04:57:15.092470+01:00 | 0.0          |
                                                    | 2019-12-18 05:57:15 | 2019-12-18T05:57:15.100241+01:00 | 0.0          |
                                                    | 2019-12-18 06:57:15 | 2019-12-18T06:57:15.137404+01:00 | 0.0          |
                                                    | 2019-12-18 07:57:15 | 2019-12-18T07:57:15.182500+01:00 | 0.0          |
automation.plattenspieler_gestoppt                  | 2019-12-18 08:00:03 | 2019-12-18T08:00:03.431031+01:00 | off          | last_triggered=2019-12-17T21:03:29.972025+01:00
                                                    | 2019-12-18 08:00:03 |                                  | === None === |
                                                    | 2019-12-18 08:00:04 | 2019-12-18T08:00:04.279635+01:00 | on           | last_triggered=2019-12-17T21:03:29.972025+01:00
sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 | 2019-12-18 08:57:15 | 2019-12-18T08:57:15.169635+01:00 | 0.0          |
automation.plattenspieler_gestoppt                  | 2019-12-18 08:57:15 | 2019-12-18T08:00:04.279635+01:00 | on           | last_triggered=2019-12-18T08:57:15.535433+01:00
                                                    | 2019-12-18 09:13:54 | 2019-12-18T09:13:54.177983+01:00 | off          | last_triggered=2019-12-18T08:57:15.535433+01:00
                                                    | 2019-12-18 09:13:54 |                                  | === None === |
                                                    | 2019-12-18 09:13:55 | 2019-12-18T09:13:55.143201+01:00 | on           | last_triggered=2019-12-18T08:57:15.535433+01:00
sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 | 2019-12-18 09:57:15 | 2019-12-18T09:57:15.216457+01:00 | 0.0          |
automation.plattenspieler_gestoppt                  | 2019-12-18 09:57:15 | 2019-12-18T09:13:55.143201+01:00 | on           | last_triggered=2019-12-18T09:57:15.585421+01:00
sensor.fibaro_system_fgwpe_f_wall_plug_gen5_power_9 | 2019-12-18 10:57:15 | 2019-12-18T10:57:15.208720+01:00 | 0.0          |
                                                    | 2019-12-18 11:57:15 | 2019-12-18T11:57:15.229153+01:00 | 0.0          |
                                                    | 2019-12-18 12:57:15 | 2019-12-18T12:57:15.228134+01:00 | 0.0          |
                                                    | 2019-12-18 13:57:15 | 2019-12-18T13:57:15.248665+01:00 | 0.0          |
                                                    | 2019-12-18 14:57:15 | 2019-12-18T14:57:15.288768+01:00 | 0.0          |
                                                    | 2019-12-18 15:57:15 | 2019-12-18T15:57:15.304776+01:00 | 0.0          |
                                                    | 2019-12-18 16:57:15 | 2019-12-18T16:57:15.319338+01:00 | 0.0          |
                                                    | 2019-12-18 17:57:15 | 2019-12-18T17:57:15.348459+01:00 | 0.0          |
                                                    | 2019-12-18 18:57:15 | 2019-12-18T18:57:15.363387+01:00 | 0.0          |
                                                    | 2019-12-18 19:57:15 | 2019-12-18T19:57:15.382370+01:00 | 0.0          |
                                                    | 2019-12-18 20:57:15 | 2019-12-18T20:57:15.406767+01:00 | 0.0          |

Let me know if you need anything else.

[pnbruckner (Phil)]

No, that solves the mystery. The automation is getting turned off and back on. This causes the trigger to reinitialize, which means the first state change of the sensor after that that satisfies the “below: 1” parameter will cause it to trigger. And sure enough, that’s what’s happening.

So why is the automation getting turned off and back on?