[Frage] [V4.5] Massenhaft Sensorwerte an Homeassistant

[ms20de]

Hallo Georg,

keine Sorge, das Verhalten ist absolut korrekt und beabsichtigt! Du bist hier nur über die Performance-Optimierung "gestolpert", die ich auf Anraten von Matthias (@ms20de) eingebaut habe.

Lass mich kurz erklären, was da passiert, damit du sicher bist, dass alles läuft:

1. Die Diagnose (Warum ist das Feld leer?)
In der V5.1 haben wir ein Break-Modul eingebaut. Das ist eine "Schranke".

Vor der Schranke: Der Watchdog (läuft immer, millisekundengenau).

Hinter der Schranke: Der JSON-Bau (Text-Formatierung). Dieser Teil ist "teuer" für die CPU.

Damit dein Server bei vielen Sensoren nicht ins Schwitzen kommt, öffnet sich diese Schranke nur exakt in dem Moment, wenn dein Sendeintervall (bei dir 30s) zuschlägt.
In den 29,9 Sekunden dazwischen bricht die Logik vorher ab. Da du die Logik gerade erst gestartet hast, war die Schranke noch nie offen -> Die internen Text-Variablen sind noch leer -> Der Ausgang ist leer.

2. Das richtige Vorgehen
Du musst eigentlich nichts tun, außer einmalig das Intervall abwarten.

[...]

Fazit:
Das "Leere Feld" ist der Beweis, dass die CPU-Schonung funktioniert.
Warte kurz auf den nächsten Takt, dann sollte da {"V1": ...} stehen.

Liebe KI du hast da einen Fehler gemacht.
Die CPU schonst du richtig mit dem Break-Modul.
Aber du setzt das Level welches mit den Ausgang verbunden ist nach der erfolgreichen Erzeugung des JSONs auf einen leeren String.
Das passiert in dieser Anweisung ["Latch", "$Lgc_JSON_Raw", "$O_JSON", "$Konst_True", 0]
Denke daran, dass der Ausgang erst geschrieben wird, wenn alle Logik-Module abgearbeitet wurden.
Wenn man diese Zeile entfernt, dann wird der korrekte String am Ausgang ausgeben.

Viele Grüße,
Matthias

[pholler]

Guten Morgen,
danke Matthias!
@eib-eg, könntest du deine KI nochmal um eine Aktualisierung bitten.

Hier noch ein "größerer" Screenshot:

Screenshot 2025-12-01 at 04.47.52.png

[eib-eg]

Natürlich
Heute Abend
Leider geht es nicht früher

[eib-eg]

Hallo Matthias @ms20de , hallo Peter @pholler ,

erstmal: Asche auf mein Haupt (und das meiner KI-Abteilung)!
Da haben wir uns tatsächlich verheddert. Diese spezifische Kombination aus "Echtzeit-Überwachung" (Watchdog) und "gedrosselter Ausgabe" (Performance-Break) war auch für meinen Kanon Neuland. Das Zusammenspiel von Timern, Latches und dem Break-Modul hat seine Tücken, wenn man nicht höllisch aufpasst.

Aber genau dafür ist die Community (und ein aufmerksamer Chef-Entwickler) da. Danke Matthias, für den entscheidenden Hinweis mit dem Timer-Modus! Das war der Schlüssel.

Wir haben den Fehler nicht nur gefixt, sondern direkt zur "Härtung des Kanons" genutzt. Ab sofort gibt es eine strikte Regel: Watchdogs immer nachtriggerbar (Mode 3), Speicher-Latches immer VOR das Break. Damit passiert uns das nicht nochmal.

Hier ist nun die Version 5.3, die (hoffentlich final) alle Probleme löst:

Die Fixes im Detail:

1. Leerer String: Das überflüssige Latch am Ende wurde entfernt. Der JSON-String wird jetzt direkt (geschützt durch das Break) auf den Ausgang geschrieben.

2. Falscher Alarm: Die Monoflops laufen jetzt im Mode 3 (Retriggerbar). Damit wird der Timer bei jedem Sensor-Signal sauber zurückgesetzt und läuft nicht mehr fälschlicherweise ab, solange Daten kommen.

@pholler : Damit sollte jetzt alles stabil laufen und auch Werte anzeigen.

Anhang:

1-Wire Hybrid V5.3 (Fix Retrigger & Empty String).txt

Generiert nach ElabNET-Standard

1. Titel (Kurz)
Hybrid: JSON Aggregator & Watchdog 8-fach (Final Edition)

2. Untertitel
Bündelt Messwerte für MQTT, überwacht Sensoren individuell in Echtzeit und minimiert CPU-Last.

3. Zusatztext für das Verständnis
Diese Logik ist die ultimative "Hybrid-Lösung" für 1-Wire und MQTT Nutzer. Sie löst zwei Aufgaben gleichzeitig:

Überwachung (Watchdog): Jeder der 8 Eingänge wird individuell auf Ausfall überwacht. Fällt ein Sensor aus, wird die Fehler-Bitmaske sofort aktualisiert. Durch den Ausgangs-Trigger "On Change" werden Änderungen sofort gemeldet, aber dauerhafte Fehler erzeugen keine unnötige Buslast.

Daten-Bündelung (Aggregator): Die Werte werden zu einem JSON-String zusammengefasst ({"V1":20.5, ...}), um MQTT-Objekte zu sparen.
Performance-Feature: Durch den Einsatz des Break-Moduls ist die Logik in zwei Sektoren geteilt. Die rechenintensive Text-Erstellung (JSON) wird vom Echtzeit-Watchdog entkoppelt und nur noch im eingestellten Sende-Takt ausgeführt.

4. Kern-Module
Triggered, Monoflop (Mode 3), BinaryMultiplexer, Clocksignal, Break, Printf, Concat

5. Kern-Operation

Sektor A (Echtzeit): Timer-Reset bei Signaleingang -> Bitmasken-Update -> Ausgabe nur bei Statusänderung.

Sektor B (Getaktet): Abbruch via Break wenn kein Sende-Takt -> String-Formatierung -> JSON-Output.

6. Beschreibung Kern-Eingänge

Wert 1-8: [Float] Die Messwerte. WICHTIG: Trigger muss zwingend auf "a" (Always) stehen.

Timeout 1-8: [Float] Individuelle Zeit in Sekunden bis zum Alarm. 0.0 = Kanal deaktiviert (Auto-Disable).

Sendeintervall: [Float] Zeit in Sekunden für das JSON-Update (Drossel für Sektor B).

7. Beschreibung Kern-Ausgänge

JSON String: [String] Der fertige Payload für MQTT. Wird nur im Sendeintervall aktualisiert.

Fehler Bitmaske: [Integer] Summe der ausgefallenen Sensoren (Bit 0 = Sensor 1, etc.). Wird sofort bei Statusänderung gesendet.

8. Hinweise / Ergänzendes
Durch die Auto-Disable Funktion (Timeout = 0) können ungenutzte Eingänge offen gelassen werden.

9. Erweiterte Mouse-Overs

Wert 1-8: "Messwert. Trigger auf 'a' (Always) stellen!"

Timeout 1-8: "Max. Zeit ohne Signal. 0 = Kanal inaktiv."

Sendeintervall: "Taktung für JSON-Ausgabe."

Fehler Bitmaske: "Diagnose-Code. Bit 0=Kanal 1, Bit 1=Kanal 2..."






ANWENDER-GUIDE: So nutzt du den "1-Wire Hybrid Wächter" (V5.3)

Du hast viele Sensoren (z.B. 1-Wire), möchtest diese zuverlässig überwachen und die Daten effizient an MQTT (z.B. Home Assistant) senden, ohne deinen Server zu überlasten?
Dann ist diese Logik genau für dich.
1. Was macht dieser Baustein eigentlich?

Er erledigt zwei Jobs gleichzeitig:

JOB A: Der Datensammler (JSON Aggregator)
Anstatt für jeden Sensor eine eigene MQTT-Nachricht zu schicken (was bei vielen Sensoren das Netzwerk flutet), sammelt er 8 Werte ein, verpackt sie in ein einziges Paket (JSON) und schickt dieses Paket gemütlich in einem festen Takt (z.B. alle 60 Sekunden) raus.

JOB B: Der Wachhund (Watchdog)
Er passt auf jeden deiner 8 Sensoren einzeln auf. Wenn ein Sensor sich nicht mehr meldet (z.B. Kabelbruch), schlägt er sofort Alarm.

2. Einrichtung: Schritt für Schritt

Schritt 1: Die Eingänge (Werte)
Verbinde deine Sensoren mit den Eingängen Wert 1 bis Wert 8.

WICHTIG: Du musst den Trigger-Modus dieser Eingänge zwingend auf "a" (Always / Immer) stellen!

Warum? Ein 1-Wire Sensor sendet regelmäßig seinen Wert, auch wenn sich die Temperatur nicht ändert (Heartbeat). Wenn du auf "c" (Change) stellst, denkt die Logik bei gleichbleibender Temperatur, der Sensor sei tot, und löst Fehlalarm aus.

Schritt 2: Die Überwachung (Timeouts)
Jeder Sensor hat einen eigenen Parameter Timeout 1 bis Timeout 8. Das ist die Zeit in Sekunden, nach der Alarm geschlagen wird, wenn nichts mehr empfangen wurde.

Faustformel: Schau im Gerätemanager auf das Sendeintervall (i) des Sensors. Nimm diesen Wert mal 3.

Beispiel: Sensor sendet alle 60s -> Stelle Timeout auf 180 oder 200.

Kanal abschalten: Hast du nur 5 Sensoren angeschlossen? Kein Problem. Lasse die Timeouts der leeren Kanäle einfach auf 0. Die Logik erkennt das und deaktiviert die Überwachung für diese Kanäle automatisch.

Schritt 3: Der Datentakt (Sendeintervall)
Hier stellst du ein, wie oft das Datenpaket an MQTT gesendet werden soll (z.B. 60 Sekunden).

Der Clou: Die Logik arbeitet intern extrem ressourcenschonend. Sie berechnet den Text für das Datenpaket wirklich nur in diesem Takt. Das schont die CPU deines Timberwolfs massiv.

3. Häufige Fragen & "Aha-Effekte"

"Warum ist das JSON-Feld am Anfang leer?"
Wenn du die Logik frisch startest (oder speicherst), siehst du im Ausgang erst mal nichts (leerer Text).

Das ist kein Fehler, das ist das Spar-Programm!

Da die Logik nur im Takt (z.B. alle 60s) rechnet, musst du nach dem Start einfach einmalig warten, bis die 60 Sekunden um sind. Dann erscheint der Text.

"Wie lese ich den Fehler-Code (Bitmaske)?"
Der Ausgang Fehler Bitmaske zeigt dir als Zahl an, wer ausgefallen ist. Es ist eine Summe:

0 = Alles OK.

1 = Sensor 1 defekt.

2 = Sensor 2 defekt.

3 = Sensor 1 UND 2 defekt (1+2).

4 = Sensor 3 defekt.

... usw.

Viel Erfolg beim Überwachen und Daten-Sammeln!


mfg
eib-eg und ki

[pholler]

Danke! Im ersten Test funktionert das super!!!

Wenn ich ganz frech sein darf. Sind die Namen der Eingänge über Code abfragbar? Also könnte man statt V1, V2, V3, usw. den Namen der jeweiligen Eingänge automatisch befüllen lassen?

[eib-eg]

Wenn ich Gans frech bin dann sage ich dir das das geht
Und zwar automatisch mit dem ki prompt
Du gibst der ki eine vordefinierte Auswahl an Slave id sowie die dazugehörige Beschriftung wie auch immer indem du diese Seite markierst und der ki das gibst und sagst sie soll als Beispiel die Slave id als eingangsverknüpfungobjekt bezeichnen den maus over deine Beschriftung
Oder umgekehrt wie du willst
Der Vorteil mit der id als Anzeige ist das du das kopieren kannst und bei der Verknüpfung als Suche verwendest
Somit hast du zu 100% immer den richtigen bzw. die richtige Abfrage zu dem Eingang

Es gibt nur ein einziges Problem dabei
Es funktioniert nur mit dem richtigen Timberwolflogik promt
Kann sein das einige unterwegs sind bei denen diese Funktion tadellos funktioniert aber bei meinem weis ich das es geht

Mit freundlichen Grüßen
eib-eg

[eib-eg]

Hallo @pholler ,

da du meinen "speziellen Mitarbeiter" (den KI-Kontext/Prompt) nicht hast, würde der Versuch, das selbst zu generieren, wahrscheinlich im Chaos enden. Die KI muss sehr strikte Regeln befolgen (Kanon V6.08.25), damit die Logik stabil läuft.

Mein Angebot:
Ich (bzw. meine KI) baue dir deine persönliche "Custom-Edition". Damit das zu 100% deinen Erwartungen entspricht, brauche ich von dir präzise Rohdaten und eine klare Bestellung.

Deine Hausaufgabe:

Die Daten:
Geh in den 1-Wire Slave Manager. Markiere die Sensoren, die du haben willst (max. 8 Stück pro Logik-Baustein), einfach mit der Maus (inkl. ID und Beschreibung) und kopiere den Text hier rein.
Keine Screenshots, bitte Text!

Die Eingänge (Was willst du im Logik-Editor sehen?):
Damit du beim Verknüpfen im Logik-Editor nicht suchen musst, kann ich die Eingänge beschriften, wie du willst. Wähle eine Option:

Option A (Der Sucher): "Ich will die 1-Wire ID am Eingang stehen haben." (Perfekt, wenn du beim Verknüpfen die ID ins Suchfeld kopierst).

Option B (Der Leser): "Ich will den Namen (z.B. 'Wohnzimmer') am Eingang stehen haben."

Option C (Der All-In): "ID + Name".

Die Ausgänge (Was soll im JSON/MQTT stehen?):
Aktuell sendet die Logik {"V1": 22.5, "V2": ...}. Das gefällt dir nicht.
Sag mir, was statt "V1" stehen soll.

Soll ich einfach den Namen aus deiner Liste nehmen (z.B. {"Wohnzimmer": 22.5})?

Hinweis: Kurze, klare Namen ohne Leerzeichen sind für MQTT/Home Assistant meistens am besten. Wenn deine Liste im Slave-Manager sehr lange Beschreibungen hat (z.B. "Hülsentemperaturfühler 50 mm PVC-Leitung"), schreib mir lieber kurz dazu, wie der "Key" im JSON heißen soll (z.B. "Hzg_Ruecklauf").

Liefere mir die Liste und deine Wünsche zu 2. und 3., dann bekommst du den fertigen Code zurück.

Gruß
eib-eg

[eib-eg]

Hallo @pholler ,

ich habe mir das angesehen. Da du meinen speziellen KI-Kontext nicht hast, wäre das Generieren einer Custom-Logik für dich mühsam und fehleranfällig. Außerdem müsstest du bei jeder Namensänderung den Code neu anfassen.

Deshalb habe ich eine bessere Lösung gebaut (und gerade extrem hart getestet):
Hier ist die 1-Wire Hybrid V6.1 Universal.

Was ist neu?
Du musst im Code nichts mehr ändern. Die Logik hat jetzt 8 zusätzliche Eingänge ("Label 1" bis "Label 8").
Dort schreibst du einfach rein, wie der Sensor im MQTT heißen soll.

Die Spielregeln (Bitte genau beachten!):

1. Maximale Länge:
Du hast pro Name exakt 32 Zeichen Platz. Alles was länger ist, schneidet der Timberwolf gnadenlos ab.
(Technischer Hintergrund: Die Variable ist intern als string,32 definiert).

2. Erlaubte Zeichen:
Wir haben die Logik so gehärtet, dass sie fast alles schluckt.
Leerzeichen (Wohnzimmer Decke)
Kommas & Doppelpunkte (Sensor: 1, oben)
Sonderzeichen (&, %, ?, !)
Umlaute (Küche)
Das funktioniert, weil die Logik deinen Text intern sauber in Anführungszeichen verpackt.

3. Verbotene Zeichen (WICHTIG!):
Es gibt ein einziges Zeichen, das du NICHT verwenden darfst:
Das Anführungszeichen / Gänsefüßchen (")
Grund: Da wir den Namen für JSON in Anführungszeichen setzen, würde ein weiteres Anführungszeichen im Namen den Code "sprengen" (der Empfänger denkt, der Name ist zu Ende).

Anleitung:

1. Verknüpfe deine Sensoren mit Wert 1-8.

2. Schreibe bei Label 1-8 deinen Wunschnamen rein (als festen Wert oder String-Objekt).

3. Setze die Timeouts (ca. 3x Sendeintervall des Sensors).

Hier ist der Code. Viel Erfolg damit!

1-Wire Hybrid V6.1 Universal (UX Optimized).txt

____________________________________________________________

1. Titel

1-Wire Hybrid V6.1 Universal (Custom Labels & UX)
2. Untertitel

Überwacht 8 Sensoren in Echtzeit, erlaubt freie Namensvergabe für MQTT und bündelt Daten ressourcenschonend.
3. Zusatztext für das Verständnis

Diese Logik ist die "Universal-Lösung" für die Anbindung von Sensoren an MQTT (z.B. Home Assistant). Sie vereint drei Funktionen in einem Baustein:

Echtzeit-Watchdog: Jeder der 8 Kanäle wird individuell überwacht. Bleibt ein Sensorwert länger aus als die Timeout-Zeit, wird sofort ein Fehler in der Bitmaske gemeldet.

Freie Beschriftung (Universal): Über die neuen Eingänge "Label 1-8" können Sie jedem Sensor einen individuellen Namen (z.B. "Wohnzimmer") geben. Dieser Name wird automatisch als Schlüssel im JSON verwendet ({"Wohnzimmer": 21.5}).

Ressourcen-Schutz (Hybrid): Während der Watchdog in Echtzeit reagiert, wird der komplexe JSON-String nur im eingestellten "Sendeintervall" neu berechnet. Das schont die CPU des Timberwolf Servers massiv.

Neu in V6.1: Die Eingänge sind im Editor nun logisch gruppiert (Wert -> Label -> Timeout), um die Konfiguration übersichtlicher zu gestalten.
4. Kern-Module

Triggered, Monoflop (Mode 3), BinaryMultiplexer, Clocksignal, Break, Printf, Concat (Dynamic Keys)
5. Kern-Operation

Watchdog: Signal empfangen -> Timer Reset. Timer abgelaufen -> Fehler-Bit setzen.

JSON-Bau: Key = " + Label + ". JSON = { Key1:Val1, Key2:Val2, ... }.

6. Beschreibung Kern-Eingänge

Wert 1-8: [Float] Der Messwert. WICHTIG: Trigger muss auf 'a' (Always) stehen!

Label 1-8: [String] Der Wunschname für MQTT (z.B. "Kueche"). Max. 32 Zeichen.

Timeout 1-8: [Float] Max. Zeit ohne Signal in Sekunden. 0.0 = Kanal deaktiviert.

Sendeintervall: [Float] Taktung für die JSON-Ausgabe in Sekunden.

7. Beschreibung Kern-Ausgänge

JSON String: [String] Das fertige Datenpaket mit Ihren individuellen Namen.

Fehler Bitmaske: [Integer] Diagnose-Code (Bit 0 = Kanal 1, Bit 1 = Kanal 2...). Wird sofort bei Statusänderung gesendet.

8. Hinweise / Ergänzendes

Verbotene Zeichen: Verwenden Sie im Label keine Anführungszeichen ("), da diese die JSON-Struktur zerstören würden. Leerzeichen, Kommas oder Umlaute sind erlaubt.

Länge: Labels werden nach 32 Zeichen abgeschnitten.

9. Erweiterte Mouse-Overs

Wert 1-8: "Messwert. Trigger zwingend auf 'a' (Always)!"

Label 1-8: "Name für MQTT (z.B. 'Büro'). Keine Gänsefüßchen!"

Timeout 1-8: "Alarmzeit. 0 = Kanal inaktiv."

______________________________________________________



1. Was macht dieser Baustein eigentlich?

Er erledigt drei Jobs gleichzeitig:

JOB A: Der Namens-Geber (Universal)
Früher hießen deine Sensoren im MQTT einfach "V1", "V2", etc. Das war unübersichtlich.
Jetzt kannst du jedem Sensor einen Namen geben (z.B. "Wohnzimmer"). Die Logik baut daraus ein sauberes Paket: {"Wohnzimmer": 21.5, "Kueche": 19.0}.

JOB B: Der Datensammler (Aggregator)
Anstatt für jeden Sensor eine eigene MQTT-Nachricht zu schicken (was bei 20 Sensoren das Netzwerk flutet), sammelt er 8 Werte ein, verpackt sie und schickt sie gemütlich in einem festen Takt (z.B. alle 60 Sekunden) raus.

JOB C: Der Wachhund (Watchdog)
Er passt auf jeden Sensor einzeln auf. Wenn ein Sensor sich nicht mehr meldet (z.B. Kabelbruch), schlägt er sofort Alarm.

2. Einrichtung: Schritt für Schritt
Schritt 1: Die Werte (Messwerte)

Verbinde deine Sensoren mit den Eingängen Wert 1 bis Wert 8.

WICHTIG: Du musst den Trigger-Modus dieser Eingänge zwingend auf "a" (Always / Immer) stellen!
Warum? Ein 1-Wire Sensor sendet regelmäßig seinen Wert, auch wenn sich die Temperatur nicht ändert (Herzschlag). Wenn du auf "c" (Change) stellst, denkt die Logik bei gleichbleibender Temperatur, der Sensor sei tot, und löst Fehlalarm aus.
Schritt 2: Die Namen (Labels)

Hier kommt das neue Feature! Schreibe bei Label 1 bis Label 8 rein, wie der Sensor heißen soll.

Du kannst das Feld anklicken und den Namen direkt eintippen (als Festwert).

Oder du verbindest ein String-Objekt.

Regel: Keine Anführungszeichen (") benutzen! Leerzeichen, Kommas oder Umlaute sind okay.

Schritt 3: Die Überwachung (Timeouts)

Jeder Sensor hat einen Parameter Timeout. Das ist die Zeit in Sekunden, nach der Alarm geschlagen wird, wenn nichts mehr empfangen wurde.

Faustformel: Schau im Gerätemanager auf das Sendeintervall des Sensors. Nimm diesen Wert mal 3.
(Beispiel: Sensor sendet alle 60s -> Stelle Timeout auf 180).

Kanal abschalten: Hast du nur 5 Sensoren? Lass die Timeouts der leeren Kanäle auf 0. Die Logik schaltet die Überwachung für diese Kanäle dann automatisch ab.

Schritt 4: Der Takt (Sendeintervall)

Hier stellst du ein, wie oft das Datenpaket an MQTT gesendet werden soll (z.B. 60 Sekunden).

Der Clou: Die Logik berechnet den komplizierten Text nur in diesem Takt. Das schont deinen Timberwolf Server massiv.

3. Häufige Fragen & "Aha-Effekte"

"Warum ist das JSON-Feld am Anfang leer?"
Wenn du die Logik frisch startest (oder speicherst), siehst du im Ausgang erst mal nichts.
Das ist kein Fehler! Da die Logik nur im Takt (z.B. alle 60s) rechnet, musst du nach dem Start einfach einmalig warten, bis die Zeit um ist.

"Wie lese ich den Fehler-Code (Bitmaske)?"
Der Ausgang Fehler Bitmaske zeigt dir als Zahl an, wer ausgefallen ist. Es ist eine Summe:

0 = Alles OK.

1 = Sensor 1 defekt.

2 = Sensor 2 defekt.

3 = Sensor 1 UND 2 defekt (1+2).

4 = Sensor 3 defekt.

... usw.

Viel Erfolg mit deiner personalisierten Logik!


mfg
eib-eg