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
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'
What is the purpose of the condition in your automation? As written, your automation works like this:
closed is published to stat/GarageDoor/statuson for a period of at least 10 seconds (i.e. relay was on 10 seconds prior to the trigger).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
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.
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 ...
Taras,
OK weird stuff has happened. Here is Logbook printscreen for the following:
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
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
Installed MQTT Explorer to see what I can learn.
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
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.
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.
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}}."
to: 'closed' to the trigger, execute Reload Automations, and test it again; it should only report when the door is closed.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:
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.
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
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.
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
Found it !! state_topic: was mistyped as topic:
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?
Taras,
Sorry, I got sidetracked with an email from a newly discovered distant relative in Brisbane, Australia. I live outside Pittsburgh, PA, USA.
I am ecstatic to report that it works both stating when door has opened and also when it is closed.
You are a bulldog of a genius-ness in being able to get it to work.
I had been waiting to hear from you that you had exhausted all ideas on how to resolve it.
Rich F
Glad to hear it works (and you’ve discovered a distant relative).
Please consider marking my post (above; containing the final working automation) with the Solution tag (only one post in the thread can have this tag). It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has an accepted solution (I.e. it’s resolved). It will also put a link below your first post that leads to the solution post. All of this helps other users find answers to similar questions.
Taras,
Glad to do it, and again, I appreciate your time spent on this.
If you don’t mind, where do you hail from(live)?
Take care,
Rich F
I’m glad we managed to get the thing to work. It took a few twists and turns but we finally got there.
If you click on my user icon, it’ll reveal I hail from Canada.
