[Question / Feature] MQTT retain flag for motion and object detection

Currently the Retain flag for MQTT publishing for {camera}/motion, {zone}/{label}, etc. is set to false. This means that when an MQTT client (e.g. Home Assistant) gets restarted or connects for the first time, it does not receive any current state until motion or objects are detected. So after restarting Home Assistant, for example, the MQTT Binary Sensor integration loads with a state of "Unknown" instead of the expected "On" or "Off". This can complicate automations that are not explicitly written to take "Unknown" into account.

This can be resolved by setting the appropriate retain flags to true (see this diff in my repo, ignore the CI.yml), which causes the MQTT broker (if configured to do so) to send the last motion / object state to Home Assistant when it restarts.

This change would resolve my problem, however there are some slight complications that I wanted to ask about before trying to turn this into a PR. Ideally this could be added as a configuration option like retain_state in CameraMqttConfig as a per-camera setting, but that further complicates things:

If an MQTT topic is no longer being sent messages with the retain flag set, either A) because retain_state was changed from True to False, or B) because a camera/zone's name changed; connecting clients will continue to receive the retained message even though the state is no longer valid (in case A) or that camera no longer exists (in case B).

Retained messages can be cleared by sending an empty message to the topic with the retain flag set to True, but since we don't know which retained messages may exist from a previous configuration, we either need to:

• Try to clear retained messages during a clean-shutdown of Frigate. This would be a very efficient way to make sure all the topics are covered, and would also prevent MQTT clients from seeing Frigate as "active" even when it's off. However, any sort of unexpected shutdown would bypass this.
• Subscribe to /frigate/# and iterate over all the retained messages we received to clear them. This is more complete since it handles expectedly abandoned topics, but it slightly more code / effort intensive.

---

Before I dig into adding configuration and retained message clearing, I wanted to ask:

• Would this be a feature worth including (if it's an only-me thing I could always just keep my own fork to run at home)?
• How concerned are we about making this configurable (would retaining by default be okay, or would that break too many things)?
• Of the two methods above (or others I haven't thought of), what's the best way to clear out old retained messages (or do we even care)?

(Apologies for the wordy post, just want to make sure I can contribute in a way that doesn't make things more complicated and keep my PRs focused)

We have used retain in the past and it's too easy to end up with a retained value that isn't synced with Frigate. We would need to ensure Frigate publishes to the topic on startup to ensure the values are current and in sync.

Do you really have devices subscribed to mqtt that restart often enough to matter? I don't think many users have this issue since motion and objects topics change fairly often.

Do you really have devices subscribed to mqtt that restart often enough to matter?

Well yes and no; when updating Home Assistant to set up new MQTT sensors or troubleshooting automations, it gets restarted pretty often (or at least the MQTT part gets reloaded if that's all I'm changing). So if I'm changing configuration and testing the camera sensors I run into "Unknown" states quite a bit and have to go walk around in front of the cameras after each change. During normal usage, it doesn't really come up much though, you're right.

It did occur to me while testing, that I can manually publish "OFF"/"0" to all the topics I'm concerned about, and then HA will at least get a proper state when starting up. It might not be in sync with Frigate, but that's not really that much worse than the current situation where there's no information at all about the state.

Agreed it seems like probably too much complication for something that will likely only happen during configuration and testing. Thanks for the explanation.