Management over MQTT

The Management API can also be driven through the MQTT broker the gateway connects to, instead of a direct WebSocket. Use it when you cannot reach the gateway’s IP, or when you manage several gateways through one broker.

The message format is the same. Two things differ.

1. It must be enabled

Set Allow Gateway management through MQTT in the gateway’s MQTT configuration. Without it the gateway ignores management messages.

Danger

Enabling this lets any client connected to that broker change all gateway and sensor settings. Only enable it on a broker you control, and whose clients you trust.

2. State is pull, not push

Unlike the WebSocket interface, the gateway does not publish its state continuously. You ask for it:

{ "type": "observeerequest", "action": "getstate", "gwSerial": 589245105 }

The gateway publishes the state to the same topic it is configured with.

gwSerial is required on every message

Every message sent to the gateway over MQTT must carry a gwSerial property with that gateway’s serial number:

{
  "type": "observeerequest",
  "phantomcode": 189281421,
  "action": "signal",
  "gwSerial": 589245105
}

This is not optional convenience. Several gateways can subscribe to the same topic, and gwSerial is the only thing that tells them which one the message is for. A message without it is ignored by all of them.

Which transport to choose

	WebSocket	MQTT
State delivery	Pushed continuously (stateupdate + statepatch)	Pulled with getstate
gwSerial needed	No	Yes, always
Needs direct IP access	Yes	No
Extra setting to enable	No	Yes
Good for	One gateway, live monitoring	Several gateways, or NAT/firewall in between

If you are building a live dashboard, prefer the WebSocket — the patch stream is far cheaper than polling getstate.