Actions
atm-environment-alarm-system #61
open
CA
MQTT telemetry to boeghpoulsen.dk via DTUdevice hop
atm-environment-alarm-system #61:
MQTT telemetry to boeghpoulsen.dk via DTUdevice hop
Status:
New
Priority:
normal
Assignee:
-
% Done:
0%
Type:
Design
Description
Architecture sketch discussed with Claude (not yet implemented):¶
- PS continues to store measurements locally as today (LittleFS ring buffer), unchanged.
- At the existing DTU hop (power-up + local midnight, see #58), in addition to the NTP sync already implemented, the PS would also publish a batch of measurements/alarm events queued since the last successful hop, over MQTT (TLS) to a broker on Carsten's Synology NAS at boeghpoulsen.dk.
- Broker (Mosquitto) exposed on a dedicated port via direct router port-forward to the NAS - not via Synology's reverse proxy (reverse-proxy setup has had issues on that box).
- No new connection schedule - publishing batches into the existing boot+midnight DTU hops rather than adding more frequent interruptions to local PFClubs browsing.
- Purpose: lets Carsten view historical/trend data from home. MQTT publish is outbound-only, so this sidesteps the inbound restrictions on both PFClubs and DTUdevice entirely (no port-forwarding into the PS itself needed).
Critical caveat - must hold before implementation¶
This integration depends on things outside the PS's control: Carsten's continued access/membership to the broker or server, DNS, network policy, credential validity, etc. If the broker is unreachable, rejects the connection, or messages can't be delivered, this must not crash, hang, or otherwise destabilize the PS - the core sensor/alarm function must remain completely unaffected regardless of MQTT/broker state.
Concretely, implementation must:
- Use a bounded outgoing queue with a clear drop policy (e.g. drop-oldest), never unbounded buffering.
- Treat every MQTT failure mode as non-fatal.
- Not trip the crash-loop or hung-task watchdog (#17) due to network/broker unavailability.
Actions