What automation did I use?
I didn’t.
I was suggesting he could update his current automation to resend the message if the broker died. The rest of the automation can be deleted.
All you’re offering are unnecessary band-aids when the solution is to simply use retained messages correctly.
If you send every message retained…
It will work sure.
If HA crashes and 5 hours later I restart it do I want a motion detection from 5 hours ago?
The way I used the retained message was to send 1 single retained message. That is all that ever needed to be sent(excluding broker failure and losing that retained message, which was the automation suggestion)
The rest of the messages can be not retained and what I posted earlier is the result. If the retained message cannot be set on the device. This is the option to use.
I didn’t mean for his automation to be used at all.
While Home Assistant is offline, the broker continues to receive payloads published to topics. Whenever Home Assistant starts, it reconnects to the broker, subscribes to all required topics, and immediately receives the most recently published payload (assuming it was published as a retained message).
The scenario you described requires both Home Assistant and the broker to be offline. jlw52761 would have to let us know if having both offline for long periods of time is a common occurrence in his operating environment.
Well yes I suppose it would actually be the broker failed in that case. Seeing as it’s a separate unit. I was thinking more along the lines of built-in broker and the whole machine crashes.
It was a rhetorical question really.
In some cases I might like to know there was movement detected before a crash, if I was using it for security, I probably would.
If I was using it to set scenes in rooms I want the actual now state, so this would be fine. The movement in the room would start the trigger.
Edit.
So we are clear…
I am presuming the motion sensor only sends ON states. If it never actually sends OFF states, then a retained ON is going to be the last message. It could have been sent many hours ago.
The problem to avoid is having the unknown state. A retained ON would do that, but it could also be stale. Without any retained message the unknown state stays active until there is actually motion as no OFF state is sent. The way I set it up removes the unknown, by setting the state immediately to OFF. Any new messages will be ONs, because ON is all that is ever sent.
That’s why the off_delay resets it to OFF, but it doesn’t reset unknown.
Technically speaking, a state value of unknown isn’t a problem but a truthful report of the current situation. If a binary_sensor entity has not received any information from the device, the entity’s state is neither on or off, it’s unknown; it doesn’t know which of the two nominal states is the actual current state so it reports unknown (this additional state was added several versions ago). The other non-nominal state is unavailable.
To avoid an unknown state on startup, the device must supply the entity with one of the two nominal states. The common method is to ensure the device publishes its state as a retained message. The argument that the value might be “stale” only applies to the atypical situation where the broker has ceased to function for a significant period of time. Otherwise, it works for typical situations like merely restarting Home Assistant and/or the broker.
Where does the Off state come from… If it never publishes Off.
If I was in a room a few hours ago. A retained On is sent.
I restart HA, I get an On state from a few hours ago.
If the device never publishes an “off” message, then the MQTT Binary Sensor should employ the off_delay option. In that specific situation, the use of retained message isn’t recommended. It’s something I explained in a different post related to receiving multiplexed payloads:
I didn’t see jlw52761 reply to your question if the device publishes an “off” message of any kind. What I did see written is that the payload may at times fail to contain the eventtype key. It’s unclear if that implicitly indicates an “off” message or if it’s just one of the quirks of the device’s behavior. The template I suggested assumes the key’s absence implies an “off” message. If the key exists in the payload but its value is anything other than event_start the template will also interpret it as an “off” message.
Anyway, we’re discussing a lot of hypothetical operational edge-cases but we don’t know all the details of the device jlw52761 is using. 