I recently automated my garage door with a mqtt relay and am having issues with it opening when I do not want it to. I only want this automation to fire when the garage door is closed, hence the condition. However, for whatever reason this condition doesn’t stop it from firing, am I missing something? I have it setup the same as others that work fine but for some reason this wouldn’t work.
- alias: Garage Open Home
initial_state: 'off'
trigger:
- entity_id:
- binary_sensor.brittany_home
platform: state
to: 'on'
condition:
- condition: state
entity_id: cover.garage_door
state: 'closed'
action:
- data:
entity_id: cover.garage_door
service: cover.open_cover
- delay: '00:10:00'
- service: cover.close_cover
entity_id: cover.garage_door
Could you follow the instructions in the large blue box at the top of the page (and every page) and apply code markup please. Without that it’s impossible for people to follow your automation as the formatting is lost.
Apparently I’m an idiot or the instructions are no good for the code markdown. I tried before your comment and after to use the code markdown instructions at the top of the page, and can’t seem to make it work correctly. Here it is from pastebin, which I know how to use.
Hard to say then. Could be that other automations is altering cover.garage_door state on similar trigger?
Only way is to debug. If you have telegram notifications set up you could simply add
- service: notify.your_telegram
data_template:
message: "Garage door state is {{ states.cover.garage_door.state }}"
at the beginning of action and reload automations to avoid rebooting HA.
State is always “unknown” on a reboot or reload until the sensors for open/close register. I’m going to do some more testing today and report back. Thanks.
State being unknown explains why your automation works despite conditions for the first time after reboot but next time automation should skip.
You should add some automation that triggers all devices to report their state on HA startup.
Mine as example:
- alias: "Sync power state on HA start-up"
trigger:
platform: homeassistant
event: start
action:
- service: mqtt.publish
data:
topic: "cmnd/sonoffs/power1"
payload: ""
- service: mqtt.publish
data:
topic: "cmnd/fridge_doors/event"
payload: "ReportDoorsState"
- service: mqtt.publish
data:
topic: "cmnd/sonoff5/event"
payload: "ReportSensorsState"
Thanks for that, although I’m unsure how to do something similar with this. The garage door open and close is based on a rf device on sonoff rf bridge. Which only sends the code when triggered. So I suppose I need to figure out how to poll it at startup. Or store the state.
I was probably too vague on this.
I have devices (mostly Sonoff Basic) flashed with Tasmota firmware which allows to write additional logic via rules. Rules are quite stiff at the moment but in my case I have managed to add some functionality I wanted.
I get up to date powerstate with “cmnd/sonoffs/power1” and I write some simple rule to get sensor data upon HA starting up. Rules differ for each device based on context.
For example to get DHT22 a la SI7021(normally reported with tele messages) sensor data on demand I did following:
Add rule and enable it on device in Tasmota console
rule1 on tele-SI7021#temperature do var1 %value% endon on tele-SI7021#humidity do var2 %value% endon on event#ReportSensorsState do publish tele/sonoff5/SENSOR {"SI7021":{"Temperature":%var1%,"Humidity":%var2%}} endon
rule1 1
What it does is save last sensor values in memory and returns them when event ReportSensorsState occurs in same topic and similar json as MQTT sensors expect.
Add action that publishes ReportSensorsState event in syncing automation
That is very helpful. I’m going to explore it. Could you show me the logic you are using for the “fridge door state” that you have above? Seems very applicable.
Thinking a little more about this, there must be a relatively easy way to store the values in HA. Although at the moment I’m not sure how.
Fridge doors sensors are Wemos D1 mini with MC-38 magnetic door sensors configured as switches in Tasmota with separate MQTT topic for each of them.
Following rule takes care of both reporting actual doors state and reporting state on demand.
on Switch1#State do backlog var1 %value%; event ReportUpperDoorState endon on Switch2#State do backlog var2 %value%; event ReportLowerDoorState endon on Event#ReportDoorsState do backlog event ReportUpperDoorState; event ReportLowerDoorState endon on Event#ReportUpperDoorState do publish stat/fridge_doors/upper %var1% endon on Event#ReportLowerDoorState do publish stat/fridge_doors/lower %var2% endon
This rule should be improved to also cover use case to report sensors state on Wemos System#Boot event to make it universal and to avoid situations where de facto state has changed while something any of components were down for any reason.
But I haven`t had a time and inner strength to do that yet
Also, how is your binary_sensor.brittany_home defined? If it’s an Smartphone Presence Detection via Wifi, then it could be the device reconnecting to the Wifi Network firing the automation as well.
It certainly has something to do with mqtt retain. I’ve watched robs video before, but I’m not sure that it pertains to a “value template” setup like this. If I knew how to set that up to be sure it retained, I would.
As far as the presence detection is concerned, that is not the issue. It’s a Bayesian sensor that is absolutely rock solid. It combines Bluetooth, WiFi, and gps. I spent a lot of time to make it 100%, and it is.
