question

greendrake avatar image
greendrake asked

Cerbo GX: Plain MQTT won't deliver messages unless another client is connected via MQTT over WebSockets

I am using this library to run a custom MQTT client to connect to my Cerbo GX over pure MQTT (port 1883). This connects and seems to subscribe successfully, but then no messages come down unless.... I connect another client to the GX over WebSocket MQTT (port 9001), specifically the official Venus HTML5 App.

The issue is pretty consistent: I start my custom client, it happily receives CONNACK and accepts my subscription requests, and then just remains silent. I open the HTML5 App, it establishes its own connection via WebSockets, and immediately my custom client starts receiving messages for topics it is subscribed to. I close the browser window, my client continues receiving messages for about a minute before it receives an empty message for each of the subscribed topics, and finally messages stop coming.

Open the HTML5 App again — messages for my custom client resume, close it — they stop. The 1883 connection stays alive/subscribed all the time.

Why would that be happening? How could possibly the GX MQTT broker decide whether to send messages down 1883 depending on whether another client is connected on 9001? Is there any way to make it work on 1883 independently?

Cerbo GX firmware v2.66.

cerbo gxMQTT
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

1 Answer
gone-sailing avatar image
gone-sailing answered ·

Have you read the section on keepalive in the dbus-mqtt documentation?

https://github.com/victronenergy/dbus-mqtt

1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Had a glance at that section initially and thought it was only required to periodically affirm that subscription is still wanted.

Now I have tried publishing to "R/e0ff50a097c0/keepalive" with a list of topics and it worked! Thanks a lot.

Still it is strange though that 1) Keepalive is required to start receiving messages from the outset on initial subscription (vs just confirming from time to time that messages are still wanted); and 2) That the connection of another client affects what the first client receives.

0 Likes 0 ·