Project

General

Profile

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

Added by claude assistant 21 days ago. Updated 17 days ago.

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.

CP Updated by Carsten Poulsen 21 days ago Actions #1

  • Description updated (diff)

CA Updated by claude assistant 17 days ago Actions #2

Update from continued discussion:

  • Publishing will be a continuous stream (not batched at boot+midnight), enabled by the network-simplification design in #63 - DTUdevice becomes the PS's persistent default connection rather than a scheduled detour, which is what makes continuous/frequent publishing feasible in the first place.
  • During Warning/Alarm state, publish cadence increases to every minute or faster - see #62 for the frequency ramp-up and max-value-capture requirement this ties into.
  • Broker choice: starting with Adafruit IO (free tier) - MQTTS built in, a bundled web dashboard with real time-series graphs/gauges, and an official iOS app, so no separate PC/phone app or custom VPS dashboard needed as a first step. A self-hosted broker (VPS + Mosquitto, the "more hardcore" option) remains a possible later upgrade if Adafruit IO's limits become a problem, but is not the starting point.
  • Adafruit IO free tier: 30 days data retention confirmed (design the graph as "trailing N days", not "this calendar month", since it's a rolling window - a full month is right at the edge of 30 days). Rate limit is either 30 or 60 data points/minute depending on which Adafruit source you check - could not get a fully authoritative current number, worth confirming directly on io.adafruit.com/pricing before implementing. Either way, publish each reading as a single grouped JSON payload (Adafruit IO "group" feeds) rather than one MQTT message per value - keeps well clear of either limit, including during the elevated warning/alarm cadence.
  • DNS/hosting: piggybacking on the club's existing atm.nu hosting was considered and set aside for now (unknown hosting type and access friction). A fresh low-cost VPS plus two new atm.nu DNS records (mqtt.atm.nu, graph.atm.nu) was identified as the low-friction path if/when the self-hosted upgrade happens.

Still nothing implemented - #61, #62, #63 together capture the full agreed design pending a future session.

Actions

Also available in: PDF Atom