What the Niagara MQTT driver will and will not do

The abstractMqttDriver module is a licensed feature. Open License Manager and look for the feature by name: if it is absent, the palette will still open and the network will still install, and nothing will work. That is worth confirming before a design depends on it.

There is a second ceiling underneath the licence. Since 4.10u10 and 4.14u1 the driver applies a default device connection limit of 25 on a JACE and 50 on a Supervisor, regardless of what the GlobalCapacity licence allows. The limit exists to protect driver performance, and only the Supervisor's is configurable — to a maximum of 500. A design that assumed one MQTT device per tenant meter is the design that discovers this.

Four data types, and no others: Boolean, numeric, string and enum. Anything structured — a JSON document with six fields in it, which is what most vendor cloud topics actually publish — has to be taken apart somewhere. The driver will not do it, so either the publisher changes shape or a module does the parsing, and that decision belongs at design time rather than on site.

The device component comes in four kinds. DefaultMqttDevice is the generic client for any broker and is the one to use; AwsMqttDevice and GcpMqttDevice are shaped for AWS IoT and Google Cloud, with their own certificate and RSA-key authenticators, and Azure IoT Hub is reached through a SAS token authenticator on the default device. From 4.14 the default device and authenticator also support client certificate authentication.

AbstractMqttDevice is the fourth, and it is the one to be careful about: it differs from the others only in that it has no authenticator at all, and therefore no communication security. It is a testing component that survives into production because it connects first time.

The client inside the driver is a rebuild of Eclipse Paho, and the package in abstractMqttDriver-rt.jar is mqttv3. There is no mqttv5 package anywhere in the jar, and MqttConnectOptions offers exactly three version values: a default, 3 for MQTT 3.1 and 4 for MQTT 3.1.1. A station therefore speaks MQTT 3.1.1 at best, and no property on the device changes that.

What that rules out is everything MQTT 5 added. No shared subscriptions, so two stations cannot split one topic's load between them and there is no broker-side way to fail over. No user properties, so any metadata has to live in the payload or in the topic string. No topic aliases. No reason codes on acknowledgements, so a publish the broker refuses comes back as a dropped connection rather than an explanation. Broker and network-server documentation increasingly assumes MQTT 5: if an integration guide tells you to subscribe to $share/group/topic, that instruction cannot be followed from a Niagara station, and the subscription will simply never receive anything.

This is the one that wastes an afternoon. The Mqtt Client Driver Point Manager has a Discover button, and pressing it opens the BQL Query Builder. It runs a query against points in your own station and lists what it finds, so that you can publish them. It does not enumerate topics, it does not ask the broker anything, and no amount of fixing the connection will make it behave like BACnet discovery.

Anything arriving from the broker is added by hand, from the abstractMqttDriver palette or the point manager's New button, with the topic typed in. That is not a defect — it follows from MQTT itself, where a broker has no obligation to tell a client what exists — but it does mean a hundred-point integration is a hundred rows of typing, which is what a spreadsheet and the batch editor are for. It also means the topic list has to come from somewhere else: read the broker's topic tree first with a free read-only tap, and type from that rather than from the integration document.

Each data type has a publish extension and a subscribe extension, and they are not interchangeable. Publishing is a wire-sheet act: drop a publish point under the device's Points folder and link the source point's output into it.

A topic is levels separated by forward slashes, and it is typed, not chosen — a typo is a point that never updates and never faults. QoS is per message: 0 fire and forget, 1 at least once with confirmation, 2 exactly once through a four-step handshake. A publisher and a subscriber may use different levels on the same topic.

Retained defaults to true on publish, which means the broker keeps the last message and hands it to anyone who subscribes later. For plant status that is what you want. For a command topic it is not — a retained command is redelivered to every client that connects, including after a restart.

• Clean Session, default false, so the session is persistent and the broker delivers queued messages when the client returns. Setting it true throws away everything on every disconnect.
• Keep Alive is the longest the client may stay silent. It sends a PINGREQ inside that window and the broker must disconnect it if nothing arrives. It exists specifically to deal with half-open connections — the failure where both ends believe they are connected and nothing is moving.
• Connection Timeout caps how long the client waits on a request to the broker.
• Enable LWT is false by default, so out of the box nothing tells the broker this station has dropped. Turn it on and the last will and testament is published on the client's behalf; Retained for LWT defaults to true, so a late subscriber still learns the station is gone.
• Send Enum As chooses between the tag and the ordinal. TAG is the default and is what a human reading the topic wants; an ordinal is what a downstream system expecting a number wants. Changing it later changes every payload.