Add initial MQTT scrubber service scaffold

docs/WORKPLAN.md

@@ -0,0 +1,86 @@
+# Work Plan
+
+## Goal
+
+Build a simple Go daemon that runs continuously, subscribes to MQTT topics from home automation devices with Tasmota as the primary source, normalizes payloads, and stores the resulting time-series data in InfluxDB v3.
+
+## Milestones
+
+### Milestone 1: Ingestion skeleton
+
+Estimate: 1 to 2 days
+
+- create runnable Go service with config loading and structured logging
+- connect to MQTT with reconnect support
+- subscribe to `tele/+/SENSOR` and `tele/+/STATE`
+- enqueue incoming messages without blocking the MQTT callback path
+- batch and write records to InfluxDB v3
+- implement graceful shutdown with final flush
+
+Definition of done:
+
+- service can run unattended for several hours
+- on restart it reconnects and resumes subscriptions
+- valid payloads reach InfluxDB
+
+### Milestone 2: Tasmota normalization
+
+Estimate: 1 to 2 days
+
+- collect sample payloads from real devices
+- normalize nested Tasmota JSON into stable field keys
+- derive a schema for measurement, tags, and fields
+- support `SENSOR` and `STATE` payload families cleanly
+- add parser unit tests for the most common device payloads
+
+Definition of done:
+
+- representative payloads from real devices parse consistently
+- field names stay stable across restarts and devices
+- parse failures are visible in logs and do not crash the daemon
+
+### Milestone 3: Operational hardening
+
+Estimate: 1 to 2 days
+
+- expose counters for received, parsed, written, dropped, and failed messages
+- improve retry behavior and failure logging for Influx writes
+- ensure bounded buffering and predictable memory use
+- add sample deployment instructions for systemd or Docker
+- document configuration and failure modes
+
+Definition of done:
+
+- service behavior under broker or Influx outages is understood and documented
+- logs are enough to diagnose the common failure modes
+- memory and buffering remain bounded under load
+
+### Milestone 4: Broader topic support
+
+Estimate: 2 to 4 days
+
+- add more Tasmota topics if needed, for example `stat/+/STATUS10`
+- add device-specific enrichments only when justified by real payloads
+- optionally separate measurements by domain such as energy, climate, and state
+- add integration tests with a local MQTT broker and InfluxDB instance
+
+Definition of done:
+
+- new topic families are added without destabilizing the core pipeline
+- schema remains low-cardinality and query-friendly
+
+## Backlog
+
+- persistent local spool for outage tolerance
+- dead-letter handling for invalid payloads
+- health endpoint or Prometheus metrics
+- config reload without restart
+- per-topic parser routing for non-Tasmota devices
+- retention and schema review once real data volume is known
+
+## Delivery order
+
+1. Make the daemon run reliably with a narrow scope.
+2. Lock in the Tasmota schema from real samples.
+3. Add visibility and failure handling.
+4. Broaden topic coverage only after the core path is stable.