1st automation trigger

[flowersrj (Rich F)]

To create my 1st automation on a SonoffSV device using Tasmota to announce when garage door moves is:

- id: garage_door
  alias: garage movement
  trigger:
  - entity_id: mqtt
    topic: 'stat/GarageDoor/POWER'
    from: ON
    platform: state
    to: OFF
  condition: []
  action:
  - service: notify.alexa_media
    data:
      target:
      - media_player.garage_dot
      - media_player.computer_room_dot
      message: Attention.  Garage door moving.
      data:
        type: tts
  mode: single

I get error below in Log viewer when I use CONFIGURATION -> AUTOMATIONS -> EXECUTE to test it. I think its due to the TRIGGER portion because if I substitute portion below at very bottom it seems to works ok.

File “/usr/src/homeassistant/homeassistant/components/notify/init.py”, line 149, in _async_notify_message_service
await self.async_send_message(**kwargs)
File “/config/custom_components/alexa_media/notify.py”, line 195, in async_send_message
for target in targets:
TypeError: ‘NoneType’ object is not iterable

  trigger:
  - entity_id: cover.garagedoor
    from: OFF
    platform: state
    to: ON

Any clue on where I went wrong?

Thanks,
Rich FR

[123 (Taras)]

That error message isn’t complaining about the automation’s trigger. It has a problem with sending the notification via alexa_media.

@flowersrj

File “/config/custom_components/alexa_media/notify.py”, line 195, in async_send_message
for target in targets:
TypeError: ‘NoneType’ object is not iterable

[flowersrj (Rich F)]

Taras,

Why do you think that it would not throw that error if I change just the trigger portion of the automation?

Rich F

[123 (Taras)]

An MQTT Trigger doesn’t support from and to options.

The State Trigger you posted is using unusual values for a cover entity. Go to Developer Tools > States, find cover.garagedoor and check its state value. Normally it will be closed or open (not OFF or ON).

When you manually trigger an automation (the way you explained you did) it skips the automation’s trigger (and condition, if any) and simply executes the action.

The error message you got was produced exclusively by the execution of the action. That’s why I said the error message isn’t complaining about the trigger; it is clearly reporting a problem when it tried to perform the notifiy.alexa_media service call.

I don’t know why it stumbled during the service call. Alexa Media is a custom integration and I have no experience with it. When I compare it to other examples, such as this one, it appears to have the same structure except for the indentation of the media_players (you can indent them by an additional two spaces but I doubt it has any bearing).

[flowersrj (Rich F)]

Taras,

Actually I think the TO: attribute should be PAYLOAD: instead. Errors are now gone but automation not firing when I press garage remote. Nothing in LogBook either.

I followed this YT tutorial in defining everything. link

This pic from Sonoff SV console.
1st to 2nd two blue lines represent device reset
2nd to 3rd blue lines represent open of door
3rd to 4th blue lines represent close of door

Just not sure of TOPIC and PAYLOAD values to use.

Here is automation script currently

Rich F

[123 (Taras)]

@flowersrj

Actually I think the TO: attribute should be PAYLOAD: instead.

As I said, the to option is not supported by MQTT Trigger.

The minimum requirement for MQTT Trigger is the topic option. The following will trigger when any payload is published to the specified topic.

  trigger:
  - platform: mqtt
    topic: living_room/switch/ac

By adding the payload option, it will trigger only when the specified payload is published to the topic.

  trigger:
  - platform: mqtt
    topic: living_room/switch/ac
    payload: 'on'

---

EDIT

What is the purpose of the condition in your automation? As written, your automation works like this:

• Trigger when closed is published to stat/GarageDoor/status
• Check if the relay has been on for a period of at least 10 seconds (i.e. relay was on 10 seconds prior to the trigger).
• Send a notification.

[flowersrj (Rich F)]

I thought the 10 seconds referred to AFTER not BEFORE. I thought negative numbers represented BEFORE.

I included printscreens of the console so as to determine if for the PAYLOAD response of ‘ON’ is sufficient or do I need some kind of RegEx formula as the MQTT lines aren’t a simple ON or OFF as seen below

1st to 2nd blue line is a reset
2nd to 3rd line is a door open
3rd to 4th line is a door closed

Rich F

[123 (Taras)]

@flowersrj

I thought the 10 seconds referred to AFTER not BEFORE.

When you specify for in a State Condition (or Device Condition) you are indicating the state value must be unchanged for the specified time. That means at the moment the condition is evaluated, the state of the relay must be on for at least 10 seconds. It’s not going to wait 10 seconds for the relay’s state to be on, it must be on for at least the past 10 seconds.

@flowersrj

the MQTT lines aren’t a simple ON or OFF as seen below

What I see is that the payload published to stat/GarageDoor/status is a simple string value and is either open or closed. In addition, the payload is published as a retained message (meaning the value is stored by the MQTT broker).

The payload published to stat/GarageDoor/SWITCH2 is a JSON string value and is either {"STATE":"ON"} or {"STATE":"OFF"} (and is not published as a retained message). If you choose to use this topic, you can interpret its payload (in a Template Condition) using trigger.payload_json (see documentation).

---

FWIW, what I would do is create an MQTT Binary Sensor that represents the garage door.

  - platform: mqtt
    name: 'Garage Door'
    state_topic: stat/GarageDoor/status
    payload_on: 'open'
    payload_off: 'closed'
    device_class: garage_door

Then the automation’s trigger can use a simple State Trigger. For example, this triggers when the door is closed:

- alias: Example
  trigger:
  - platform: state
    entity_id: binary_sensor.garage_door
    to: 'off'

  ... etc ...

[flowersrj (Rich F)]

Taras,

OK weird stuff has happened. Here is Logbook printscreen for the following:

1. restarted ha
2. pressed remote to open garage door (no message from Alexa)
3. went to Developer Tools -> cover.Garage_door
   pressed button (door closed, no message from Alexa)

SVrelay1 is friendly name shown in Tasmota software.

Is there a way to tell if an automation triggered or if condition was met or not?

Here is my relevant configuration.yaml so u can see if I entered it correctly

Here is relevant automations.yaml code

[flowersrj (Rich F)]

Taras,

One small change, had to select binary sensor for trigger but pretty much same results. No automation selected in logbook except when I execute it manually.

Rich F

[flowersrj (Rich F)]

Installed MQTT Explorer to see what I can learn.

Rich F

[flowersrj (Rich F)]

Learned this:

Two at rest scenarios are when no door movement and door remote is not held

• when reed switch halves are in contact (meaning door is shut)
  stat/GarageDoor/POWER = ‘OFF’
  stat/GarageDoor/status = ‘closed’

• when reed switch halves are not in contact (meaning door is open)
  stat/GarageDoor/POWER = ‘OFF’
  stat/GarageDoor/status = ‘open’

So, possible actions when remote button is pressed

action 1 -> stat/GarageDoor/POWER goes to 'ON' for a moment or two then
            stat/GarageDoor/status becomes 'open' when door stops
                                 

action 2 -> stat/GarageDoor/POWER goes to 'ON' for a moment or two then
            stat/GarageDoor/status becomes 'closed' when door stops

Now I need to understand your binary sensor code.

Rich F

[123 (Taras)]

@flowersrj

Here is my relevant configuration.yaml so u can see if I entered it correctly

Up until your most recent post, there was no mention that you have already defined a cover entity to represent the garage door. Had I known that, I would have not suggested defining a binary_sensor because it’s redundant. The automation can be triggered by the cover’s state.

---

TIP:

Please do not post screenshots of anything that you can copy-paste. Why? Because whoever helps you may have to re-type the text that you posted as a screenshot. For more information, consult the forum’s FAQ, specifically guideline #14:

Screenshots
Sometimes an image is worth a thousand words, and including a screenshot (or a link to one hosted elsewhere) can help. Don’t do that for anything you can copy and paste from your configuration, YAML, code, or logs. Please only include screenshots that are actually helpful.

---

Suggestion

Try the following simple automation that reports the garage door’s state as a persistent notification. Do not add any conditions to it and do not test it by manually triggering the automation (there is no Trigger State Object when you do that so trigger.to_state.state will be undefined).

- alias: Garage Door Status
  trigger:
  - platform: state
    entity_id: cover.garage_door
  action:
  - service: persistent_notification.create
    data:
      title: "{{ now().timestamp | timestamp_local() }}"
      message: "Garage door is {{trigger.to_state.state}}."

• If it fails to trigger then there’s a problem with the cover’s configuration.
• If it works, add to: 'closed' to the trigger, execute Reload Automations, and test it again; it should only report when the door is closed.
• If that also works, replace the action’s entire service call with yours (alexa_media) and re-test.

[flowersrj (Rich F)]

No notifications appeared under ‘Notifications’ on left margin. I even restarted HA.

The cover values match what was in a YT video that this setup is based on. See the info under the video. link or go directly
to it to see the yaml at link

Here is my Tasmota information again

screen print of automation code you asked me to enter:

[123 (Taras)]

@flowersrj

No notifications appeared under ‘Notifications’ on left margin

In Configuration > Automations check the last_triggered time of the Garage Door Status automation. If it triggered it will indicate when it happened. Given that you reported receiving no persistent notification then it should have no timestamp (i.e. never triggered).

If it failed to trigger then there may be a problem with the configuration of cover.garage_door. Go to Developer Tools > States, find cover.garage_door and observe its state when you operate (open/close) the physical door. Its state should reflect the door’s position. If it fails to do that then it has a configuration error. If it succeeds then you have done something (that I cannot guess) which is causing the automation’s trigger from working nominally. Review Configuration > Logs for any errors.

[flowersrj (Rich F)]

Taras,

I woke up this morning and saw this in HA under Notifications.

When I go to CONFIGURATION -> AUTOMATIONS, the automation last fired at 6:38am EST. That is about the time my wife used the garage.

I was still in bed at that time and watched the door on my android HA app. I saw door open then a minute later I saw it close on the Lovelace card.

Here is logbook image which registers your automation firing.

Rich F

[123 (Taras)]

That’s good news because it means cover.garage_door is properly configured and is reporting its state (open/closed) correctly. The State Trigger is detecting the cover’s state-changes and reporting them as a persistent notification.

Don’t be concerned by the notification’s strange title. That’s due to a syntax error I made in the suggested automation. The template should be this :

title: "{{ now().timestamp() | timestamp_local() }}"

Anyway, at this point you should feel confident to use the same State Trigger in your original automation. The only question remains is if the service call to Alexa Media will work.

- id: testingthis
  alias: Garage Door Status
  trigger:
  - platform: state
    entity_id: cover.garage_door
  condition: []
  action:
  - service: notify.alexa_media
    data:
      target:
        - media_player.garage_dot
        - media_player.computer_room_dot
      message: 'Attention. Garage door is {{ trigger.to_state.state }}.'
      data:
        type: tts
  mode: single

If the announcement works, great! If not, and it produces the original message, then there’s definitely an issue with Alexa Media.

[flowersrj (Rich F)]

Taras,

We (I mean you) were so close. Something’s not right.

Do you see anything?

I added your 2nd automation to bottom thru editor and fixed your 1st automation with code in email.

Rich F

Almost forgot. I wiped out binary_sensor definition so I had to put it back into configuration.yaml

[flowersrj (Rich F)]

Found it !! state_topic: was mistyped as topic:

[123 (Taras)]

Did you get a chance to test the latest automation I posted? I see from your screenshot that you have included it as “Garage Door Status 2 - 2/21”. Does it announce the garage door’s state or does it fail?