ElabNET Technik Forum

Hi Georg,

eib-eg hat geschrieben: ↑Sa Dez 06, 2025 2:09 pmDank 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

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

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

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.

Werde am Abend mich hinsetzen

(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

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