I have some 433MHz door and window sensors all connected to a Tasmotized Sonoff RF Bridge. These sensors all work perfectly and send a message when open and a different one when closed. They are all configured as shown below.
My question is regarding their state when restarting HA. As I understand it they should all return a state of ‘unavailable’ but mine all return ‘Closed’. am I missing something that explains this?
And:
The reason I discovered that my sensors were apparently behaving unexpectedly was because I asked in another post how others managed the fact that these sensors cannot be forced to retain their state following a restart. There must surely be a way around this, how else would people use them as the basis of alarm systems? The only way I can think of is the horrible kludge of saving the binary sensor state into an input boolean every time it changes. Again, am I missing something?
You need to define the availability topic and payload (and send the corresponding message) for the state to be noted as unavailable
This is normally done be setting the retain flag on the state messages. The broker then retains the message in its database and sends it to all clients that subsequently subscribe to the topic. I don’t have tasmota, so can’t tell you how, but I’m sure it allows you to set the retain flag.
binary_sensor:
- platform: mqtt
name: "Door1"
state_topic: "433/Door1"
device_class: Door
The availability topic mentioned by @gpbenton doesn’t work as expected in this case because the 433Mhz devices connect THROUGH the Sonoff RF Bridge and the availability topic would only tell you if the bridge is online, not the most recent status from that particular 433Mhz device.
The downside to this setup, and any device that doesn’t retain it’s own state, is that if the state changes while HASS is down, HASS won’t know about it until the state changes again. So… if the door is open and then you stop HASS and close the door, when you start HASS again, it’ll still see the door as open.
Yes I guess there can be no perfect solution given the sensors are entirely passive and respond to the outside world rather than actually sensing it. But your solution is a big improvement. Thanks again.
Yes… but the Sonoff RF Bridge (or any other RF/IR listening device like the Broadlink devices, Xiaomi IR transceivers, or the “roll your own” ESP8266 based sensors like the OpenMQTTGateway), is a device that listens for other devices. And those other devices don’t connect through MQTT nor do they announce their availability to the Sonoff RF Bridge. So the availability topic would tell you if the Sonoff RF bridge was available. But it wouldn’t tell you if a particular RF device was available. And since each RF device’s trigger is simply seen as a different code to the Sonoff RF bridge, there’s no way to know the availability of any particular RF device without adding data retention (as the MQTT republishing automation I showed above does).
So, while the availability topic can indicate whether RF codes can be received at all, it wouldn’t indicate the previous state of any particular RF device.
For a more complete sensor, each RF device, using the binary_sensor YAML I showed above, could include the availability topic of the RF Bridge. This way, if the RF bridge did go offline, those sensors would show as unavailable as well. But it wouldn’t handle the OPs case of wanting to either see “unavailable” on this particular sensor or the last known state whenever HASS is restarted. When HASS is restarted the availability of the RF Bridge would be “online”, but HASS would have no idea what the state for that particular device was.
As I mentioned, because the RF devices themselves cannot generally handle a state request, this setup isn’t 100% perfect. There CAN be times when the state in HASS/MQTT is incorrect regarding the RF device. These cases include: if the RF Bridge is stopped/restarting when the RF device transmits a new state, if HASS is stopped/restarting when the RF Bridge publishes a new state (though this case could be corrected by moving the MQTT republishing to a process outside of HASS), or if the transmission from the RF Device was not received by the RF Bridge for whatever reason (interference, too many transmissions at once, device out of range, etc).
Dealing with these RF Devices is a different beast entirely because, essentially, they always run in what HASS calls “assumed state” mode. And, with “assumed state” comes “assumed availability”.
I tried this and the condition is not working. I decide that was because payload contains several elements so I tried
- condition: template
value_template: "{{ trigger.value_json.RfReceived.Data in ('DC5F0A','DC5F0E') }}"
but that didn’t work either.
I tried removing the condition altogether and it always published ‘OFF’ which also implies that trigger.payload or trigger.value_json.RfReceived.Data are not the correct thing to be using.
and the fdoor is a typo but only in this post. I copied and pasted my config and then edited it here to make it more generic. Probably not the best decision in hindsight.
I’ll keep playing with it but if you have any further suggestions I’d be grateful.
It’s not just HASS, I use hassio and it takes forever to restart. It really ca put you off changing anything especially if you want to experiment. And typos are very costly! I’m showing my age here but it reminds me of the old days when we had to submit a job just to compile our programs let alone test them and wait for the next day to see the output!!
Anyway, thanks I really appreciate your help. Give me a day or two and I might have tried this again
This thread is exactly what I was looking for. I noticed the same thing because I set my house up with 433MHz door and window sensors and every time I opened up all the windows in the house and did a home assistant restart I’d lose the states of the windows, they’d all return to “Closed” even though they were really open. @swiftlyfalling thank you so much for the MQTT automation suggestion, that makes this solution work VERY well!
@klogg, so I just realized that the 433 door/window sensors I’m using have a low battery code as well as opened/closed. Now I’m trying to figure out how to integrate that code with all my door/window sensor MQTT setups that I got from this thread.
It doesn’t seem to work out nicely since there are now three codes. Using the if/else/endif statement doesn’t make sense and I don’t think that we can set “low battery” for one of the states of door’s binary sensor. It would be nice to set an attribute but I can’t seem to wrap my head around how to do that with the MQTT automation yaml.