MQTT Test

[digiajay]

Hi Jakub,

I tried to test MQTT with https://mqttx.app/web-client# and https://www.hivemq.com/demos/websocket-client/ but doesn't looks like connecting.

-Ajay

[jakub-przepiora]

hi, i will try this in this week but i testet this with local simulator on other computer and this worked

[jakub-przepiora]

Hi @ajay — thanks for the report, I dug into it. 🙂

The short version: OpenMES is an MQTT subscriber/client, not a broker. So the browser clients you tried (MQTTX web client, HiveMQ WebSocket client) have nothing to connect to on the OpenMES side — MQTT is pub/sub through a broker, and OpenMES is just another client that connects to that broker.

Two things were going on:

1. You need a broker in the middle (e.g. Mosquitto):

   [ MQTTX / machine ] --publish--> [ Mosquitto broker ] <--subscribe-- [ OpenMES (mqtt:listen) ]
   

   Point OpenMES at the broker (Admin → Connectivity → MQTT), and publish from MQTTX to the same broker.

2. Browser clients only speak MQTT-over-WebSocket — a broker listening only on TCP 1883 will refuse them. You need a WebSocket listener (port 9001, protocol websockets). That's why my local test with a native TCP simulator worked, but your browser clients didn't.

I've clarified all of this in the docs (topology + a Mosquitto config with both a 1883 TCP and a 9001 WebSocket listener, plus how to point MQTTX web at port 9001 over ws://): #194.

Give that a try and let me know if it connects — happy to help debug further if not.

[digiajay]

Thanks Jakub, appreciate you digging into this. I know OpenMES is a subscriber/client and not a broker — that part I already knew.

We tested locally against a Mosquitto broker and got it working end-to-end. Along the way we noticed a couple of things worth flagging, separate from the WS-vs-TCP point:

mqtt:listen is a single long-lived process pinned to one --connection=<id> at startup (the mqtt-listener service passes this via MQTT_CONNECTION_ID). It only loads that one connection's config when the process starts, and only subscribes to that connection's topics. So when we created a new MQTT connection in the admin UI, nothing actually started listening for it — the DB row existed, but no process was pointed at its ID. It just sat at "disconnected" until we manually restarted mqtt:listen (--connection=<that-id>, or the mqtt-listener container with MQTT_CONNECTION_ID set to it). That's likely what's happening on /admin/connectivity/mqtt/2 on demo.getopenmes.com too — the connection itself looks fine, there's just nothing running against that ID.

Separately, after publishing a message to a subscribed topic, the connection's detail screen (Live Message Log) went blank/stuck in the browser. Haven't isolated the exact trigger yet.

Worth noting the restart point isn't the same as needing one after every edit — once a listener is actually running against a given connection ID, changes to that same connection's host/port/topics do get picked up automatically on the next reconnect cycle. The gap is specifically that a brand-new connection ID has nothing running against it at all until a process is manually started/pointed at it.