Gateway id override

[nicolas-juteau]

Actually, mqtt-forwarder fetches the gateway_id from the backend (either concentratord or semtech_udp). In cases where either concentratord / semtech packet forwarder cannot start for various reasons (i.e: hardware problem with the LoRa card), mqtt-forwarder stalls there and no MQTT connection to the remote broker is made (which is fair enough). This means remote commands cannot be executed anymore because it requires an MQTT connection for that.

The proposed feature is to allow the possibility to override the gateway_id in the configuration file. If set by the user, the mqtt client will use the overriden gateway_id in the configuration file rather than waiting for the backend to respond. This allows for remote command execution (which is a nice feature of mqtt-forwarder), even though no concentrator / packet forwarder backend is started.

If gateway_id is not overriden, mqtt-forwarder operates as usual.

Tested successfully on MultiTech MTCAP / MTCDT gateways.

[brocaar]

I'm a bit hesitant to merge this. I understand that the MQTT Forwarder will not start until the Concentratord or UDP Packet Forwarder has started, however this does assure that the correct Gateway ID will be used.

It would also mean we now end up with multiple places where the Gateway ID can be set (or overridden). I'm not sure if that is a good thing.

[nicolas-juteau]

I'm a bit hesitant to merge this. I understand that the MQTT Forwarder will not start until the Concentratord or UDP Packet Forwarder has started, however this does assure that the correct Gateway ID will be used.

It would also mean we now end up with multiple places where the Gateway ID can be set (or overridden). I'm not sure if that is a good thing.

I understand your hesitation. After looking at the interactions between mqtt-forwarder and concentratord, there might be a better way to achieve this.

My understanding is that mqtt-forwarder polls for the gatway_id via zeromq message, which is handled by libconcentratord: it listens for gateway_id zeromq message and calls the appropriate Command::GatewayID of the applicable component (sx1301, sx1302, 2g4). The component itself replies with the gateway_id parameter passed in command's handle_loop function responsible of running the command thread. As you are already aware, it is now possible to override the gateway id for sx1302 (see this issue), in which case the overriden gateway id is passed to the handle_loop command thread. This provides an effective way to pass the overriden gateway id to mqtt-forwarder, thus avoiding defining multiple gateway_id at different places and avoids any modifications on the mqtt-forwarder end. The only remaining things left to modify is allow gateway id override on sx1301 and 2g4 components as well.

Let me know your input on this.

Cheers,
Nicolas

[nicolas-juteau]

After a deeper look in the code, gateway_id is already set in config for sx1301 so it already works as described in my previous comment. The reason it does not work in the first place for gateway with LoRa card issues is that the code throws in the concentrator::start function, so the gateway command thread never has time to start and thus does not reply to mqtt-forwarder gateway_id requests.

I guess we're back at square one for this :/

[brocaar]

Aren't we mixing two things?

1. One item is the possibility to override the Gateway ID which is possible for the SX1302/3. For the SX1301 it is always provided by the user.
2. Connecting the MQTT Forwarder over MQTT even if the Concentratord is not started.

2. is not affected by 1). However, if we make the Gateway ID configurable in the MQTT Forwarder to solve 2), then we end up with multiple places where a Gateway ID can be configured; the Concentratord and the MQTT Forwarder. I'm not in favor of making it possible to configure the same setting at multiple places, as this will potentially lead to mis-configurations.

[nicolas-juteau]

I think there is a misunderstanding. I was suggesting a different way of solving the issue described here, that does not imply to override the gateway_id in the mqtt-forwarder. I then remembered that the gateway id is always set by the user for sx1301 (not only possible for the sx1302) in the concentratord.

However, after checking the concentratord code, I found it won't solve the issue anyway because the code throws in the concentrator::start() function, which is called before starting the thread responsible for replying to mqtt-forwarder via zero mq message. A way to make this work is to find a way for the concentratord to send the gateway id to mqtt forwarder before calling concentrator::start().

I will open a separate issue in chirpstack-concentratord about this.

[brocaar]

I think our thoughts partial overlap ;-) What I mean is that there is still a dependency to have a "partially" started Concentratord. If the Concentratord is not starting at all (e.g. it is disabled, hardware fault), you are still in the same situation that the MQTT Forwarder won't start.

Still I have mixed thoughts about this. The limitation can also be a feature. If the MQTT Forwarder connects successfully because we make it possible to retrieve the Gateway ID before successfully starting the Concentratord this would lead to a .../state/conn - CONNECTED MQTT msg being published. When using this for gateway monitoring, this gives a false positive that the gateway is connected (it is connected, but not forwarding).

[nicolas-juteau]

I guess then it all comes down to the end-user use case. Some will use the .../state/conn - CONNECTED MQTT topic to monitor whether the gateway forwards concentrator messages, while some others won't. You are right however that some will, and therefore it might not be the best idea to enforce this through the concentratord (publishing the gateway id before it starts the LoRa concentrator), but rather provide an option to override this through the mqtt-forwarder config.

Personally, I consider the mqtt-forwarder much more than only a concentrator message forwarder, but also all the other data it can actually forward through the features it provides (metadata, commands, callbacks). Losing those features because a LoRa card hardware fault does not makes sense, in my opinion. Hence the proposed pull request. Not to mention there are other ways to detect and report potential LoRa card hardware faults (we use monit to send an alert if concentratord is restarted more than X consecutives times). Or one could potentially use (the absence of) concentratord_version or hal_version metadata pushed by the mqtt-forwarder, but I have not tested this / do not know the behavior in case concentratord does not start. I will report this in this discussion later.

Apart from that, I guess the only argument left I have is to keep this feature optional, undocumented or documented in a way that the user is warned/aware of potential config mismatchs.

Still, this was a very interesting discussion.

Cheers and thank you for your work!

[nicolas-juteau]

Or one could potentially use (the absence of) concentratord_version or hal_version metadata pushed by the mqtt-forwarder, but I have not tested this / do not know the behavior in case concentratord does not start. I will report this in this discussion later.

Update about this. In the described case, the gateway will always show as "never seen" on chirpstack panel, since concentratord cannot start and thus will never send .../event/stats, which just makes sense.

As already mentioned however, .../state/conn will always reflect the connection state of the mqtt-forwarder.