I’ve been playing around with qos=1 and qos=2 and lora-gateway-bridge version 3.0.1 and I’ve found some interesting things:
Qos works as long as your connection doesn’t drop for too long. If it’s just a few seconds(10-40) things almost work as you’d expect.
Qos 2 somewhat behaves like 1. So you get multiple duplicate messages upon restoring the lora-gateway-bridge connection to the broker.
Not all messages are stored from the moment that the bridge loses connection to the broker. Sometimes you get all messages and other times there will be many missing. It’s behavior is erratic but you seems to lose more messages after being down 40 seconds or greater.
The amount of time that the connection is down determines whether messages or stored at all. If I intentionally drop the connection to the broker for 120 seconds no messages are stored. If I drop the connection for 60 seconds, messages are stored but there are some that are lost.
SetOrderMatters seems to be ignored even though this is set to true by default. Messages are to be sent in the order that they are received and not out of order. So frame count 150 should always follow 149 and 151 should follow 150 for instance.
lora-gateway-bridge also crashes after it tries to reconnect once the mqtt broker is down for approximately 1 minute. If your connection goes up and down a few times after messages are stored lora-gateway-bridge never seems to catch up and live locks it seems.
Something horrible is happening on reconnect. It tries to create multiple sessions which many brokers don’t allow without a unique client id for each. Due to this it crashes almost every time that I test qos with mosquitto due to reconnection retries it seems.
The only way that I can keep it from crashing is by using vernemq broker and specifying this option in the vernemq.conf
allow_multiple_sessions = on
I also built the bridge from git and added a few options but that was unnecessary and didn’t actually make lora-gateway-bridge behave any better. It actually crashes faster once I declare other options. @lpitka mentioned that AutoReconnect needed to be true(I read this also) and MessageChannelDepth should be set but as is things work without a known MessageChannelDepth. Evidently there is a default setting for MessageChannelDepth even though the docs don’t say what it is(100?).
I think it would be apropos if we could specify the MessageChannelDepth and the Store. Some devices are better suited for a file store rather than a memory store and vice versus.
This definitely needs more testing.
Has anyone done anything similar and if so what have you seen?