ElabNET Technik Forum

Werte Foristen,
ich möchte alle meine 1wire-Sensoren zusätzlich in Homeassistant nutzen.
Wie bekomme ich diese am besten "rüber"? MQTT?

Mit MQTT habe ich es probiert. Man kann am TWS pro App Level Topic immer nur einen Wert publishen. Das wird schnell unübersichtlich und ist ein ziemlicher Klickaufwand. Alternativ kann man mehrere Werte in einen JSON publishen. Das ist etwas weniger Klickaufwand aber dann in der Aufbereitung in Homeassistant kompliziert.
Am TWS sieht das für einen von zehn Räumen mit JSON so aus: Gibt's da bessere Ansätze?

LG
Peter

Nicht wirklich. Im TWS gibt es keine Automatismen zur Objektgenerierung auf den Schnittstellensystemen. Das erhöht die Flexibilität, da man an der jeweiligen Schnittstelle so maximale Freiheiten genießt aber ja man muss sich da dann jeden Datenpunkt selbst bauen.

Du kannst Dir jetzt jeden Datenpunkt einzeln versenden oder ein einziges Topic aufbauen und ein Sammel-JSON verschicken. Das Sammel-JSON musst Du dann aber an anderer Stelle generieren, das wäre dann eine Logik die ein JSON aus X Eingangselementen zusammen baut. Und an die Eingänge der Logik kommen die 1-wire Objekte dran verbunden. Auf der HA Seite musst Du dann wieder das JSON zerlegen.

ggf ist das aber mit dem Sammel-JSON gar kein schlechter Gedanke, denn dann kannst in der Logik auch weitere Metadaten mit ans HA schicken, in Dem Du auch noch als eigene Werte im JSON Metadaten zum Sensor mit schickst, dann kann HA da ggf auch wieder leichter eine Entität draus bauen.


Wenn Du ein klares Schema für die Objekte hast, kann man aber auch mit echten KI Agent-Browsern wie COMET sich die Klickarbeit abnehmen lassen.
Du sagst Ihm dann schaue mal mit ich lege jetzt einen neuen MQTT Datenpunkt an, wieder hole das bitte für die folgenden 5 weiteren 1-wire Datenpunkte. Ich hatte mir da letztlich für einen Weg in die andere Richtung 20 MQTT Eingänge aus einem größeren JSON generieren lassen mit direkter Verlinkung an eine passende TS.

JSON Aggregator für MQTT + Praxisbeispiel: Wie KI das Chaos sortiert

Hallo Peter (@pholler ), hallo Stefan (@StefanW),

das Thema "Massen-Daten" und "Klickaufwand" ist ein perfektes Beispiel dafür, wo wir mit intelligenten Tools hinwollen.
TEIL 1: Die Lösung für Peter (JSON Aggregator)

Görans Idee mit dem "Sammel-JSON" ist technisch der eleganteste Weg. Ich habe dir mit meinem KI-Kanon eine Logik generieren lassen, die genau das tut.

Der Baustein: "JSON Aggregator 8-fach (V1.1)"
Diese Logik nimmt 8 Float-Werte und baut daraus vollautomatisch einen JSON-String: {"V1":20.5, "V2":21.0, ...}.

Die Features:

1. Sammeln: Du verknüpfst deine Sensoren einfach im DOS.

2. Drosseln (Wichtig!): Damit MQTT nicht geflutet wird, wenn sich ein Sensor ändert, habe ich ein Sendeintervall eingebaut. Der String geht z.B. nur alle 60 Sekunden raus.

3. Test & Hinweis: Ich habe kein Home Assistant im Einsatz. Ich habe die Logik nur soweit getestet, dass sie sich im TWS fehlerfrei speichern lässt und das JSON sauber in Grafana ankommt (siehe Screenshot). Ob HA das Format exakt so frisst, müsstest du bitte kurz prüfen.

(Datei JSON_Aggregator_8fach_V1.1.json im Anhang)

TEIL 2: Die Frage der Größe (Das "Monster")

Ich habe intern mit meiner KI diskutiert: "Können wir das auch für alle 80 Sensoren in einem Baustein machen?"
Die Antwort ist: Technisch ja. Der Timberwolf packt das locker.

Aber: Wir raten davon ab.
Eine Logik mit 80 Eingängen im Editor zu verknüpfen, macht keinen Spaß – da scrollst du dich tot. Zudem wird der JSON-String extrem lang.

Mein Vorschlag zur Struktur:
Teile es in sinnvolle Häppchen auf (z.B. pro Etage oder pro Raum-Gruppe).

Anbei findest du die 8-fach Version zum Testen.

Da ich den Code per KI generiere (fehlerfrei, ohne Tippfehler bei 80 Zeilen Code), ist das Skalieren für mich kein Aufwand.

Angebot:
Teste mal die 8er Version. Wenn das Prinzip bei dir in Home Assistant funktioniert, sag einfach Bescheid, welche Größe du brauchst (z.B. 16-fach oder 24-fach).
Ich lasse dir den passenden Baustein dann kurz raus. Das ist eine Sache von Minuten.
TEIL 3: Die Vision (Praxisbeispiel Boiler)

Um zu zeigen, was möglich ist, wenn man diesen Ansatz weiterdenkt, habe ich das Ganze an meiner eigenen Anlage (32kWh Insel, komplexe Heizung) durchexerziert.

Die Aufgabe:
Ich habe einen Boiler mit 13 Temperatursensoren für die Schichtladung.
Meine Liste im 1-Wire Slave Manager war "historisch gewachsen" (also chaotisch): Namen durcheinander, aber die Montagehöhen (10cm, 30cm, 130cm) standen dabei.

Der KI-Workflow:
Ich habe der KI diese rohe Liste hingeworfen und gesagt:
"Bau mir einen JSON-Aggregator für diese 13 Sensoren. Aber sortiere die Eingänge physikalisch nach der Höhe (cm) und schreib mir die 1-Wire ID direkt in die Beschreibung."

Das Ergebnis (in 30 Sekunden):
Die KI hat mir eine Logik geliefert, bei der:

Ordnung herrscht: Die Eingänge sind sortiert von Level_010cm (unten) bis Level_130cm (oben).

Komfort herrscht: Im Mouse-Over/Tooltip jedes Eingangs steht bereits die exakte 1-Wire ID und der Name aus meiner Liste. Ich muss im DOS nicht mehr suchen, sondern nur noch "Verbinden" klicken.

(Siehe Screenshot der Logik im Anhang)
TEIL 4: Der Profi-Tipp (Daten-Hygiene)

Das funktioniert natürlich nur so perfekt unter einer Bedingung: Saubere Beschriftung.

Wenn ihr eure Sensoren im TWS sauber benennt (z.B. "Puffer_Oben", "Puffer_Mitte" oder Tags nutzt), kann die KI diese Struktur erkennen und euch die Arbeit abnehmen.

Schlechter Input: "Sensor 1", "Sensor 2" -> KI kann nur raten.

Guter Input: "VL_Heizung", "RL_Heizung" -> KI baut die Logik logisch auf.

Das ist der Beweis: Mit dem richtigen Werkzeug (Kanon) wird aus "Klick-Orgie" eine strukturierte Ingenieurs-Lösung.

Viel Erfolg beim Testen!

lg
eib-eg

Anhänge:


{"V1":45.0,"V2":44.5,"V3":44.2,"V4":44.0,"V5":43.5,"V6":41.5,"V7":38.8,"V8":36.0}


(Für Peter)



(Als Beweis für Stefan)


Generiert nach ElabNET-Standard

1. Titel (Kurz)
JSON Aggregator 8-fach (Float to JSON)

2. Untertitel
Bündelt 8 Messwerte in einen JSON-String für MQTT mit einstellbarem Sendeintervall.

3. Zusatztext für das Verständnis
Dieser Baustein reduziert den Konfigurationsaufwand bei der Übertragung vieler Messwerte (z.B. an Home Assistant oder Cloud-Dienste). Anstatt für jeden Sensor ein eigenes MQTT-Objekt anzulegen, fasst diese Logik 8 Werte in einem einzigen JSON-String zusammen ({"V1": 20.5, "V2": ...}).
Besonderheit: Um eine Überflutung des MQTT-Brokers bei sich ständig ändernden Einzelwerten zu verhindern, verfügt der Baustein über eine integrierte Drossel (Sendeintervall). Der JSON-String wird nur im eingestellten Takt (z.B. alle 60s) aktualisiert gesendet.

4. Kern-Module
Printf, Concat, Clocksignal, Latch

5. Kern-Operation
Formatierung der Einzelwerte -> Zusammenbau des Strings -> Zyklische Ausgabe (Latch).

6. Beschreibung Kern-Eingänge

Wert 1-8: [Float] Die Eingangswerte (z.B. Temperatur, Feuchte). Trigger: "c" (On Change).

Sendeintervall: [Float] Zeit in Sekunden, wie oft das gesammelte Paket gesendet werden soll (Drossel).

7. Beschreibung Kern-Ausgänge

JSON String: [String] Der fertige Payload für das MQTT-Objekt. Format: {"V1":Wert1, "V2":Wert2, ...}.

8. Hinweise / Ergänzendes
Die Ausgangs-Variable ist auf 1024 Zeichen dimensioniert, was für 8 Float-Werte mehr als ausreichend ist.
Für die Nutzung in Home Assistant muss das JSON dort mittels Value Templates zerlegt werden.

9. Erweiterte Mouse-Overs (Vorschläge für den Editor)

Wert 1-8: "Messwert (Float). Wird automatisch in den JSON-String integriert."

Sendeintervall: "Drossel in Sekunden. Bestimmt, wie oft das MQTT-Paket gesendet wird."

JSON String: "Fertiges JSON-Objekt. Mit einem MQTT-Publish-Objekt verknüpfen."

Hi Georg,

das ist richtig gut!

lg

Stefan

Hallo Georg,

eib-eg hat geschrieben: ↑Fr Nov 28, 2025 11:04 pm Der Baustein: "JSON Aggregator 8-fach (V1.1)"
Diese Logik nimmt 8 Float-Werte und baut daraus vollautomatisch einen JSON-String: {"V1":20.5, "V2":21.0, ...}.

Ich habe den Baustein ausprobiert und zwei Probleme gefunden, vielleicht kannst du die KI noch darauf hinweisen:

1) Die KI hat das Latch mit dem Parameter 0 verwendet, also Wert weitergeben wenn TRUE durch das Clocksignal erzeugt. Das Clocksignal wechselt immer zwischen TRUE und FALSE im Intervall. Solange das Intervall TRUE ist werden alle Werte weitergeben, es wäre besser auf die wechselnde Flanke zu reagieren.
Siehe: https://elabnet.atlassian.net/wiki/spac ... ulbaustein

2) Die Eingänge mit C für Change/Wertänderung gefallen mir nicht, weil der Logik immer den kompletten JSON String ermittelt wenn ein Wert eintrifft. Aus Gesichtspunkten der Ressourcenschonung würde ich empfehlen den String nur zusammenzubauen wenn auch das Sendeintervall eintritt.
Also entweder U Update/Aktualisierung am den Eingängen wählen, oder die Ausführung der Logik mit dem Break-Modul vor der Erstellung des JSONs abbrechen, wenn nichts versendet werden soll.

Viele Grüße,
Matthias

Hallo Matthias @ms20de ,

danke für den kritischen Blick unter die Haube! Das ist genau das Feedback, das wir brauchen, um aus einer "Idee" einen "Standard" zu machen.

Du hast in beiden Punkten absolut recht:

Latch Mode 0: Das war ein Denkfehler. Bei "Pegelsteuerung" bleibt das Tor offen, solange der Takt anliegt -> Burst-Gefahr.

Ressourcen (Trigger): Bei Trigger "a" (Always) ständig Strings zu bauen, die man dann verwirft, ist Verschwendung.

Ich habe die Logik daraufhin komplett überarbeitet und "gehärtet".
Hier ist die Version 5.1.

Die technischen Änderungen (Performance & Stabilität):

1. Architektur-Umbau (Break):
Die Logik ist jetzt zweigeteilt.

Teil A (Watchdog): Läuft immer (für Timer-Reset).

Teil B (JSON-Bau): Ist durch ein Break-Modul abgetrennt. Der rechenintensive Teil (Printf/Concat) wird nur noch exakt 1x pro Sendeintervall ausgeführt. In der Zeit dazwischen verbraucht die Logik fast null CPU für den String-Bau.

2. Latch-Fix:
Ich nutze jetzt eine interne Flankenerkennung. Damit gibt es garantiert nur ein Telegramm pro Intervall.

3. Smart-Alarming:
Der Fehler-Ausgang (Bitmaske) nutzt den nativen "On Change" Trigger. Damit werden Fehler sofort gemeldet, aber dauerhaft anstehende Fehler erzeugen keine Buslast mehr.

@pholler : Damit hast du jetzt eine Version, die auch bei vielen Instanzen den Server nicht in die Knie zwingt und trotzdem jeden Ausfall sofort meldet.






KATALOG-DOKUMENTATION: 1-Wire Hybrid V5.1 (Performance Edition)

Generiert nach ElabNET-Standard

1. Titel (Kurz)
Hybrid: JSON Aggregator & Watchdog 8-fach (Performance Optimized)

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

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

Überwachung (Watchdog): Jeder der 8 Eingänge wird in Echtzeit 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 (V5.1): 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. Das schont die Ressourcen massiv, auch bei vielen Instanzen.

4. Kern-Module
Triggered, Monoflop, BinaryMultiplexer, Clocksignal, Break, Printf, Concat, Latch

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, damit auch unveränderte Werte den Watchdog bedienen ("Heartbeat").

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, ohne Fehlalarme zu erzeugen.
Die Logik benötigt keine externen Timer.

9. Erweiterte Mouse-Overs (Vorschläge für den Editor)

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

Sendeintervall: "Taktung für JSON-Ausgabe (Ressourcen-Schonung)."

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

Fehler Bitmaske: "Diagnose-Code. Aktualisiert sich sofort bei Fehler."

___________________________________________

ANWENDER-GUIDE: So nutzt du den "1-Wire Hybrid Wächter"

Du hast viele 1-Wire Sensoren, 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. Hier ist die Erklärung, wie sie funktioniert und wie du sie einrichtest.
1. Was macht dieser Baustein eigentlich?

Er erledigt zwei Jobs gleichzeitig, die normalerweise getrennte Logiken erfordern würden:

JOB A: 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.

JOB B: 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.

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 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. Die Ausgänge verstehen

JSON String:
Das ist dein Datenpaket. Es sieht so aus: {"V1": 21.5, "V2": 45.0, ...}.
Verbinde das mit einem MQTT-Objekt. In Home Assistant kannst du die Werte dann einfach auseinandernehmen.

Fehler Bitmaske:
Hier siehst du sofort, wer Probleme macht. Der Wert 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. (Binäre Zählweise).

Smart-Feature: Dieser Ausgang sendet sofort, wenn ein Fehler auftritt oder verschwindet. Er sendet aber nicht ständig, wenn der Fehler einfach nur ansteht. Das hält den Bus sauber.

Profi-Tipp zur Fehlersuche (Doktor-Modus)

Wenn du die Logik testest und die Timeout-Zeit änderst (z.B. von 600s auf 10s runtersetzt), wundere dich nicht, wenn der Alarm nicht sofort kommt.
Grund: Ein Timer, der bereits läuft (mit den alten 600s), lässt sich nicht mittendrin stören. Er muss erst ablaufen oder durch ein neues Signal vom Sensor neu gestartet werden.
Lösung: Nach einer Zeit-Änderung einfach kurz warten, bis der Sensor das nächste Mal sendet – dann ist die neue Zeit aktiv.

Viel Erfolg mit der "eierlegenden Wollmilchsau"!

______________
ende ki text


mfg
eib-eg

Vielen Dank für diese Idee! Hört sich genial an!
Ich hab jetzt erst die Zeit gefunden es zu testen. Bin gleich an die V5.1 ran gegangen. Ich schaffe es aber nicht dass da was sinnvolles raus kommt. Bei mir spuckt das Modul immer nur Leerzeichen aus: LG
Peter

Hallo Peter,

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.

Schritt A: Lass die Logik laufen.

Schritt B: Warte, bis dein Timer (30s) einmal abgelaufen ist.

Schritt C: Sobald der "Takt" kommt, rauscht die Logik einmal komplett durch, baut das JSON und das Feld füllt sich.

3. Checkliste zur Sicherheit
Damit es beim nächsten Takt auch sicher klappt, prüfe bitte kurz:

1. Trigger: Haben deine Eingänge (Wert 1 etc.) den Trigger auf "a" (Always)? Das ist wichtig, damit die Logik überhaupt aufwacht, wenn der Sensor sendet.

2. Werte: Liegen an den Eingängen schon Zahlen an? (Im Screenshot sieht man keine blauen Linien/Werte an den Eingängen, evtl. haben die Sensoren noch gar nichts gesendet?).

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

lg
eib-eg

Danke für die Antwort,
ich lasse es mal über Nacht laufen.
Die 30s habe ich aber definitiv abgewartet und trotzdem wird da immer nur " " gesendet.

Wie ist die Einstellung beim sendefilter im Slave id im gerätemanager
Sowie nach dem Verknüpfen auch gespeichert ?
Die Eingänge werden im dok Modus bei Empfang rot hinterlegt
Dieses rot ist im Bild nicht zu sehen

Deswegen wie Stefan immer schreibt kompletter Bildschirm mit einstellen
Denn die Diskette also speichertaste hat dadurch eine andere Farbe
Dies ist auch im Bild nicht zu sehen