Publish Modbus points to MQTT
Connect the broker, define one field point, verify its value and status, and test commands separately.
Prepare one field point
Have the field device's register map and working serial settings. Select one documented read-only point with a known value. You also need the broker address, transport/port, required credentials, and permission to publish/subscribe to the intended topics.
Use the SB1000 web interface for the device and point editor and live diagnostics. The native app configures only the settings supported by its NFC schema.
1. Connect the broker
- Select MQTT operation for the appropriate serial port and configure its line settings.
- Enter the broker URI using the intended scheme: mqtt://, mqtts://, ws://, or wss:// where supported by the installed firmware. Match the broker's actual port and transport.
- Check network routing and DNS when using a hostname. A reachable web interface does not establish access from SB1000 to the broker.
- Enter the broker credentials and check its publish/subscribe access rules.
- Save and verify that SB1000 reports the broker as connected.
Encryption and broker identity verification are separate properties. The firmware documented by this guide supports encrypted MQTT transports but disables CA/common-name certificate validation. Do not assume mqtts:// or wss:// authenticates the broker in that firmware; follow the security requirements of the installation and check the release's documented behavior.
While the MQTT broker is disconnected, the MQTT mapping driver's Modbus polling pauses. Restore broker connectivity before concluding that missing polling traffic means an RS485 fault.
2. Define the device and point
- Add the field device on the correct port with its actual Modbus address.
- Choose the library solution for the exact model/firmware, or create a definition from its register map. A similar product name does not guarantee the same map.
- Verify the point's table/function, zero-based address, width, signedness, byte/word order, scale, offset, unit, and access.
- Set a sensible polling interval and inter-message delay. Start with a small point set; absent devices and retries consume bus time.
- Save the profile. Saving changes restarts the protocol services so the new definitions can load.
A Modbus exception means the device answered but rejected that request. In firmware 8, exception replies no longer count as a nonresponding device for “Max fails until down”. Check the exact status and firmware before diagnosing an offline device.
3. Verify the subscriber's result
Value topics use the configured structure Prefix/DeviceName/PointName/value. The corresponding status topic ends in /status, and the command topic for a writable point ends in /set. Use the actual configured names and case.
Subscribe to the expected value and status topics. Compare a fresh value against the field device and check the status. A retained value from an earlier session is not evidence of a fresh measurement. Per-device statistics are available under Prefix/DeviceName/Statistics on firmware exposing that feature.
If the broker is connected but values are missing, check the profile and point list, exact topic prefix, source status, and publishing/polling policy. A write-only point does not provide a newly polled measurement; its displayed value may be the last value written.
4. Test commands separately
Confirm the point is writable and use the payload defined by its numeric or state configuration. Perform a planned reversible test on the point's /set topic, inspect the resulting status, and read the documented field feedback. Check any heartbeat/repeated-write setting so a one-off test does not become a recurring command.
A successful command status does not prove physical movement. Local overrides, operating modes, and equipment interlocks still apply. Restore or release the test action afterward.
Complete the integration
Record the broker transport/port without passwords, exact topic names, point definitions, firmware version, and a successful live value/status pair. Verify reconnect behavior and how the receiving system marks stale data. Keep credentials out of screenshots and support exports.
