MQTT

Machine connectors, energy meters and your own systems send real-time station data to Busroot over MQTT, a lightweight, open messaging protocol designed for IoT. This page is the reference for the signals Busroot accepts and how to connect. To find which signal each capability needs, see Machine connectors.

Station Signals

The types of data Busroot accepts are called signals. Busroot supports these signals:

Signal field	Description
production_complete_good production_complete (alias)	The number of new (good) production units created.
production_count_good production_count (alias)	The running count of new (good) production units created. The number of new units is this count minus the previously received count.
production_complete_bad bad_production_complete (alias)	The number of new bad/reject production units created.
production_count_bad bad_production_count (alias)	The running count of new bad/reject production units created. The number of new units is this count minus the previously received count.
bad_production_reason	Quality reason code for the bad production reported in the same message, so quality losses can be analysed by cause. Should match a reason code of type quality configured on the account. An unrecognised code is still recorded and displayed as the raw code, and bad production without a reason is recorded as "Unknown".
productive	Whether the station is currently engaged in production. Any number greater than 0 means productive.
electrical_kwh	The total cumulative amount of kWh consumed. This is typically from a meter reading.
electrical_kwh_interval	The amount of kWh consumed since the last data point.
electrical_kw	The power being drawn on the electrical supply in kilowatts.
line_speed speed (alias)	A number indicating the speed of the station. No units are assumed, so this could be a percentage or a speed such as m/s.
status_code	A code for the current status of the station, for example an error code from the machine control. Busroot stores the latest code on the station and in each station window.
non_production_reason	Declares that the station is currently in a period of non-production, and gives the reason code for it. The presence of the field is the declaration. See Non-Production Signal below.
rssi	The Wi-Fi signal strength of the device.
timestamp	The time these signals were generated, as a Unix epoch in milliseconds. Best omitted: the time of receipt is then used, which is correct for anything publishing live.

Send the signals as a JSON string published to the station's MQTT topic, for example:

MQTT Topic: busroot/v1/[Account ID]/[Station Code]

Payload:
{
  "production_count_good": 12.4,
  "electrical_kwh": 15774.45
}

Non-Production Signal

Sometimes external logic knows a station is legitimately idle for a reason Busroot cannot detect, for example two interlocked stations that can only run one at a time. The non_production_reason signal lets that logic declare the idle period, so the time is excluded from utilisation in the same way as a planned non-production schedule and the station is not penalised for it.

• The field's presence is the declaration. There is no separate on/off flag and no end message. To end the period, stop sending the field. The value is the reason code for the period, which should match a reason of type non-production configured on the account. An unrecognised code is still honoured, and is displayed as the raw code.
• It is a heartbeat. Each message re-asserts non-production for the one-minute window it lands in, so publish at least once per minute for continuous coverage. If the sender stops, deliberately or through a failure, the period ends on its own, so a station can never be left stuck in non-production.
• While the period is open, the time is excluded from utilisation, no downtime is raised, and production signals from the station are not recorded. The station is shown exactly like a scheduled non-production period: Planned Non-Production (blue) on the Cockpit and the Operator Interface, where a "Current Planned Non-Production" card shows the declared reason. The card has no start or end times, since the period is controlled entirely by the sender.
• It is not a schedule. No schedule is created, ended or modified. A running production schedule continues underneath and takes over again as soon as the declaration stops. A non-production schedule's reason takes precedence over the signal's, and an ongoing manual downtime takes precedence over the signal entirely.
• It is auditable. The non-production CSV export (/api/non-production/csv) lists non-production time per station and reason over a range with a Source column (Signal or Schedule), so time excluded from the utilisation denominator by a device is never invisible.

MQTT Access

To connect to the Busroot MQTT broker, a device needs valid credentials: a Device ID and an Access Token. An Admin creates them on Devices. The Device ID is the account ID, followed by a / and a unique value for that device.

For the broker's host names and ports, see Shop floor network.

Connect with this username, password and client ID:

MQTT Field	Value
Username	Device ID
Password	Access Token
Client ID	Device ID + / + [optional string]

Once connected, the device can only publish and subscribe to topics for its own account:

Busroot Signals Topic: busroot/v1/[Account ID]/[Station Code]\ Raw Data Topic: busroot/v1/dau/ + Device ID

Busroot processes data published to the Busroot Signals topic directly, using the signals above.

Busroot does not process data published to the Raw Data topic. It lets a device send data in its own format. A second stage then converts the payload into Busroot signals and publishes them to the Busroot Signals topic. Contact support to set this up.

To remove a device's access, delete it on Devices. Its credentials then no longer authenticate.