MQTT, Modbus and BACnet

Field protocols let a building or industrial system read the site's data without depending on the cloud. This document describes the kind of contract each protocol presents and the order in which it is brought up. It does not print a topic tree, a register map or a BACnet object list — those are interface definitions, and the authoritative versions live in contracts/openapi.yaml and on the matching model page. A hand-written register table here would be a number that no engineer signed off.

Preconditions

• The local path has already been proven with the uplink absent, per Edge controller setup. A protocol fault must never be able to hide a local-policy fault.
• The consuming system's required data points are listed, so the mapping is built deliberately rather than by browsing whatever is exposed.

Protocol contracts in outline

Each protocol below is presented as a contract shape. The mapping from a site's node identities to that shape is a site decision, made against the authoritative definitions, not against this page.

MQTT

The edge controller can act as a client that publishes site state and subscribes for commands. The contract is a namespace with a defined structure: a prefix for the site, a segment identifying the node, and a suffix distinguishing state from command. Whether a given topic is published on change or on an interval is a configuration choice. The exact topic segments, the payload encoding and the quality-of-service behaviour are defined in contracts/openapi.yaml; this page deliberately prints no topic string.

Modbus

Modbus is exposed through the gateway or edge controller, not directly from a wireless endpoint. The contract is a register-oriented view of a subset of the site's data points: discrete values, coils, and holding or input registers, each with a defined width and byte order. Which data point maps to which offset is a site configuration, and the authoritative map is owned with the contract, not restated here.

BACnet

Where a building management system expects BACnet, the controller presents the site's points as BACnet objects of the usual types (binary and analog, input and output as appropriate). The object naming and the instance-numbering scheme are site configuration; the authoritative list is published with the contract.

Bringing a protocol up

1. Confirm the point list the consumer needs.
2. Map each point to the protocol's shape using the authoritative definitions in contracts/openapi.yaml.
3. Enable the protocol on the controller.
4. Read back a known value at the consumer and confirm it matches a value shown locally on the gateway.
5. Change a real endpoint state and confirm the consumer observes it.

Failure modes

• Consumer reads stale values: the point is published on change and nothing changed; confirm the publish trigger, not the wiring.
• Register mapping off by one: the offset was taken from an older revision; re-read the map from the contract for the controller's revision.
• Command accepted but no local effect: the mapping targeted the registry entry that is not the physical endpoint; check the node identity.
• Protocol enabled before the local path was proven: the local behaviour is being masked; disable the protocol and re-run the local check.

Limitations

• LS-GW-100 and LS-GW-300 differ in field-protocol support; LS-DIN-4CH exposes Modbus only through a gateway. Confirm which protocols exist on your revision on the model page before designing around them.
• No topic string, register offset or object instance appears on this page by design. Numbers that cannot be traced to the contract or a datasheet are excluded from the documentation set.

What this document does not cover: the gateway's own local REST interface and event delivery are in API and webhooks, and the network position that makes these protocols reachable is in Reference topology.