FreeDMR/docs/reporting-relay.md

Reporting Relay

report_sql.py can be the sole client of the FreeDMR TCP reporting socket and provide a compatible downstream socket for the live dashboard. This avoids placing multiple reporting consumers on the live server while retaining the existing netstring protocol.

The existing six positional arguments are unchanged. Enable the relay with:

python report_sql.py freedmr 4321 dbhost dbuser dbpassword logs \
  --relay-interface 127.0.0.1 --relay-port 4322

Configure FDMR Monitor to connect to relay port 4322. Use an explicit container-facing interface instead of 127.0.0.1 when the dashboard runs in a different container, and restrict access to that interface at the network boundary. Report configuration and bridge-state messages contain trusted Python pickle data and must not be exposed to untrusted clients.

The relay forwards upstream messages unchanged and caches only the latest configuration and bridge-state messages so a newly connected dashboard can be initialized immediately. SQL storage accepts both legacy events and extended events with trailing origin fields:

START: type,event,trx,system,streamid,peerid,subid,slot,dstid,source_server,source_rptr
END:   type,event,trx,system,streamid,peerid,subid,slot,dstid,duration,source_server,source_rptr

Legacy events remain valid and are stored with null origin columns. The relay is optional; omitting --relay-port preserves the previous importer behavior.

Multiple FreeDMR backends

report_mux.py combines reporting from multiple FreeDMR backend processes into one compatible reporting socket. It is used by the HDStack container profile and can also be run directly:

python report_mux.py --listen-interface 127.0.0.1 --listen-port 4321 \
  --client 127.0.0.1 \
  --backend 1,127.0.0.1,4322 --backend 2,127.0.0.1,4323

Backend numbers are explicit and must be unique. Configuration keys, bridge member system fields and bridge-event system fields are prefixed with that number, for example 1:SYSTEM-001. Other fields are preserved. The MUX reconnects to each backend independently and a reporting-source failure does not affect the radio proxy. Its backend connections remain open between updates and accept bounded reporting frames up to 10 MiB so populated worker snapshots do not trigger Twisted's smaller default netstring limit. A lost backend connection is reported with its backend number and is re-established independently. See hdstack.md for the generated container topology and configuration.