Hello all, new to HA but really liking it so far. I recently integrated my Envisalink with HA and have been running into an issue. Whenever I restart HA any binary sensors that were marked on/opened are reverted back to off/closed. Is there anyway to retain the state of the binary sensor state even after a restart?
So after a lot of research I am not the only one with this issue. There seems to be a multitude of ways to solve this issue, most of which are above my skill level. I have narrowed it down to two possible solutions one being input_booleans and the other a custom component called Saver.
Input booleans seem like the easiest way to solve this, but I am a bit confused on how to use them. Would I set an automation to trigger every time the binary_sensor state changes, and have the input boolean match that state. Then have another automation set to set the state of the binary_sensor based on the state of the input boolean after every restart?
It seems like I recently had this same issue on a reboot, however I wasnāt sure if it was an issue that one of the doors was closed during the reboot and so afterwards the pre-reboot state was actually saved but then out of sync after a reboot. I had this problem with some ZigBee devices.
What you describe for using a binary sensor seems right as I understand it.
As you said @pabla, you are not alone.
Which method did you decide to go with in the end?
Bit frustrated with this to be honest. The official binary_sensor.mqtt documentation mentions the retain flag on 3 occasions, but when adding this to my configuration.yaml, it saya that retain is an invalid option.
The system cannot restart because the configuration is not valid: Invalid config for [mqtt]: [retain] is an invalid option for [mqtt]. Check: mqtt->mqtt->binary_sensor->0->retain.
Whilst I appreciate the change in the underlying logic, resulting in the state as unknown, is technically correct, Iāve been trying to piece together a relatively simple āsolutionā to retain its previous state after a reboot, for quite a while now.
I say āsolutionā as I know technically until a message is actually received, unknown is technically correct, but I would prefer to retain the original state, even if inaccurate. I understand the flaw in my logic, but I would prefer to accept this flaw, rather than my 11 binary_sensors report their state as unknown.
In effect, the devil you know rather the devil you donāt.
Alternatively, if someone could provide an example of their configuration.yaml, with a binary_sensor (for a door or window) that will not report its state as unknown, but rather its previous state, upon restart, I donāt believe I would be alone in thanking them.
2 Likes
@HA-Gecko so I donāt recall what your setup is, however, I use Zigbee2MQTT and looking at my devices there is a setting there for āRetainā. I believe this is where at least I need to configure this.
Now, as Iām reading through about that option I believe that has to do with holding on to MQTT messages. And perhaps that is what is really happening under-the-hood. Basically, with retain on the last state message that was received is still available and on startup HA, or Z2M, will be able to read that message still and set the state, otherwise without retaining some of the messages there is no message available for HA/Z2M to pickup to determine the proper state. The following blog post describes this pretty well.
A retained message is a normal MQTT message with the retained flag set to true. The broker stores the last retained message and the corresponding QoS for that topic. Each client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe. The broker stores only one retained message per topic.
So looking at the documentation for Z2M I believe I can set this in Z2M and it will in fact retain the last message with the current state of the device and then after an HA reboot we should see the state immediately set correctly.
Thanks for your reply @timnolte , however my zigbee devices continue to work fine with the ZHA integration as usual.
It was an oversight on my part not to specify I was referring to some 433MHZ GS-WDS07 door and window sensors (these are ones that transmit both an open XXXXA message, as well as a XXXXE close message.
These were then sent to a Sonoff RF bridge flashed with tasmota >> MQTT >> HA
After digging around I found this post, opting for strategy 2 via @123 's Node-Red flow, however I was still unable to have any success. After implementing the node-red flow and adjusting the relevant topics in both the demultiplexer node and within the configuration.yaml, Iām now not able to receive any state change whatsoever.
I may have a look at the input_boolean alternative, although I can see that getting pretty messy with my already preconfigured automations within both HA and Node-Red.
I will update this post if my endeavours prove successful 
Obviously something was configured incorrectly because many users have successfully implemented Strategy 2. Double-check the MQTT topics and the contents of the dictionary you defined in the function node.
I have not found a solution unfortunately. I got close to a solution by using the custom component saver which successfully saved the state of the sensor, but I ran into the issue of setting the state of the same sensor back to its original state. I tried a custom component called setter but it didnāt work as I thought it would. At this point I have given up and will just manually set states of the devices after each restart. A big flaw in HA, never really seen anything like it in any other home automation platforms.
Looks like in your case there is a solution, as others have posted so good luck!
The flaw appears to be with the Envisalink integration because other integrations donāt have a problem ensuring sensor states are supplied correctly on startup. Post the problem you are experiencing as an Issue in the Core repository on GitHub.
@123 I donāt see how that integration has anything to do with the MQTT issue, unless that was originally mentioned in this post and I missed it.
Edit: I see that was in the original post. So my guess is that the integration you are talking about isnāt setting the retain option?
I was under the impression that by default all binary sensors donāt retain their states unless the integration supplies the states after a restart. So in the case of the Envisalink integration is not a bug, more or so a feature that has not been implemented?
A binary sensor, or other entity, created by an integration has its value set by the integration. In other words, on startup, itās the Envisalink integrationās responsibility to set the value of its entities. Itās not Home Assistantās responsibility to manage the states of the Envisalink integrationās entities.
Hm maybe Iāll submit an issue on GitHub and see what comes of it.
What about retaining history ?
Hey guys. Iāll know a way to retain an binary sensor with the help of an helper binary sensor.
I am using this to retain the value for some āproblematicā aqara presence detectors in my zigbee network.
Here is an example which crreates an new binary sensor:
- platform: template
sensors:
presence_detector_toilette_filtered:
friendly_name: "Presence Detector Toilette Filtered"
value_template: >
{% if states('binary_sensor.presence_detector_toilette') in ['unavailable', 'unknown', 'none'] %}
{{ states('binary_sensor.presence_detector_toilette_filtered') }}
{% else %}
{{ states('binary_sensor.presence_detector_toilette') }}
{% endif %}
This binary sensor is used in my /config/binary_sensor.yaml which is included in m< configuration.yaml like this: binary_sensor: !include binary_sensor.yaml
The new sensor presence_detector_toilette_filteredis then used in my automations.
I hope this helps
The devs have missed a trick here. Dumb RF based binary sensors are not going to check in and report their state every time HA is restarted. To expect all smart devices to conform is a fallacy. HA prides its self on being customizable. We should be able to address things not done correctly by manufacturers. This needs a solution within HA.
Hi, did you get anywhere with this?
The cure (as several older threads on the HA forums will tell you) is to enable the RETAIN flag for your MQTT message. There is not a single guide or instruction out there on how exactly to do this. Been looking for days.
I discovered that the Sonoff Bridge Information Page shows a summary of MQTT settings. Strangley, the value for MQTT āNo Retainā is DISABLED. That doesnāt make sense as it implies RETAIN IS enabled? However, as it is for you, all my commands are sent without the RETAIN flag (as seen in MQTT Explorer). And in any case, the config page shows no such check box for retain. The option is a complete mystery.
Use my trick above or configure tasmota to use Publish2 instead of Publish. This way, the retain flag is set in the mqtt publish.