Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Bridging and order of (re)sending of messages 
On 2021-06-21 14:48, Greg Troxel wrote:


I have more questions than answers and am thinking that at least I and
likely many would benefit from understanding more about your situation.


Trying to give more info here and answer your questions:

It's still in more or less design phase, but the idea is:
- to have 250 (heterogeneous) static sensor stations, publishing say 2 - 10 different quantities(observed property) (being either meteorological or chemical or radiological) to one or two (central/round robin?) brokers. These are the daily/historic/background measurements. These have a rather OK connection 99% of the time.
- to have 2-10 moving stations (say vehicles), which are used in case of emergency or (fire) incidents. THOSE are the ones having connection troubles sometimes... and THOSE are during that incident the most interesting....
- a bonus would be if the vehicles could keep communicating (so maybe bridging to each other) even if the central broker is down/unreachable
- multiple sensors, probably combined with time (and some of them with GPS position), but separated as 1 quantity/observed property per message, probably json messages
- yes QOS is set to 2 (we are interested in historical values from the internal broker). Steve in an earlier post proposed to use the retained flag (in combi with qos 0) to always have the latest value availabe, even in case of a longer connection issue
- persistence: an idea is to use a (OGC) Sensor Things Api server like https://github.com/FraunhoferIOSB/FROST-Server to persist the values. FROST even has an mqtt endpoint itself, so maybe 'bridging' from the central broker to FROST
- queue full?... well then at least let's have the latest retained message as soon as we are connected again... 

Thanks for your interest, hoping this answers some of your questions.

Regards,

Richard Duivenvoorde


  I assume there is a single sensor that posts a reading to a single
  topic, notionally sensor/id/temp, with a value that's basically
  printf %0.1f of temp in C.
Or, are you representing time in the payload? (It seems one has to do that to make the semantics work in the received database, but I may be 
  overlooking something.)

  What qos are you using?  Assuming 1 or 2, what is your rationale for
  the choice?

  Are you using a retained topic?
Does this have anything to do with persistence being configured on the 
  remote broker?  (I'd guess not, except that you may want to recover
  from reboots as a separate concern.)

  Can you explain your clean_session flag setup?  One thing I don't
  follow is that there are two directions of messages on a bridge and I
  would think one might want to have persistence separately.


Related to your desire to reorder is a question about which messages
are dropped when the queue is full.  Another is if there are other
protocols sending data on reconnect and that you may want to force
mosquitto to just send the recent one, in order to have it not compete
with those protocols.   This gets very complicated fairly fast.

Greg

Back to the top