[Feature request]: Should 'Retain' be default

[lmcd]

Is your feature request related to a problem? Please describe

I'm using zigbee2mqtt in a completely new project.
Some low-power battery powered devices report their status very intermittently. Sometimes once an hour or so. With the default configuration of zigbee2mqtt, it's impossible to know the last state of the device until it eventually reports.

Zigbee2mqtt 'cheats' this for its own frontend, by explicitly sending last device states on websocket connection. It seems odd to me that there's an explicit exception for zigbee2mqtt's own frontend, but for everyone else, the 'Retain' option needs to be set on a per-device basis.

Are there any downsides to retaining device messages by default?

Describe the solution you'd like

Make 'Retain' default to ON.

Describe alternatives you've considered

None

Additional context

None

[lmcd]

Additionally, posting to the /get topic does nothing on this class of device - so there seems to me no way of accessing this information besides just waiting an arbitrary amount of time for it.

[Koenkk]

Adding the following to your configuration.yaml will enable it for all devices:

device_options:
    retain: true

(https://www.zigbee2mqtt.io/guide/configuration/devices-groups.html#default-values)

[lmcd]

Yeah I appreciate this can be configured, I'm just wondering if there is any downside at all to this being the default?
Thinking similarly about the last seen option. Is there any particular reason why this doesn't also default to on. Seems like a useful thing to know out of the box without requiring users to manually configure.

[Koenkk]

It will create more traffic on the client side (since it will always receive all states).

For those interested, please 👍 the OP so we can see if this should be the default.

[lmcd]

Got it. I'm quite new to MQTT - but doesn't each client receive all states, all of the time anyway (if they're subscribed to all topics)?. All this would change is what each client receives when initially connecting to the MQTT server - and this already happens forcibly on the frontend.

[lmcd]

I think also that this is unlikely to get wide community backing, as this sort of things only affects people doing custom integrations outside of HA etc (I'm not sure if/how HA works around this)