I have a Milesight UG67 gateway on a cellular connection. I have ChirpStack running on a cloud server. The gateway Packet Forwarded is configured with “Chirpstack-v4” with MQTT on port 1883 (default).
The gateway connects fine to the NS on the MQTT connection. I have a test button that sends data ‘ConfirmedDataUp’ and it’s received in the NS with no problems. I noticed that I was receiving repeat transmissions and realised on the gateway it wasn’t seeing the downlink ACK message. I subscribed to the downlink topic on the ChirpStack server and the ACK downlink message is there. The gateway just doesn’t seem to respond to it, hence device doesn’t receive the ACK and then retransmits.
For something that I really thought would be easy to resolve, I’m hitting dead ends. Please could someone assist.
Have you considered using UDP or basicstation on the gateway to a gateway-bridge on your server? I think the UG67 might just have an outdated gateway bridge installed.
Hi Liam, I tried the Gateway-Bridge initially, but thought the MQTT route would be a cleaner approach and I’ve had experience with Mosquitto before. I wouldn’t have considered that the UG67 would have an outdated implementation of the Chirpstack-V4 interface, but if anyone can confirm that, would be great. Is the NS gateway-bridge the preferred option for deployments?
So to clarify, all communication between a gateway and Chirpstack must go through the MQTT broker. No matter what packet forwarder you use, it must go through a Chirpstack gateway bridge somewhere, this gateway bridge translates the typical lorawan packet into an MQTT message Chirpstack can receive.
So presumably, when the UG67 gives you an option to use the “Chirpstack MQTT” packet forwarder, all it is doing is sending it’s traditional UDP packet to a Chirpstack gateway bridge on the gateway itself, and then it sends the MQTT over the air to Chirpstack’s MQTT broker.
Now you are right to think that sending MQTT over the air is a cleaner alternative to sending UDP to a gateway bridge on the Chirpstack server, this is because MQTT uses TCP which has many improvements over UDP. If you want to avoid using UDP though, Basicstation implements TCP instead and you can send that over the air to your gateway-bridge on the server. I would say that using basic-station, or a gateway bridge on the gateway is the typical option for deployments. Personally I am using a gateway bridge on each gateway.
If the UG67 specifically says the “NS gateway-bridge” then that indicates it is definitely outdated, as Chirpstack used to have a separate Network server and application server back in V3, but in V4 they are both merged into one so anything you see that specifically references the Chirpstack Network Server is likely outdated. Does seem strange to me that uplinks are working and it’s just downlinks failing, as I’d expect an outdated gateway bridge to just fail all around, but maybe the MQTT downlink topic format changed in some version of V3 so an outdated gateway bridge is just listening to the wrong topic.
However, since the UDP packet forwarder and Basicstation packet forwarder are both standardized through the Semtech LoRaWAN specifications, they will not be outdated. I’d recommend using one of those (ideally basicstation) since the UG67 local gateway-bridge doesn’t work.
Although if you want to keep testing the gateway bridge the UG67 has, I’d say the next step to debugging the downlinks would be to check if they are being posted to the MQTT broker correctly once triggered in the UI. You should check the topic <region-prefix>/gateway/<gateway-eui>/command/down filling in the values for <>, or you can just subscribe to all MQTT topics using “#”. And check the Chirpstack logs for any errors.
Bit of an info dump here but I hope it gives you some clarity.
Hi Liam, you’re a champ, I really appreciate your time to respond on this. I will implement your recommendations and confirm the outcome if that will assist others with the same issue.