Event triggering tracking in logs

Phil, any comment on the likely effectiveness of this?

We got sidetracked from the original problem (nothing to do with mqtt).

First, template sensors are not restored after a restart. They only update when the referenced entity or entities update(s.)

Regarding the template trigger, it would act the same was as a numeric_state trigger. The first update of the reference entity will cause it to evaluate, If true it will fire. After that it has to become not true, and then back to true to fire again.

So, not sure changing to a template sensor & using that in a trigger would matter. If you really don’t want that first transition to cause the automation to run:

condition:
- condition: template
  value_template: "{{ trigger.from_state is not none }}"
2 Likes

Thanks. The only issue with that solution would be if there was a restart just before the trigger is due (less likely than the previous issue of restarting after sunset) which would cause a valid trigger to be missed.

Well. I have changed it to exam a sensor.sun_angle instead… will see.

But what worry me is the fact it happened first time for last 7 months I use these automation. I also was experimenting with home-assistant_v2.db yesterday, purging, deleting due to another issue

Could the changes in the db cause misfiring my shutter automation?

it has just executed the triggers again!!!

right after restart the sensor is ‘unknown’
ha-c

This is exactly what I pointed out to you many posts ago. You then went off on a tangent about mqtt.

Phil pointed out a solution that will work as long as you don’t restart within a few minutes of sunset.

Can not catch the None condition. I created a testing automation to see trigger states. But it is confusing.

- alias: sun angle below30 test
  trigger:
    platform: numeric_state
    entity_id: sensor.solar_angle
    below: 1.2
  action:
    service: persistent_notification.create
    data_template:
      message: >
        Trigger from {{ states('trigger.from_state') }}
        to {{ states('trigger.to_state') }}
        sensor.solar_angle {{ states('sensor.solar_angle') }}

After a restart and fist change of solar_angle the trigger was fired and returned this msg

Trigger from unknown to unknown sensor.solar_angle 0.49

Why does it return from_state and to_state as unknown?

Don’t put the trigger variables in calls to the states function.

data_template:
      message: >
        Trigger from {{ trigger.from_state }}
        to {{ states('trigger.to_state') }}
        sensor.solar_angle_simulator- {{ states('sensor.solar_angle') }}

then it says:

  • sun angle below30 test: Error executing script. Unexpected error for call_service at pos 1: Error rendering data template: UndefinedError: ‘trigger’ is undefined

Please don’t post snippets. Oftentimes the problem is in another part of the automation you didn’t see.

Going back to what you posted earlier, I meant to change it to this (I was replying from my phone so I couldn’t easily do this):

- alias: sun angle below30 test
  trigger:
    platform: numeric_state
    entity_id: sensor.solar_angle
    below: 1.2
  action:
    service: persistent_notification.create
    data_template:
      message: >
        Trigger from {{ trigger.from_state }}
        to {{ trigger.to_state }}
        sensor.solar_angle {{ trigger.to_state.state }}

Got the msg from the automation right after the reboot. trigger.from_state is not None:

Trigger from <state sensor.solar_angle=-33.98; unit_of_measurement=degrees, friendly_name=Sun angle @ 2020-09-02T23:50:39.152834+02:00> to <state sensor.solar_angle=-34.77; unit_of_measurement=degrees, friendly_name=Sun angle @ 2020-09-03T00:09:02.196024+02:00> sensor.solar_angle -34.77

Also, I used sun.sun entity instead of a sensor. Seems Hassio restores last state and there is no None “state” for the trigger when it fires with a first change of elevation attribute.

Trigger from <state sun.sun=above_horizon; next_dawn=2020-09-04T03:35:02+00:00, next_dusk=2020-09-03T17:52:59+00:00, next_midnight=2020-09-03T22:42:50+00:00, next_noon=2020-09-04T10:42:58+00:00, next_rising=2020-09-04T04:06:40+00:00, next_setting=2020-09-03T17:21:15+00:00, elevation=43.24, azimuth=218.96, rising=False, friendly_name=Sun @ 2020-09-03T14:32:56.617650+02:00> to <state sun.sun=above_horizon; next_dawn=2020-09-04T03:35:02+00:00, next_dusk=2020-09-03T17:52:59+00:00, next_midnight=2020-09-03T22:42:50+00:00, next_noon=2020-09-04T10:42:58+00:00, next_rising=2020-09-04T04:06:40+00:00, next_setting=2020-09-03T17:21:15+00:00, elevation=42.81, azimuth=220.18, rising=False, friendly_name=Sun @ 2020-09-03T14:32:56.617650+02:00> sensor.solar_angle above_horizon

Just to close this ghost automation trigger case.
After a number of experiments the solution I found working to me is using condition as below. Also, in the automation I cannot use sun.sun attribute ‘elevation’ from trigger.from_state because it returns a data structure. As such I need to use a sensor.

- alias: Close all shutters
  trigger:
    platform: numeric_state
    entity_id: sensor.solar_angle
    below: -5
  condition:
  - condition: template
    value_template: "{{ ((trigger.from_state.state)|float) > ((trigger.below)|float) }}"
  action:
  - service: cover.close_cover
    entity_id: cover.window_shutter_00

Also, I find it very strange that there is no way to avoid execution of an automation right after HA reboot in standard way (for example, via some parameters). But I look at this rather as a bug because usage ‘elevation’ is in HA documentation with an example I copy-paste.