Transmitter — Roadmap (Historical)
:::caution Status
Build complete. Source (docs/transmitter-device-module-roadmap.md) is explicitly marked by its authors as "a historical log, not a current spec" — Phases 1–5 all shipped 2026-07-17. The broker, the provisioning backend, and the trigger topic scheme have all changed since. Corrections are noted inline below where this roadmap's original text would otherwise mislead a current reader.
:::
For current, non-historical behavior use these instead of this page:
MQTT Protocol (wire contract, kept live),
Transmitter module (architecture),
Device Registry Unification (the
backend that replaced this roadmap's mosque_devices-is-the-source-of-truth
model).
What shipped (2026-07-17)
| Phase | Scope | Status | Effort |
|---|---|---|---|
| 1 | Data model + backend CRUD foundation — mosque_devices table, mosque_device_events, all CRUD/claim/announce/cmd endpoints, fake-device reference implementation | ✅ Implemented | 3–4 days |
| 2 | Presence pipeline — DeviceStatusService, MQTT subscriber, connectivity-vs-reported-status split, stale sweep, alert hooks | ✅ Implemented | 3 days |
| 3 | Admin-panel module — TransmittersScreen.jsx, rich status pills, config edit drawer, Ping/Test tone/Identify/Stop/Reboot, add-device flows | ✅ Implemented | 4–5 days |
| 4 | Health checks & diagnostics — periodic MQTT ping probe, heartbeat sample history, 24h uptime, post-azan played-confirmation | ✅ Implemented | 3–5 days |
| 5 | Alerts & rollout hardening — debounced offline/recovered alerts, super-admin fleet view, Device Inventory module, Sales Invoices module, broadcast-audit unification | ✅ Implemented | 3–4 days |
Minimum shippable slice was Phases 1–3 (~2.5 weeks). All five phases,
plus several same-day addenda (Device Inventory page, Sales Invoices
module, super-admin dashboard restructure, broadcast-audit origin/
devices_expected/devices_played fields) shipped the same day per the
source log.
What has since changed underneath this roadmap
The roadmap's own text is corrected here rather than rewritten, so a reader who has the original can see exactly what moved:
| This roadmap said (2026-07-17) | What's true now |
|---|---|
| Broker: HiveMQ free tier | Self-hosted EMQX (AZD-40/41) — see Device Deployment. Removes the 100-connection/10GB-month ceiling this roadmap flagged as a risk. |
Trigger topic: mosque-wide masjidconnect/{mosqueId}/trigger | Retired entirely. Azaan is now a per-device play command on the transmitter's own cmd topic, same shape as a stream player's — see MQTT — Commands. |
mosque_devices is the source of truth for provisioning | Superseded by the unified devices/device_registry backend — see Device Registry Unification. mosque_devices stays only for wire compatibility, kept in sync by DB triggers. |
Approve/reject endpoints on mosque_devices.py | Deleted (AZD-136/144). Device authorization is Super Admin only, for every device kind, via the unified device-registry endpoints. |
| Not in scope | Transmitter audio uplink (mic/line-in → Icecast → per-device fan-out) shipped as a new capability this roadmap never anticipated — see MQTT — Transmitter Audio Uplink. |
Remaining open item
Per-device broker credentials/ACL for transmitters. Shipped for stream
players (EMQX migration 0013, normative per-device ACL); transmitters
still use a shared fleet credential. Per the source document, this is
recorded as a deliberate stance, not currently planned as an upgrade —
not a gap awaiting a fix. If this changes, it belongs in
Device Deployment's broker ACL section,
not this historical roadmap.
Deployment caveat noted in the original log
Two backend instances sharing one database both consume device MQTT messages — change detection can race and alerts can double or drop. The pilot deployment runs a single instance; scale-out needs a leader/lock on the subscriber (noted alongside per-device broker ACLs as an upgrade trigger, not a scheduled item).