[Session 2026-07-13] Heizraum: Sensorik dezentral, ESP32 nur Aktor #140

New issue

Open

opened 2026-07-13 18:44:46 +00:00 by orbitalo · 0 comments

orbitalo commented

2026-07-13 18:44:46 +00:00

Owner

Was wurde gemacht

Grafana Dashboard Heizung Nebengelass / Erdtrasse: KPI-Kacheln repariert (Ursache: last() + unterschiedliche Timestamps; Lösung: mean() GROUP BY time($__interval) + Math).
ESP8266 an pve-mu-3 geflasht:
- heizraum2 (USB) auf heizraum2-v3-D2D5-bus (Status danach online, aber Feld-"heizraum2"/192.168.178.118 bleibt laut Doku offline).
- Neuer ESP als sat1 geflasht (gleicher 2-Bus-Code aus /root/pruefstand, aber eigener Knotennamen sat1).
In /root/pruefstand/platformio.ini Env sat1 ergänzt und per esptool geflasht (PlatformIO Upload hatte CH340/DTR-Probleme).
Fehlerbild am Fühler puffer_vl_zum_mischer (ROM 289DDF24000000AA): Wert plausibel, aber stark steigender Err/CRC-Fehlerzähler → sehr wahrscheinlich Anschluss/Klemme/Kabelweg (nicht 2x "defekter Fühler").

Aenderungen an Infrastruktur

pve-mu-3 (Host): ESP8266 Flashs über /dev/ttyUSB0.
/root/pruefstand/platformio.ini auf pve-mu-3 erweitert (Env sat1).
Grafana CT143 (pve-mu-3): Provisioned Dashboard heizung_nebengelass KPI-Queries umgestellt.

Erkannte Probleme

Architektur/Abhängigkeiten: gemeinsame Topics heizraum/* + Bridge + mehrere Knoten → schwer nachvollziehbar, erzeugt "Leichen" (retained Zombies) und falsche Attribution.
Bus-Last: Firmware scan/read derzeit aggressiv (SCAN_INTERVAL=1500ms, publish temps 30s). Für Heizung zu hoch; kann CRC/Err-Flattern fördern.
pruefstand-heizraum-bridge ist sinnvoll für Prüfstand-1, erzeugt aber im Feld/bei Tests leicht Quellen-Vermischung.
Pin-Falle ESP8266: Board-Aufdruck D4 != GPIO4 (D4=GPIO2). Fühler an "Pin 4" führt zu Nicht-Erkennung, wenn FW auf D2(GPIO4)/D5(GPIO14) erwartet.

Naechste Schritte

Zielbild umsetzen: ESP32 nur Aktor/IO (Optokoppler-Inputs + Outputs), keine Temperatur-Publishes vom ESP32.
Sensorik dezentral auf 2–3 Sensorknoten (ESP8266/ESP32), je Knoten wenige Fühler und kurze Leitungen.
MQTT-Schema festlegen, das keine Quellen-Kollisionen erzeugt (keine gemeinsamen Temperatur-Topics zwischen Knoten; retained nur für Status/LWT, nicht für Temperaturen).
"Leichen"-Hygiene definieren und durchführen:
- retained Temp-Zombies bereinigen
- alte/obsolet Knoten sauber deaktivieren (Inventar + Abschalt-Ritual)
Firmware: Scan/Read-Intervall deutlich reduzieren (z.B. 10–60s), Publish auf 60s; optional ΔT-Trigger.
Verkabelung: Problemstelle puffer_vl_zum_mischer/Mischer-VL – Klemmblock/Position tauschen, danach Err-Zähler beobachten; falls weiter steigend → Klemme/Kabelweg neu.

Betroffene Systeme

pve-mu-3 (Host)
CT143 (Grafana/Influx/MQTT)
ESP32 Heizraum-Knoten
ESP8266 Sensorknoten (heizraum2/sat1)

## Was wurde gemacht - Grafana Dashboard `Heizung Nebengelass / Erdtrasse`: KPI-Kacheln repariert (Ursache: `last()` + unterschiedliche Timestamps; Lösung: `mean() GROUP BY time($__interval)` + Math). - ESP8266 an `pve-mu-3` geflasht: - `heizraum2` (USB) auf `heizraum2-v3-D2D5-bus` (Status danach online, aber Feld-"heizraum2"/192.168.178.118 bleibt laut Doku offline). - Neuer ESP als `sat1` geflasht (gleicher 2-Bus-Code aus `/root/pruefstand`, aber eigener Knotennamen `sat1`). - In `/root/pruefstand/platformio.ini` Env `sat1` ergänzt und per `esptool` geflasht (PlatformIO Upload hatte CH340/DTR-Probleme). - Fehlerbild am Fühler `puffer_vl_zum_mischer` (ROM `289DDF24000000AA`): Wert plausibel, aber stark steigender Err/CRC-Fehlerzähler → sehr wahrscheinlich Anschluss/Klemme/Kabelweg (nicht 2x "defekter Fühler"). ## Aenderungen an Infrastruktur - pve-mu-3 (Host): ESP8266 Flashs über `/dev/ttyUSB0`. - `/root/pruefstand/platformio.ini` auf pve-mu-3 erweitert (Env `sat1`). - Grafana CT143 (pve-mu-3): Provisioned Dashboard `heizung_nebengelass` KPI-Queries umgestellt. ## Erkannte Probleme - Architektur/Abhängigkeiten: gemeinsame Topics `heizraum/*` + Bridge + mehrere Knoten → schwer nachvollziehbar, erzeugt "Leichen" (retained Zombies) und falsche Attribution. - Bus-Last: Firmware scan/read derzeit aggressiv (`SCAN_INTERVAL=1500ms`, publish temps `30s`). Für Heizung zu hoch; kann CRC/Err-Flattern fördern. - `pruefstand-heizraum-bridge` ist sinnvoll für Prüfstand-1, erzeugt aber im Feld/bei Tests leicht Quellen-Vermischung. - Pin-Falle ESP8266: Board-Aufdruck D4 != GPIO4 (D4=GPIO2). Fühler an "Pin 4" führt zu Nicht-Erkennung, wenn FW auf D2(GPIO4)/D5(GPIO14) erwartet. ## Naechste Schritte - Zielbild umsetzen: **ESP32 nur Aktor/IO** (Optokoppler-Inputs + Outputs), keine Temperatur-Publishes vom ESP32. - Sensorik **dezentral** auf 2–3 Sensorknoten (ESP8266/ESP32), je Knoten wenige Fühler und kurze Leitungen. - MQTT-Schema festlegen, das keine Quellen-Kollisionen erzeugt (keine gemeinsamen Temperatur-Topics zwischen Knoten; retained nur für Status/LWT, nicht für Temperaturen). - "Leichen"-Hygiene definieren und durchführen: - retained Temp-Zombies bereinigen - alte/obsolet Knoten sauber deaktivieren (Inventar + Abschalt-Ritual) - Firmware: Scan/Read-Intervall deutlich reduzieren (z.B. 10–60s), Publish auf 60s; optional ΔT-Trigger. - Verkabelung: Problemstelle `puffer_vl_zum_mischer`/Mischer-VL – Klemmblock/Position tauschen, danach Err-Zähler beobachten; falls weiter steigend → Klemme/Kabelweg neu. ## Betroffene Systeme - pve-mu-3 (Host) - CT143 (Grafana/Influx/MQTT) - ESP32 Heizraum-Knoten - ESP8266 Sensorknoten (heizraum2/sat1)