Automation not triggerred

[chemelli (Simone Chemelli)]

Hi,

trying to setup an automation to detect when my device restart.
Extract from automations.yaml:

- id: '1577969487121'
  alias: Shelly availability
  trigger:
  - below: 100
    entity_id:
    - sensor.shelly_shsw_25_xxxxxx_uptime_attr
    - sensor.shelly_shsw_25_xxxxxy_uptime_attr
    - sensor.shelly_shsw_25_xxxxyx_uptime_attr
    platform: numeric_state
  action:
  - data_template:
      message: 'Shelly restarted: {{trigger.below.friendly_name}}'
      title: Shelly availability (HA)
    service: notify.mail_send
  - data_template:
      message: 'Shelly restarted: {{trigger.below.friendly_name}}'
    service: system_log.write

Based on several eamples I found, seems code is fine but obviously it’s not.

Anyone that can help a noobie ?
I’m more interested in understanding what’s wrong and why than in the fix itself.

Simone

[pnbruckner (Phil)]

The automation should trigger whenever one of the entities’ state changes and its state, as interpreted as a number, is below 100. Then, for that entity, it will not trigger again until the state becomes 100 or above, and then goes below 100 again.

As for the action, trigger.below.friendly_name is not valid. You might want either trigger.to_state.attributes.friendly_name, or more simply, trigger.to_state.name. See the trigger variable for the numeric_state trigger, and State Objects for more details.

[chemelli (Simone Chemelli)]

Hi @pnbruckner,

thank you for your answer.

The issue is that when “sensor.shelly_shsw_25_xxxxxx_uptime_attr” shows 26 in UI, automation is not triggered. I set debug log level for automations, but nothing is recorded.

About the action, I saw in that page that “trigger.below” is a valid template variable. As much as “trigger.to_state”. Where am I wrong ?

Looking forward for your kind feeback.

Simone

[pnbruckner (Phil)]

@chemelli

The issue is that when “sensor.shelly_shsw_25_xxxxxx_uptime_attr” shows 26 in UI, automation is not triggered.

The trigger can only “fire” when the entity changes state. (To say that another way, the automation trigger is only evaluated when the entity changes state.) If the sensor is initialized, and has a value below 100, before the automation is initialized (which is common), then the automation won’t fire because the entity isn’t changing state. The entity has to cause a state_changed event before the automation trigger will be evaluated and possibly fire.

@chemelli

About the action, I saw in that page that “trigger.below” is a valid template variable. As much as “trigger.to_state”. Where am I wrong ?

Yes, you are correct, in that they are both valid. trigger.below will be a float, and trigger.to_state will be a State Object.

But trigger.below.friendly_name is not valid, because a float does not have an attribute named friendly_name.

[chemelli (Simone Chemelli)]

@pnbruckner

The trigger can only “fire” when the entity changes state. (To say that another way, the automation trigger is only evaluated when the entity changes state.) If the sensor is initialized, and has a value below 100, before the automation is initialized (which is common), then the automation won’t fire because the entity isn’t changing state. The entity has to cause a state_changed event before the automation trigger will be evaluated and possibly fire.

My test was to restart HA, and after I get the trigger initialized event in the log restart the device.
But still automation is not fired

Any more ideas ?

Simone

[Tinkerer (aka DubhAd on GitHub)]

It has to start with the value at 100 or above and then go below 100.

Starting below 100 won’t cause it to trigger.

[pnbruckner (Phil)]

@chemelli

restart the device

What do you mean by that? Does this cause a state_changed event for the entities listed in the trigger? If not, then that explains why the automation isn’t triggering.

@Tinkerer

It has to start with the value at 100 or above and then go below 100 .

Starting below 100 won’t cause it to trigger.

That’s actually not true. It’s slightly more complicated than that. The way the trigger works is, first and foremost, it is only evaluated when a listed entity changes state (i.e., generates a state_changed event.) The first time it changes, if the below and/or above parameters are satisfied (in this case, is below 100), it will fire. After that the parameters must not be satisfied, and then satisfied again, before it will trigger again.

So it’s possible to trigger without “crossing the boundary”, but only if the above/below parameters are satisfied the first time the entity changes state after the automation is initialized.

[123 (Taras)]

@pnbruckner

That’s actually not true. It’s slightly more complicated than that.

Tinkerer’s explanation is precisely how I understand the mechanism works so I eagerly read your description explaining why it’s more complicated than that.

@pnbruckner

The first time it changes (i.e. state_changed event), if the below and/or above parameters are satisfied … it will fire.

If I understood you correctly, you’re suggesting there’s a possibility it can trigger even without crossing the threshold? Can you elaborate on what you mean the first state_changed event? Is it the first after startup?

I’m having trouble picturing how it could trigger even if it did not cross the threshold of 100.

[chemelli (Simone Chemelli)]

@pnbruckner

What do you mean by that? Does this cause a state_changed event for the entities listed in the trigger? If not, then that explains why the automation isn’t triggering.

How can I know if the reboot of the device cause a status_changed event ? And furthermore, how can I know all the event this kind of device is able to cause ?

Simone

[chemelli (Simone Chemelli)]

@chemelli

How can I know if the reboot of the device cause a status_changed event ? And furthermore, how can I know all the event this kind of device is able to cause ?

Simone

Ok, seems I’m finding my way: history shows a status change for some others entity_ids, not the one I choiced
So I updated my code to:

- id: '1577969487122'
  alias: Shelly cloud status
  trigger:
  - from: 'connected'
    entity_id:
    - sensor.shelly_shsw_25_xxxxxx_cloud_status_attr
    - sensor.shelly_shsw_25_xxxxyx_cloud_status_attr
    - sensor.shelly_shsw_25_xxxxxy_cloud_status_attr
    platform: state
  action:
  - data_template:
      message: 'Shelly {{trigger.to_state.name}} move to state {{trigger.to_state}}'
      title: HA Notification - Shelly cloud status
    service: notify.mail_send
  - data_template:
      message: 'Shelly {{trigger.to_state.name}} move to state {{trigger.to_state}}'
    service: system_log.write

Should I now be able to detect each time status change from “connected” to something else ?

Simone

[rccoleman (Rob Coleman)]

If I understood you correctly, you’re suggesting there’s a possibility it can trigger even without crossing the threshold? Can you elaborate on what you mean the first state_changed event? Is it the first after startup?

He said:

So it’s possible to trigger without “crossing the boundary”, but only if the above / below parameters are satisfied the first time the entity changes state after the automation is initialized.

So, after boot, when the automations are reloaded, when the automation is disabled and reenabled, maybe other times.

[123 (Taras)]

@rccoleman

So, after boot, when the automations are reloaded, when the automation is disabled and reenabled, maybe other times.

I can understand how changing from unknown, or unavailable, to 99 would constitute a state_changed event that could satisfy the trigger’s requirements.

Can someone explain how disabling/enabling an automation could do that?

[pnbruckner (Phil)]

If you really want to know how it works, just read the code.

Before I explain this in a bit more depth, I’ll state I don’t necessarily agree that it should work this way. I didn’t write it originally. I’m just trying to explain how it currently works…

Basically, for each entity listed in entity_id, it effectively maintains a flag that indicates whether or not a change of state for that entity has caused the automation to trigger, which is initialized to False when the automation is initialized. (I say effectively because the implementation is actually a list, but that’s not really important.) As @rccoleman pointed out, the automation is initialized when HA starts, but also when automations are reloaded, or when an individual automation is turned off and back on. So when these things happen all the “flags” are reset to False.

Next, as I mentioned earlier, the triggers are only evaluated when an entity changes state. This could be when the “state string” changes, or even when only one of the attributes changes. Or it could even be when nothing in the entity’s state changes (if that entity “forces” state changes.) Technically this is when a state_changed event is fired for the entity.

So, when an entity changes state, its numeric value will be compared against the above and/or below parameters. If it meets the requirements, and the flag has not yet been set [which is the case after the automation has been (re)-initialized], the trigger will “fire,” and the flag for that entity will be set. This prevents future state changes for that entity that meet the requirements from re-triggering the automation until a state change that does not meet the requirements resets the flag, after which the next state change for that entity that does meet the requirements will trigger the automation again.

I think the original goal was probably to prevent successive state changes that all meet the requirements from causing multiple triggers. It’s been described as requiring “the boundary to be crossed”, but that’s not really how it works.

It’s also worth noting that a state which cannot be interpreted as a number will also reset/clear the flag. So, in this example (w/ “below: 100”), the following sequence of states:

99, unknown, 99, 99, unavailable, 99, 98, 1, 100, 50

would cause 4 triggers.

[123 (Taras)]

Thank you for the detailed explanation. It appears that the “flags” mechanism is responsible for the ‘more complicated’ triggering behavior. Because the automation gets reset at the time the it is first loaded/enabled, it allows for ‘edge-case’ triggers, like changing state from unknown to 99.

In other words, a restart or re-enabling of an automation ‘clears its slate’ and it allows it to be triggered by the kind of state-changes we don’t normally think about.

[chemelli (Simone Chemelli)]

Hi, my final config that seems to work quite fine:

- id: '1577969487121'
  alias: Shelly uptime
  trigger:
  - below: 100
    entity_id:
     - sensor.shelly_shsw_25_xxxxxx_uptime_attr
     - sensor.shelly_shsw_25_yyyyyy_uptime_attr
    platform: numeric_state
  action:
  - data_template:
      message: 'Shelly {{trigger.to_state.name}} restarted; uptime is {{trigger.to_state.attributes.uptime}}'
      title: HA Notification - Shelly uptime
    service: notify.mail_send
  - data_template:
      message: 'Shelly {{trigger.to_state.name}} restarted; uptime is {{trigger.to_state.attributes.uptime}}'
    service: system_log.write
- id: '1577969487122'
  alias: Shelly cloud status
  trigger:
  - from: 'connected'
    entity_id:
     - sensor.shelly_shsw_25_xxxxxx_cloud_status_attr
     - sensor.shelly_shsw_25_yyyyyy_cloud_status_attr
    platform: state
  action:
  - data_template:
      message: 'Shelly {{trigger.to_state.name}} move to state {{trigger.to_state.attributes.cloud_status}}'
      title: HA Notification - Shelly cloud status
    service: notify.mail_send
  - data_template:
      message: 'Shelly {{trigger.to_state.name}} move to state {{trigger.to_state.attributes.cloud_status}}'
    service: system_log.write

I asked the author of the integration to improve the generation of the state_changed.

Thank you for your great help.
See you,

Simone