[
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