Re: [mosquitto-dev] retained messages and bridges

[Roger Light <roger@xxxxxxxxxx>]

Hi Greg,

The bridges follow the subscription rules for any other client, with
the exception of the extra features "don't send my messages back to
me", and "send retained bit as the original publisher". I don't really
want to add custom  payload processing.

I think the MQTT v5 subscription features might help you - if you used
"Do not send retained messages at the time of the subscribe" then
would that solve your problem? The next feature version will have
better MQTT v5 support for bridges.

Regards,

Roger





On Tue, 11 Aug 2020 at 13:21, Greg Troxel <gdt@xxxxxxxxxx> wrote:
>
>
> I have a setup, and projecting to the part that matters, it is:
>
>   broker at site A
>   Home Assistant (HA) at site A
>
>   broker at site B
>   code to read status of a UPS and inject messages
>
> At B, the retain flag is set.
>
>
> Currently, the code to publish status is not running.
>
> So, in steady state, there is a retained message on broker B and one on
> broke A, and HA has timed out the status and shows things as
> Unavailable, which is correct.
>
> Then, internet flakes at B and the bridge connection is re-made to A,
> and the old message is reinjected.  HA sees that as fresh (which it is
> not) and then times it out again.
>
> There are multiple tings kind of wrong:
>
>   mqtt is a message protocol, and users have to use it in a sound way,
>   and publishing current state and using retain is not really sound.
>   With retain, you have to have a timestamp and handle that, so you
>   don't deal with old data as fresh data.  (very hard obviously)
>
>   retain is ok for the originating broker; as long as it is up the
>   message sits there, but it doesn't re-appear.  However, once a
>   retained message has been sent over a bridge, arguably it should not
>   be re-sent over that same bridge.  That requires bookkeeping somehow,
>   perhaps a 'last sync' timestamp per bridge, and not sending messages
>   that are earlier than this time.    Not clear what specs say, but I
>   think this would be an improvement.
>
>
> Overall I am concluding both that
>
>   bridges should not send retained messages that were already sent.
>
>   state information should not be retained, unless one of
>
>      it has timestamps and processing code is timestamp and time
>      semantics aware (which HA is not)
>
>      recipients really treat the retained message as simply "current
>      state" with no sense of expiration (which doesn't really make sense
>      because when you don't have a message for 2 days you really have no
>      idea what's going on)
>
>
> Thougths?
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev