Dragino LPS8 stats in MQTT okay, last seen "never"

I have the stack running now in Kubernetes: Network server, Application Server, Gateway Bridge (+Postgres, +Redis), no geolocation server, but I think that’s okay–and I have a Mosquitto server that already existed that I’m leveraging. I think the stack is all working properly, but with Kubernetes I may have missed a “Service”, so it could be like some firewall is up between components I’m not aware of.

I have a Dragino LPS8 running nothing but the stock firmware–I pointed its “LoRaWAN” configuration at my Gateway Bridge port 1700 (the LPS8 is not talking to MQTT directly). I seem to be getting stats sent to the Gateway Bridge every 30 seconds, and the Gateway Bridge is posting /gateway/[gwid]/event/stats messages to Mosquitto… but (from the iOS app MQTT Analyzer) the message payloads sent to MQTT appear to be empty, and the web front-end shows that the gateway was last seen “never”. the LPS8 shows some JSON in its log as what is being sent for stats. I’m not seeing anything in the logs of any component that looks like a problem.

Is there configuration to decode the format for the incoming (stats) messages, or a step I’m perhaps missing? Possible some port is not allowed between some components? I’m sure there’s some additional information to provide but not sure from where.

Thank you…

Oooh… this is probably relevant. Using mosquitto_sub instead of MQTT Analyzer it appears the messages are not empty… some of it appears to be raw binary.

/ # mosquitto_sub -h localhost -p 1883 -t 'gateway/#'

@AAP    333336@(\\@ |@ J192.168.0.174ZDOǗ`/߽)X

@AAP    333336@(\\@ |@ J192.168.0.174Z޼I1k9

@AAP    333336@(\\@ |@ J192.168.0.174Z9k?G՝4}{

And I’m assuming with the “Ǘ” and “/߽” that these aren’t base64 encoded either.

Again, these messages are being written by the Gateway Bridge, not the LPS8 itself. Though it may just be writing whatever the gateway sends. Is there somewhere I’ve missed where I’m supposed to specify encoding/decoding on the gateway or Bridge? Re-checking the docs now…

Okay, per Problems with some MQTT content and changing the marshaler to json I can see/read the stats messages in mosquitto_sub and MQTT Analyzer now… so that’s good. The Application Server still shows “Last seen at: Never”, but this narrows things down a bit… now to see why the Application Server isn’t reading the stats messages…

Puzzled again. Everything looks correct. From Network Server logs:

time="2021-03-31T01:19:01Z" level=info msg="gateway/mqtt: connecting to mqtt broker" server="tcp://mosquitto-internal:1882"
time="2021-03-31T01:19:01Z" level=info msg="backend/gateway: connected to mqtt server"
time="2021-03-31T01:19:01Z" level=info msg="gateway/mqtt: subscribing to gateway event topic" qos=0 topic=gateway/+/event/+

Topic contents:

/ # mosquitto_sub -h localhost -p 1882 -t 'gateway/HEXGWID/event/+'
{"gatewayID":"BASE64GWID=","ip":"192.168.0.174","time":"2021-04-01T09:57:31Z","location":{"latitude":22.7,"longitude":114.24,"altitude":450,"source":"GPS","accuracy":0},"configVersion":"","rxPacketsReceived":0,"rxPacketsReceivedOK":0,"txPacketsReceived":0,"txPacketsEmitted":0,"metaData":{},"statsID":"O6F2GdJySSiFVn/oInBrWQ=="}

Will try turning up the logging level on the Network Server?..

Turning up the logging level to 5 on the Network Server didn’t show anything…which may be something… Other than the initial connection to MQTT and subscription, I saw no messages indicating any further MQTT activity. Should there be a debug message when a new message on the gateway/+/event/+ topic is posted?

Yes, there should. Maybe you have setup ACL rules and the NS is not allowed to subscribe to the topic?

No, but I was using this configuration in Mosquitto:

listener 1882
mount_point internal/

Which seems to have been the problem. My understanding is that this was equivalent to a chroot for clients using this listener…and the Gateway Bridge was using MQTT just fine with this in place… also the mosquitto_sub commands above were using the same listener and subscribed fine on that internal/ path without specifying it… very strange, I would not think this would be a problem. I may experiment further. But removing the mount_point directive has fixed my stack for now. Thank you!