Up until now I have been working with Ursalinks UG65 and UG85 utilizing their integrated network server. Works seamless.
Next step is to utilize a private server based architecture – I’ve chosen ChirpStack. Installed and followed the steps (configuration). Can connect to the application server’s web-site. Log’s do not show any obvious error. Trying to use a Dragino LG308 as a gateway is where the trouble starts. I’ have installed the .ipk as described and setup the configuration. The MQTT monitor (connected to the MQTT @ application server) shows that the gateway is sending something (gateway/90b81691fdeaa22b/command/down >> …o…+(.0.B…}…4/5j…"…8P…mM…*…o…(.0.B…}…4/5j.2…+). However, the application server says the gateway is never seen. What I’m wondering is, where am I supposed to tell the application server how it is to connect to the gateway? Ok, I have the same gateway-id on both sides, but the “ChirpStack architecture” shows me that there are two possible ways to connect gateways: via UDP or MQTT. Ho do I tell the application server on which way it is supposed to listen?
What you’re seeing in the MQTT monitor is not a message from the gateway to the server, but the other way round, ie: the server is trying to communicate with the gateway. This is easy to see because the topic includes “/command/down”.
Its not exactly the same, but you can see some example MQTT topics here and here (go to v3.0.0) . For a quick rule of thumb, if the topics includes the word “down” its probably going from the server to the downlink
What you said about gateways being able to connect either via MQTT or UDP is only partially true. The gateway has a packet forwarder that communicates via UDP. This is transformed to MQTT via the Chirpstack Gateway Bridge, which may be installed in the gateway or somewhere else. If it is installed in the gateway, then the only communication that the gateway has with the outside world is MQTT. If the bridge is not installed in the gateway, that communication is UDP instead.
HOWEVER, this does not impact the application server or the network server at all, since they don’t care where the Bridge is installed as long as it is working correctly. Where is your bridge installed?
Judging from the fact that the down command reaches the MQTT broker, I’m guessing the connection between the broker and the network server is working correctly. On top of this, from the logs of the bridge it looks like the connection between the MQTT broker and the bridge was also established successfully. This leads me to believe that the problem is between the packet forwarder and the bridge.
installed everything on my LG308 according to https://www.chirpstack.io/gateway-bridge/gateway/dragino/ (however, some of the fields on the web-site of my LG308 are named differently than mentioned in that installation manual, e.g. the manual mentioned a setting ‘IoT Service’ which I don’t have) – from what I can tell, this installation is supposed to be packet-forwarder AND Gateway-Bridge
From the Dragino LG308 (gateway) I have tested possible MQTT-connection with
This is working (can see the ‘hello’ popping up in MQTT-Monitor)
I have verified a dozen times the cfg ‘/etc/chirpstack-gateway-bridge/chirpstack-gateway-bridge.toml’ on the Dragino – that all is perfect
In an act of desperation I have set (on the Dragino LG308) the field ‘Server Address’ to the Ubuntu machine (with the chirpstack-installation on) – and voila – messages (gateway/xxxx/event/stats) are coming in (verified with MQTT-Monitor). This ‘Server Address’ was originally set to 127.0.0.1 (according to the manual) which is supposed to talk to the (on the Dragino) locally installed Gateway-Bridge. For some reason this did not work. To me it looks like the gateway now talks to Gateway-Bridge on the Chirp-Server (not to its own local version). If I set marshaler=“json” on the Chirp-Server the messages in the MQTT are showing up in JSON format, that’s proof to my assumption.
From what I gather, you got it to work correctly with the bridge that is in the VM. Is it possible that your system is not working correctly with the bridge installed on the gateway because everything in the VM is set up to allow incoming connections through the 1700 port but not the 1883 port?