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

[StefanW]

Hi Georg,

Dank dir @pholler wurde die Logik so hochkatapultiert das sich elabnet dazu entschieden hat diese in die fertig integrierten Logiken zu implementieren

Yeah, dies hat zwei Gründe:

1. Die Logik ist gut und sie ist allgemein brauchbar um viel Messwerte über zwei Server zu koppeln.

2. Du hast von der KI auch gleich eine brauchbare Beschreibung / Doku erstellen lassen gemäß der Akzeptanz-Regeln, damit war uns das vom Aufwand her machbar.

lg

Stefan

[pholler]

Hallo Georg, hallo KI!
Vielen Dank für die super Logik! Ich bin etwas Still bei dem Thema aber immer noch am Testen.

Was mir aufgefallen ist. Boolean-Inputs führen dazu dass die Logik nur noch "" ausgibt. Kann man da was dagegen tun? Haben KI oder HI ne Idee dazu?

Mein Anwendungsfall
Ich habe in jedem Zimmer Temperatur- und Feuchtesensoren, zusätzlich Sensoren im Estrich und in der Decke. Weiters noch typischerweise zwei Reedkontakte für die Fenster. Alles auf 1W-Basis. Ich würde gerne all diese acht Sensoren pro Zimmer in einem MQTT-Topic übertragen. Wäre einfach übersichtlich. Die Reedkontakte würde ich als zusätzlichen Trigger für die Logik anwenden damit ein Fensteröffnen auch sofort übertragen wird.

Ich weiß noch nicht so recht wie ich mit der Fehlerbitmaske umgehen soll. Die sollte eigentlich auch an MQTT übertragen werden, oder? Könnte man die nicht auch gleich in den JSON integrieren?

LG
Peter

[eib-eg]

Schreib mal wie du das Ergebnis gesendet haben willst
Schreib in welcher Reihenfolge du es haben willst
Schreib wie oft gesendet werden soll
Aufpassen, wie oft wird der fensterkontakt abgefragt und in eine zeitserie gespeichert, also wie viele sec der abfrage sind eingestellt
Wenn Fenster offen gleich senden oder verzögert
Sollen änderungswerte von temp und oder feuchte auch ein sendeanstoß geben sowie wie oft soll gesendet werden

Wir kommen schön langsam an dein Ziel ran
Je genauer du Angaben machst um so schneller bist am Ziel

Ich weis
Erst wenn man weis „was alles möglich ist“ kommen erst die Ideen und gleichzeitig die Fehler die nebenbei auftreten durch Tests

Also her mit den Infos um schneller an dein Ziel zu kommen
Aber Mache dir über meine Fragen Gedanken darüber

[pholler]

Dann eröffne ich das "Wünsch-dir-was":

• Anstatt eines eigenen Ausgangs mit dem Fehlercode soll ein anstehender Fehler (also das Ausbleiben von Inputdaten) in das Ausgabe-JSON unter dem jeweiligen Labelnamen als NaN, NULL oder so etwas ähnlichem ausgegeben werden. Welcher Ausgabewert für nicht vorhandene Daten bei MQTT-JSON mit Weiterverwendung in Homeassistant am schlauesten ist kann vielleicht die KI beantworten.
• Der Output-JSON soll jedes Mal erstellt werden wenn die Logik getriggert wird
  • Entweder wenn das frei wählbare Intervall erreicht wird (also wie gehabt)
  • Oder wenn sich ein Wert ändert.
  Konkret soll das Flag des Inputs (A, C, U) berücksichtigt werden. Dann kann ich nämlich einen binären Eingang für meine Fensterkontakte einfach auf C setzen und die Logik wird bei Änderung getriggert. Temperaturen kann ich auf U setzen und wenn ich zB im Badezimmer der Meinung bin dass Änderungen der relativen Feuchtigkeit dort wichtig sind und sofort geschickt werden müssen dann setze ich diesen einen Eingang auch auf C oder A.
• Inputs sollen auch mit binären Eingängen funktionieren. Evtl. auf 0/1 konvertieren.

[eib-eg]

Werde am Abend mich hinsetzen

[eib-eg]

(Transparenz-Hinweis: Dieser Text wurde mit KI-Unterstützung erstellt, um die technischen Risiken der angeforderten Änderungen präzise zu formulieren.)

Hallo Peter,

ich habe mir deine Wunschliste ("Wünsch-dir-was") genau angesehen.
Technisch ist das alles machbar: Event-gesteuerte Ausgabe statt Taktung, und null im JSON bei Fehler.

Aber bevor ich (bzw. die KI) das baue, muss ich eine deutliche Warnung aussprechen. Du verlangst hier einen massiven Eingriff in die Architektur, der Risiken birgt.

1. Das Performance-Risiko (Die Bremse fehlt)
Die aktuelle V6.1 hat eine bewusste "Bremse" (das Break-Modul). Sie berechnet den aufwendigen JSON-String (Text-Operationen kosten CPU!) nur alle X Sekunden.
Wenn wir das umbauen, wie du willst (Trigger durch Input "C" oder "A"), entfernen wir diese Bremse.

Das Szenario: Wenn du 8 Sensoren hast, die etwas "nervös" sind und jede Sekunde senden, baut der Server 8x pro Sekunde diesen String neu.

Die Gefahr: Das erzeugt unnötige CPU-Last. Wenn das viele User nachbauen, haben wir bald Performance-Probleme im Feld. Du musst dann extrem diszipliniert mit den Triggern umgehen.

2. Die Komplexität (NULL im JSON)
Um null (als echtes JSON-Null ohne Anführungszeichen) oder den Wert zu senden, muss die Logik intern für jeden Kanal eine Weiche (Multiplexer) haben. Das bläht den Code auf und macht ihn schwerer lesbar.

Mein Vorschlag:
Bevor wir das "Monster" auf 8 Kanälen bauen:
Bist du dir sicher, dass du das Risiko eingehen willst?

Wenn ja, würde ich dir erst einmal einen 2-Kanal-Prototypen bauen.
Damit kannst du testen:

1. Versteht Home Assistant das null im JSON korrekt?

2. Verhält sich die Buslast/CPU so, wie du es erwartest?

Gib kurz Bescheid, ob wir das so machen sollen.

Gruß
eib-eg

[pholler]

Hallo Georg,
vielleicht bin ich bei dem Punkt Performance etwas naiv, aber mir macht dass überhaupt keine Sorgen. Temperatursensoren werden bei mir typischerweise alle 5 Minuten vom 1W abgefragt und nur Änderungen werden dann ans Objekt übergeben. Z.B.:

Screenshot 2025-12-10 at 09.21.50.png

Da kommen nicht viele Logiktrigger zusammen. Bestimmt weniger als 1 Trigger je Minute. V.a. wenn man "langsame" Eingänge auf U setzt kann man die Logikstarts nochmal runter setzen. Ja, ich möchte das Risiko eingehen.

Wäre super wenn du mir einen Code für zwei Inputs zum Testen erstellen lassen könntest.

LG
P

[pholler]

Werte Foristen,
ich habe einige Tage lang unterschiedlichste JSON-Generatoren für die Logikengine getestet und mich auch daran erfreut, neue Ideen rund um LLM einzupflegen. Vielen vielen Dank an eib-eg für die intensive Unterstützung dabei! Das funktioniert überraschend gut, hat aber immer wieder auch Probleme.

Am Ende des Tages konnte ich mich mit dem Konzept nicht ganz anfreunden. Es kamen entweder zu viele MQTT-Pakete, falsche NULL oder zu wenige. Das war mir nicht robust genug.

Ich habe daher eine zweite Strategie ausprobiert, inspiriert von eig-eg's LLM-Ansatz für die Logikengine: Ich habe mir von der LLM ein MQTT-JSON-Template bauen lassen und mir so die viele Klickerei im TWS, die ja der Ausgangspunkt dieses Topics war, gespart. Die 1W-Geräte müssen dann nur noch zugewiesen werden – also derselbe Klickaufwand wie bei der JSON-Variante über ein Custom-Logik-Modul.

Der Vorteil dabei ist aber, dass keine Werte geschickt werden, die gar nicht aktualisiert wurden, sondern tatsächlich nur ein MQTT-Telegramm je Wertaktualisierung gesendet wird. Die Überwachung, ob tatsächlich Werte gesendet werden, kann ich so bequem und robust in HA machen. Das geht in HA mit

Code: Alles auswählen

expire_after: 3700

und würde auch einen Ausfall des TWS erkennen.

Ich stelle die Methode kurz vor

• Entweder im TWS eine MQTT-Vorlage für einen Raum oder ein Themengebiet erstellen oder man lässt auch dass schon der LLM machen. Hat bei mir prima funktioniert.
  Screenshot 2025-12-14 at 08.37.08.png
• Dann klickt man auf Export
  export.png
  Es wird ein JSON-File erstellt. zB:
  TWS MQTT Device Export - Zi1.json
• JSON-File in die LLM jagen, Änderungswünsche bekanntgeben, File abspeichern und dann wieder in der MQTT-Oberfläche des TWS importieren
  Screenshot 2025-12-14 at 08.43.36.png
• Da kommt dann eine Warnung, dass die Datei verändert wurde (ein Hash passt nicht), ignorieren und schon hat man einen ganzen Raum im TWS-MQTT-Fenster zum Publishen bereit.