Skip to content

Station Controller MQTT

MQTT readings from Station Controller DCN modules, proxied by an iSR Client on MQTT SaaS.

The iSR Client polls modules on each station controller over SSH/RS-485, posts readings to the hub, and fans out one MQTT publish per channel reading. You do not need a separate portal MQTT client row for each station controller — all SC traffic appears under the proxying iSR Client’s {account_id}/{client_id}/… prefix.

The iSR Client’s own status and host telemetry are documented in iSR Client MQTT. CPU, RAM, swap, and disk for the iSR Client host belong there (state/summary, optional telemetry/system), not in the SC module tables below.

For QoS rules, the QoS 2 add-on, and fair-use caps, see MQTT QoS and topics.

Topic layout

SC readings use the same platform path as the proxying iSR Client:

{account_id}/{client_id}/{subpath}
Segment Value
{account_id} Tenant UUID (must match the iSR Client’s mqtt_account_id)
{client_id} The proxying iSR Client’s MQTT Client ID from the portal
{subpath} state/{type} or telemetry/{type} (see module tables below)

Topic setup and credentials: iSR Client MQTT — topic layout and MQTT clients.

Example topics (same account and client as the iSR Client page):

550e8400-e29b-41d4-a716-446655440000/isr-shack-01/state/relay
550e8400-e29b-41d4-a716-446655440000/isr-shack-01/telemetry/watt_meter
550e8400-e29b-41d4-a716-446655440000/isr-shack-01/telemetry/temp_probe

Wildcards for all SC traffic on that iSR Client:

550e8400-e29b-41d4-a716-446655440000/isr-shack-01/state/#
550e8400-e29b-41d4-a716-446655440000/isr-shack-01/telemetry/#

Identified by

What How
Which SC unit station_controller_device_id in JSON — SC-{MAC} (uppercase MAC segments), not a separate {client_id} in the topic path
Which reading type + chan (1-based on DCN modules) + module + dcn
DCN address Bus address of the module, e.g. 0x01 for a GPIO board — not an IP address. Peripheral modules are typically 0x01, 0x02, …; the Pi host is the bus master at 0x00.
Display names Module and channel labels from the hub UI — not in the flat MQTT JSON today; match on machine ids or map from hub config

How readings are published

  • One MQTT message per channel reading — not one blob per poll cycle — so relays can use QoS 2 while meters stay at QoS 0.
  • Module-dependent — subpath and payload shape depend on which DCN hardware is installed (tables below).
  • Zero or more SCs per iSR Client — filter on station_controller_device_id when several units share one MQTT login.

The SC’s Raspberry Pi is the platform that hosts DCN modules. Only peripheral module readings are documented here.

Module readings by type

Four module types are defined in the platform; three publish MQTT readings today (gpio, hf_coax_switch, rf_watt_meter_2port). dcn_power_hub can appear in topology but does not publish reading topics on MQTT yet.

Each row is one MQTT publish. module in the JSON matches the tables below.

GPIO module (module: gpio)

DCN payload: UPDATE,GPIO1,… — relays, open-collector outputs, digital inputs, volt meters, and temperature probes.

type Subpath QoS Channels reading units
relay state/relay 2 1–4 boolean ""
open_collector_output state/open_collector_output 2 1–4 boolean ""
digital_input state/digital_input 2 1–4 boolean ""
volt_meter telemetry/volt_meter 0 1–4 number V
temp_probe telemetry/temp_probe 0 1–2 number F

HF Coax Switch module (module: hf_coax_switch)

DCN payload: UPDATE,CX1,… — four RF path positions. Each channel is 1 when that position is selected, 0 otherwise.

type Subpath QoS Channels reading units
coax_switch state/coax_switch 2 1–4 0 or 1 ""

RF Watt Meter — 2 port (module: rf_watt_meter_2port)

DCN payload: UPDATE,WM1,… — forward and reflected power on two ports (four channels total).

type Subpath QoS Channels reading units
watt_meter telemetry/watt_meter 0 1–4 number W

Typical channel layout: 1 = port 1 forward, 2 = port 1 reflected, 3 = port 2 forward, 4 = port 2 reflected (labels are configurable in the hub UI).

DCN Power Hub (module: dcn_power_hub)

Discovered on the DCN bus during topology scan. No reading channels are published to MQTT today — listed for topology matching only.

Payload envelope (one channel per message)

Each publish is a flat JSON object. reading type depends on type: booleans for GPIO relays/inputs/outputs; 0/1 for coax positions; numbers for meters.

Field Type Notes
station_controller_device_id string SC-{MAC}
collected_at_utc string RFC3339 UTC for the poll cycle
type string Reading type (matches subpath), e.g. relay, watt_meter
chan integer 1-based channel index on that module
reading boolean or number Current value
units string e.g. V, W, F; empty string when N/A
module string gpio, hf_coax_switch, rf_watt_meter_2port, …
dcn string DCN address of the module, e.g. 0x01

Example — relay on GPIO module at DCN 0x01, channel 3:

{
  "station_controller_device_id": "SC-88:AE:DD:71:FF:BE",
  "collected_at_utc": "2026-05-19T18:42:10Z",
  "type": "relay",
  "chan": 3,
  "reading": true,
  "units": "",
  "module": "gpio",
  "dcn": "0x01"
}

Example: one poll cycle → several MQTT publishes

iSR Client {client_id} = isr-shack-01. Station controller SC-88:AE:DD:71:FF:BE with GPIO at DCN 0x01, watt meter at 0x02, coax switch at 0x03:

…/state/relay              QoS 2   module gpio                 dcn 0x01  chan 3  reading true
…/telemetry/temp_probe     QoS 0   module gpio                 dcn 0x01  chan 2  reading 72.5 F
…/telemetry/watt_meter     QoS 0   module rf_watt_meter_2port  dcn 0x02  chan 1  reading 66.5 W
…/state/coax_switch        QoS 2   module hf_coax_switch       dcn 0x03  chan 2  reading 1

Effective QoS for state/ vs telemetry/ matches iSR Client MQTT — Effective QoS.