atm-environment-alarm-system #61
Updated by Carsten Poulsen 21 days ago
## 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). ### h3. 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.