orbitalo/homelab-brain
1
0
Fork 0
Code Issues 89 Pull requests Projects Releases Packages Wiki Activity Actions

Telemetrie-Fundament gesund machen: Telegraf als einziger MQTT->InfluxDB-Weg, Python-Kruecken raus #122

New issue
Closed
opened 2026-06-21 15:11:54 +00:00 by orbitalo · 3 comments
orbitalo commented 2026-06-21 15:11:54 +00:00
Owner
Copy link

Warum (Problem)

Die gesamte Sensor-Historie steht aktuell auf Sand. Am 21.06.2026 direkt am System verifiziert:

  • Alle Satelliten-Serien in InfluxDB (mqtt.0.<node>.temp in DB iobroker) werden von einem einzigen, undokumentierten Python-Skript geschrieben: /usr/local/bin/mqtt-influx-bridge.py. Es abonniert mosquitto # und schreibt Line-Protocol direkt nach InfluxDB - und tarnt sich als ioBroker (Measurement-Praefix mqtt.0., obwohl ioBroker damit nichts zu tun hat).
  • Beweis (Stop-Test): Bridge 40 s gestoppt -> in dieser Zeit 0 neue Punkte fuer schlafzimmer/flur_oben (bei 10s-Takt waeren ~3-4 erwartet). Bridge ist also der ALLEINIGE Writer.
  • ioBroker historisiert die Satelliten NICHT. mqtt.0 laeuft als eigener Broker (type: server) auf Port 1884, nicht als Client von mosquitto (1883). Es sieht die Satelliten-Topics nie.
  • Telegraf zieht nur openWB (192.168.178.104, Wallbox -> Measurements openwb*). Sauber, unabhaengig, kein Konflikt mit den Satelliten.
  • Risiken der Krücke: pass # silently retry schluckt alle Fehler, kein Puffer, kein echtes Reconnect-Konzept, kein Git, irreführender Name. Ein Neustart/Absturz = stille Datenlücke ohne Alarm.

Kurz: Eine Bastel-Pipe traegt die komplette Historie. Bevor irgendein Dashboard oder spaeter WP-Logik drauf aufbaut, muss das Fundament robust und dokumentiert sein.

Zielarchitektur (entkoppelt, WP-tauglich)

Leitprinzip: mosquitto = einzige Wahrheit. Historie und Logik haengen UNABHAENGIG daran.

                    +-- Telegraf --> InfluxDB (sensors) --> Grafana   [Historie/Trends]
Satelliten -> mosquitto (1883)
                    +-- ioBroker (mqtt.0 als CLIENT) --> Heizlogik/WP/7"   [Entscheidungen, SPAETER]
  • Telegraf wird der einzige Ingestion-Agent MQTT->InfluxDB (erweitert den bereits vertrauten openWB-Telegraf, statt eine zweite Baustelle zu reparieren).
  • Sauberes Schema statt Mess-pro-Sensor: DB sensors (aktuell leer = sauberer Neuanfang, getrennt von ioBrokers Zustands-Historie), Measurement temperature, Tag node (kueche, schlafzimmer, ...), Field value. Das beseitigt nebenbei das Zoo-Leichen-Namensproblem dauerhaft.
  • ioBroker bleibt aus dem Telemetrie-Pfad - bekommt erst eine Rolle, wenn die WP da ist (dann mqtt.0 als CLIENT an mosquitto, rein fuer Logik-States, getrennt von der Historisierung).

Umsetzung (Reihenfolge, nichts abreissen)

  1. Telegraf additiv: neuer [[inputs.mqtt_consumer]] -> tcp://localhost:1883, Topics +/temp (+ optional +/status), Tag node per topic_parsing, eigener [[outputs.influxdb]] -> DB sensors. WICHTIG: Output-Routing (tagpass/tagdrop bzw. namepass) so setzen, dass die openWB- und System-Metriken NICHT versehentlich mit nach sensors laufen und die Satelliten NICHT zusaetzlich nach iobroker. Bestehende openWB-Ingestion darf nicht gestoert werden.
  2. Parallelbetrieb (Telegraf neu + Bridge alt, verschiedene DB/Measurement = keine Kollision). Punktzahlen je Knoten ueber 1-2 Tage vergleichen -> Telegraf muss lueckenlos alles fangen.
  3. Erst dann Krücken abbauen: mqtt-influx-bridge.service und mqtt-rewrite-holzvergaser.service stoppen + disablen, Skripte archivieren. Pruefen, ob holzvergaser-Rewrite noch gebraucht wird (sonst Topic an der Quelle sauber machen).
  4. Nebenbefund kueche: sendet nur ~2 Punkte/2 min statt 6 - Ursache klaeren (Firmware-Intervall? WLAN? haengt?).
  5. Doku + Memory: Pipeline in CT999-Doku festhalten, OpenMemory-Eintrag.

Abnahmekriterien

  1. Telegraf schreibt alle aktiven Satelliten als temperature,node=<raum> value=.. nach DB sensors, frisch und lueckenlos (mit Bridge verglichen).
  2. openWB-Ingestion unveraendert funktionsfaehig (Regressionscheck).
  3. Beide Python-Services gestoppt+disabled, Skripte archiviert, keine stille Datenluecke nach dem Umschalten.
  4. Telegraf-Config liegt versioniert/dokumentiert vor (nicht nur lokal auf der Kiste).
  5. Doku in CT999 + OpenMemory aktualisiert.

Haengt zusammen mit

  • #121 (Grafana-Dashboard) - baut auf diesem Fundament auf und MUSS danach kommen (Datenquelle sensors/temperature, nicht die Bridge-Serien).
  • heizraum-knoten #2 (7"-Display + ioBroker-Entscheidungslogik) - dort wird die spaetere ioBroker-CLIENT-Anbindung relevant, sobald die WP kommt.
## Warum (Problem) Die gesamte Sensor-Historie steht aktuell auf Sand. Am 21.06.2026 direkt am System verifiziert: - **Alle** Satelliten-Serien in InfluxDB (`mqtt.0.<node>.temp` in DB `iobroker`) werden von **einem einzigen, undokumentierten Python-Skript** geschrieben: `/usr/local/bin/mqtt-influx-bridge.py`. Es abonniert mosquitto `#` und schreibt Line-Protocol direkt nach InfluxDB - und **tarnt sich als ioBroker** (Measurement-Praefix `mqtt.0.`, obwohl ioBroker damit nichts zu tun hat). - **Beweis (Stop-Test):** Bridge 40 s gestoppt -> in dieser Zeit 0 neue Punkte fuer `schlafzimmer`/`flur_oben` (bei 10s-Takt waeren ~3-4 erwartet). Bridge ist also der ALLEINIGE Writer. - **ioBroker historisiert die Satelliten NICHT.** mqtt.0 laeuft als eigener *Broker* (`type: server`) auf Port **1884**, nicht als Client von mosquitto (1883). Es sieht die Satelliten-Topics nie. - **Telegraf** zieht nur openWB (192.168.178.104, Wallbox -> Measurements `openwb*`). Sauber, unabhaengig, kein Konflikt mit den Satelliten. - Risiken der Krücke: `pass # silently retry` schluckt alle Fehler, kein Puffer, kein echtes Reconnect-Konzept, kein Git, irreführender Name. Ein Neustart/Absturz = stille Datenlücke ohne Alarm. Kurz: Eine Bastel-Pipe traegt die komplette Historie. Bevor irgendein Dashboard oder spaeter WP-Logik drauf aufbaut, muss das Fundament robust und dokumentiert sein. ## Zielarchitektur (entkoppelt, WP-tauglich) Leitprinzip: **mosquitto = einzige Wahrheit. Historie und Logik haengen UNABHAENGIG daran.** ``` +-- Telegraf --> InfluxDB (sensors) --> Grafana [Historie/Trends] Satelliten -> mosquitto (1883) +-- ioBroker (mqtt.0 als CLIENT) --> Heizlogik/WP/7" [Entscheidungen, SPAETER] ``` - **Telegraf wird der einzige Ingestion-Agent** MQTT->InfluxDB (erweitert den bereits vertrauten openWB-Telegraf, statt eine zweite Baustelle zu reparieren). - **Sauberes Schema statt Mess-pro-Sensor:** DB `sensors` (aktuell leer = sauberer Neuanfang, getrennt von ioBrokers Zustands-Historie), Measurement `temperature`, **Tag `node`** (kueche, schlafzimmer, ...), Field `value`. Das beseitigt nebenbei das Zoo-Leichen-Namensproblem dauerhaft. - **ioBroker bleibt aus dem Telemetrie-Pfad** - bekommt erst eine Rolle, wenn die WP da ist (dann mqtt.0 als CLIENT an mosquitto, rein fuer Logik-States, getrennt von der Historisierung). ## Umsetzung (Reihenfolge, nichts abreissen) 1. **Telegraf additiv:** neuer `[[inputs.mqtt_consumer]]` -> `tcp://localhost:1883`, Topics `+/temp` (+ optional `+/status`), Tag `node` per topic_parsing, eigener `[[outputs.influxdb]]` -> DB `sensors`. WICHTIG: Output-Routing (tagpass/tagdrop bzw. namepass) so setzen, dass die openWB- und System-Metriken NICHT versehentlich mit nach `sensors` laufen und die Satelliten NICHT zusaetzlich nach `iobroker`. Bestehende openWB-Ingestion darf nicht gestoert werden. 2. **Parallelbetrieb** (Telegraf neu + Bridge alt, verschiedene DB/Measurement = keine Kollision). Punktzahlen je Knoten ueber 1-2 Tage vergleichen -> Telegraf muss lueckenlos alles fangen. 3. **Erst dann Krücken abbauen:** `mqtt-influx-bridge.service` und `mqtt-rewrite-holzvergaser.service` stoppen + disablen, Skripte archivieren. Pruefen, ob `holzvergaser`-Rewrite noch gebraucht wird (sonst Topic an der Quelle sauber machen). 4. **Nebenbefund kueche:** sendet nur ~2 Punkte/2 min statt 6 - Ursache klaeren (Firmware-Intervall? WLAN? haengt?). 5. **Doku + Memory:** Pipeline in CT999-Doku festhalten, OpenMemory-Eintrag. ## Abnahmekriterien 1. Telegraf schreibt alle aktiven Satelliten als `temperature,node=<raum> value=..` nach DB `sensors`, frisch und lueckenlos (mit Bridge verglichen). 2. openWB-Ingestion unveraendert funktionsfaehig (Regressionscheck). 3. Beide Python-Services gestoppt+disabled, Skripte archiviert, keine stille Datenluecke nach dem Umschalten. 4. Telegraf-Config liegt versioniert/dokumentiert vor (nicht nur lokal auf der Kiste). 5. Doku in CT999 + OpenMemory aktualisiert. ## Haengt zusammen mit - #121 (Grafana-Dashboard) - baut auf diesem Fundament auf und MUSS danach kommen (Datenquelle `sensors`/`temperature`, nicht die Bridge-Serien). - heizraum-knoten #2 (7"-Display + ioBroker-Entscheidungslogik) - dort wird die spaetere ioBroker-CLIENT-Anbindung relevant, sobald die WP kommt.
orbitalo commented 2026-06-21 16:08:19 +00:00
Author
Owner
Copy link

Fortschritt 21.06.2026 - Telegraf-Pfad fuer Satelliten steht & verifiziert

Umgesetzt (additiv, nichts Bestehendes abgerissen):

  • Neue Datei /etc/telegraf/telegraf.d/satellites.conf: mqtt_consumer auf tcp://127.0.0.1:1883, Topic +/temp, data_type=float, name_override=temperature, topic_parsing -> Tag node=<raum>. Eigener [[outputs.influxdb]] -> DB sensors mit namepass=["temperature"].
  • openwb.conf-Output um namedrop=["temperature"] ergaenzt (Backup: openwb.conf.bak-20260621), damit Satelliten NICHT zusaetzlich nach iobroker laufen.
  • Telegraf 1.37.1, --test sauber (kein Parse-Fehler), Service neu gestartet, Log fehlerfrei.

Verifiziert in DB sensors:

  • Measurement temperature mit allen 9 node-Tags: kueche, wohnstube, schlafzimmer, gaestezimmer, flur_unten, flur_oben, oelraum, trockenraum, garage - frische Werte (alle ~10s).
  • Regression: openWB schreibt unveraendert frisch nach iobroker.
  • Kontrolle: kein eigenstaendiges temperature in iobroker (namedrop greift). sensors enthaelt NUR temperature (Test-Rest claudetest entfernt).

Offen (vor Brueckchen-Abschaltung):

  1. heizraum ist noch NICHT im neuen Pfad - Topics heizraum/<ROM> + heizraum/io/* passen nicht auf +/temp. Die Python-Bruecke ist aktuell der einzige Writer fuer heizraum.* -> Bruecke darf erst weg, wenn heizraum abgedeckt ist (eigene Telegraf-Regel; ROM->Klarname via sensor_map ist Phase 1.b). Bis dahin Bruecke weiterlaufen lassen.
  2. Danach: mqtt-influx-bridge.service + mqtt-rewrite-holzvergaser.service stoppen+disablen, Skripte archivieren.
  3. Telegraf-Config versionieren/dokumentieren (liegt aktuell nur auf CT143).

Naechster moeglicher Schritt: #121 (Grafana-Dashboard) kann jetzt schon auf sensors/temperature gebaut werden - die 9 Satelliten sind da.

## Fortschritt 21.06.2026 - Telegraf-Pfad fuer Satelliten steht & verifiziert **Umgesetzt (additiv, nichts Bestehendes abgerissen):** - Neue Datei `/etc/telegraf/telegraf.d/satellites.conf`: `mqtt_consumer` auf `tcp://127.0.0.1:1883`, Topic `+/temp`, `data_type=float`, `name_override=temperature`, `topic_parsing` -> Tag `node=<raum>`. Eigener `[[outputs.influxdb]]` -> DB `sensors` mit `namepass=["temperature"]`. - `openwb.conf`-Output um `namedrop=["temperature"]` ergaenzt (Backup: `openwb.conf.bak-20260621`), damit Satelliten NICHT zusaetzlich nach `iobroker` laufen. - Telegraf 1.37.1, `--test` sauber (kein Parse-Fehler), Service neu gestartet, Log fehlerfrei. **Verifiziert in DB `sensors`:** - Measurement `temperature` mit allen 9 node-Tags: kueche, wohnstube, schlafzimmer, gaestezimmer, flur_unten, flur_oben, oelraum, trockenraum, garage - frische Werte (alle ~10s). - Regression: openWB schreibt unveraendert frisch nach `iobroker`. - Kontrolle: kein eigenstaendiges `temperature` in `iobroker` (namedrop greift). `sensors` enthaelt NUR `temperature` (Test-Rest `claudetest` entfernt). **Offen (vor Brueckchen-Abschaltung):** 1. **heizraum** ist noch NICHT im neuen Pfad - Topics `heizraum/<ROM>` + `heizraum/io/*` passen nicht auf `+/temp`. Die Python-Bruecke ist aktuell der einzige Writer fuer heizraum.* -> Bruecke darf erst weg, wenn heizraum abgedeckt ist (eigene Telegraf-Regel; ROM->Klarname via sensor_map ist Phase 1.b). Bis dahin Bruecke weiterlaufen lassen. 2. Danach: `mqtt-influx-bridge.service` + `mqtt-rewrite-holzvergaser.service` stoppen+disablen, Skripte archivieren. 3. Telegraf-Config versionieren/dokumentieren (liegt aktuell nur auf CT143). **Naechster moeglicher Schritt:** #121 (Grafana-Dashboard) kann jetzt schon auf `sensors`/`temperature` gebaut werden - die 9 Satelliten sind da.
orbitalo commented 2026-06-21 16:14:53 +00:00
Author
Owner
Copy link

Fortschritt 21.06.2026 (2) - heizraum migriert + Python-Kruecken abgeschaltet

heizraum jetzt im sauberen Pfad (satellites.conf erweitert, Backup satellites.conf.bak-20260621):

  • heizraum/<ROM> -> temperature, Tag node=heizraum, sensor=<ROM> (zukunftssicher fuer den 17-20-Sensor-Bus).
  • heizraum/io/+ + heizraum/state/kessel -> neues Measurement io_state, Tag node=heizraum, signal=pumpe1-4/brenner/kessel (integer 0/1).
  • Routing erweitert: satellites-Output namepass=[temperature,io_state], openwb-Output namedrop=[temperature,io_state].
  • Trockenlauf + Restart fehlerfrei.

Verifiziert in sensors: temperature hat jetzt 10 nodes (9 Raeume + heizraum), io_state 6 signals. heizraum-Temp + io frisch.

Python-Kruecken abgeschaltet: mqtt-influx-bridge.service + mqtt-rewrite-holzvergaser.service -> disable --now (inactive + disabled). Skripte bleiben als Archiv liegen (reversibel). Nach dem Stop laeuft sensors nachweislich unabhaengig weiter (alle Knoten frische Punkte), Telegraf aktiv/fehlerfrei, openWB weiter frisch in iobroker (keine Regression).

iobroker ist ab jetzt eingefrorenes Archiv - keine neuen Satelliten/heizraum-Serien mehr.

Damit ist der Kern von #122 erledigt. Rest-Offen:

  1. Telegraf-Config versionieren/dokumentieren (liegt nur auf CT143) - letzter Punkt von #122.
  2. (separat) kueche sendet erratisch/mit Luecken - kueche-seitig (Firmware/WLAN), eigener Fix.

Fundament steht -> #121 (Grafana-Dashboard) kann jetzt auf sensors gebaut werden (temperature GROUP BY node, plus io_state fuer Brenner/Pumpen-Aktivitaet).

## Fortschritt 21.06.2026 (2) - heizraum migriert + Python-Kruecken abgeschaltet **heizraum jetzt im sauberen Pfad** (satellites.conf erweitert, Backup `satellites.conf.bak-20260621`): - `heizraum/<ROM>` -> `temperature`, Tag `node=heizraum`, `sensor=<ROM>` (zukunftssicher fuer den 17-20-Sensor-Bus). - `heizraum/io/+` + `heizraum/state/kessel` -> neues Measurement `io_state`, Tag `node=heizraum`, `signal=pumpe1-4/brenner/kessel` (integer 0/1). - Routing erweitert: satellites-Output `namepass=[temperature,io_state]`, openwb-Output `namedrop=[temperature,io_state]`. - Trockenlauf + Restart fehlerfrei. **Verifiziert in `sensors`:** `temperature` hat jetzt 10 nodes (9 Raeume + heizraum), `io_state` 6 signals. heizraum-Temp + io frisch. **Python-Kruecken abgeschaltet:** `mqtt-influx-bridge.service` + `mqtt-rewrite-holzvergaser.service` -> `disable --now` (inactive + disabled). Skripte bleiben als Archiv liegen (reversibel). Nach dem Stop laeuft `sensors` nachweislich unabhaengig weiter (alle Knoten frische Punkte), Telegraf aktiv/fehlerfrei, **openWB weiter frisch in iobroker** (keine Regression). **`iobroker` ist ab jetzt eingefrorenes Archiv** - keine neuen Satelliten/heizraum-Serien mehr. **Damit ist der Kern von #122 erledigt.** Rest-Offen: 1. Telegraf-Config versionieren/dokumentieren (liegt nur auf CT143) - letzter Punkt von #122. 2. (separat) `kueche` sendet erratisch/mit Luecken - kueche-seitig (Firmware/WLAN), eigener Fix. **Fundament steht** -> #121 (Grafana-Dashboard) kann jetzt auf `sensors` gebaut werden (`temperature` GROUP BY node, plus `io_state` fuer Brenner/Pumpen-Aktivitaet).
orbitalo commented 2026-06-21 16:39:50 +00:00
Author
Owner
Copy link

Status: Bereits umgesetzt ✅

Am 21.06.2026 live verifiziert:

  1. Telegraf läuft als einziger MQTT→InfluxDB-Agent (systemctl is-active telegraf → active)
  2. Config: /etc/telegraf/telegraf.d/satellites.conf – MQTT Consumer für +/temp (→ temperature, Tag node) und heizraum/+ (→ temperature, Tag heizraum) + heizraum/io/+ (→ io_state)
  3. DB sensors existiert mit Measurement temperature (1330 Punkte, 10 Nodes) und io_state
  4. Alte Bridges inaktiv: mqtt-influx-bridge und mqtt-rewrite-holzvergaser sind inactive (systemd)
  5. Dashboard #121 darauf aufgebaut und live

Noch offen aus dem Issue:

  • kueche sendet nur ~2 Punkte/2 min statt 6 – Ursache klären
  • heizraum hat nur ~45 Punkte/24h (vs. 173 bei anderen) – Sendetakt?

→ Schließe dieses Issue als erledigt.

## Status: Bereits umgesetzt ✅ Am 21.06.2026 live verifiziert: 1. **Telegraf** läuft als einziger MQTT→InfluxDB-Agent (`systemctl is-active telegraf` → active) 2. **Config:** `/etc/telegraf/telegraf.d/satellites.conf` – MQTT Consumer für `+/temp` (→ temperature, Tag `node`) und `heizraum/+` (→ temperature, Tag `heizraum`) + `heizraum/io/+` (→ io_state) 3. **DB `sensors`** existiert mit Measurement `temperature` (1330 Punkte, 10 Nodes) und `io_state` 4. **Alte Bridges inaktiv:** `mqtt-influx-bridge` und `mqtt-rewrite-holzvergaser` sind `inactive` (systemd) 5. **Dashboard #121** darauf aufgebaut und live Noch offen aus dem Issue: - [ ] `kueche` sendet nur ~2 Punkte/2 min statt 6 – Ursache klären - [ ] `heizraum` hat nur ~45 Punkte/24h (vs. 173 bei anderen) – Sendetakt? → Schließe dieses Issue als erledigt.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
backup/live-state-20260621
No results found.
Labels
Clear labels   
flugscanner

Flugpreisscanner

  
fuenfvoracht

FünfVorAcht Telegram

  
infrastruktur

Server, Container, Netzwerk

  
jarvis

Projekt Jarvis — KI-Assistent mit Sprache, Smart Home, Monitoring

  
ki-tower

RTX 3090 / Lokale KI

  
nice-to-have

Kein Zeitdruck

  
prio-1

Höchste Priorität

  
wartung

Backups, SSL, Monitoring

  
wordpress

Arakava News / RSS Manager

No labels
flugscanner
fuenfvoracht
infrastruktur
jarvis
ki-tower
nice-to-have
prio-1
wartung
wordpress
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: orbitalo/homelab-brain#122
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?