Wer nutzt denn eigentlich alles Home Assistant?

[mumpf]

Hi,

Für den ekey gibt es doch - wenn ich nicht völlig daneben liege - auch einen KNX Converter

danke für die Rückmeldung. Ja, den KNX Converter kenne ich, der ist mir aber zu eingeschränkt. Und zu teuer. Und ich müsste auch mein eKey-Multi-Steuergerät austauschen, weil die nicht kompatibel sind (oder ein kostenpflichtiges Update machen). Ich hab mein eKey eben schon 5 Jahre, der KNX Converter kam viel später.

Ich hab auch weiter geforscht... es scheint so zu sein, dass HA nicht auf IP-Signale lauschen kann, weder TCP noch UDP. Das hat mich total überrascht, hätte ich nie erwartet. Und falls jetzt das Argument mit HA-API kommt: Für intelligente (programmierbare) Geräte ist das auch prima, aber wenn ein Gerät einfach so per UDP strings versendet, möchte ich eben auch drauf reagieren können. Am besten nativ in HA...

Ich werde jetzt wohl per externem python-script auf die UDP-Telegramme lauschen und die dann per API an HA weiterschicken. Vielleicht werde ich mich nochmal mit Node-Red beschäftigen, da soll man das auch machen können. Mal sehen...

Gruß, Waldemar

[meti]

Ich werde jetzt wohl per externem python-script auf die UDP-Telegramme lauschen und die dann per API an HA weiterschicken.

da könntest du auch gleich eine HA-integration schreiben und über HACS ausliefern. Wär wahrscheinlich sogar weniger Aufwand.

Du kannst auch NodeRed als HA-Plugin laufen lassen um da direkt HA events / services auszulösen.

[mumpf]

Hi,

da könntest du auch gleich eine HA-integration schreiben und über HACS ausliefern

da sind 2 Worte dabei (könntest, ausliefern), die so nicht stimmen. Ich hab keine Ahnung, wie man eine HA-Integration schreibt und schon gar nicht, wie man über HACS ausliefert. Und ich kann nicht wirklich Python. Ich meine, ich bekomme die Syntax hin und das mit den Datentypen etc. ist auch klar. Aber der OO-Teil und die ganzen asyc-Prozessierung ist nicht so klar. Vielleicht in 1-2 Jahren, wenn ich begriffen hab, wie das alles in HA läuft.

Erstmal die Notlösung, später dann die Verbesserung.

Gruß, Waldemar

[mumpf]

Hi,

Du kannst auch NodeRed als HA-Plugin laufen lassen um da direkt HA events / services auszulösen.

ich hab da jetzt auch mal ausprobiert und es erstmal per NodeRed gelöst. War einfacher als befürchtet . Danke für den Tipp, ich wusste zwar, dass es geht, aber ich hatte mich nicht getraut, noch eine weitere unbekannte Technologie parallel einzuführen...

Gruß, Waldemar

[mumpf]

Hi,

kaum versucht man was konkretes, stolpert man über Probleme... und die zeigen mir, dass ich es noch immer nicht verstanden habe. Konkret geht es um

state_chage trigger - in HA wird ein Trigger gesendet, sobald ein entity geändert wurde, also einen neuen Wert zugewiesen bekommen hat

versus

state_update trigger - in HA wird ein Trigger gesendet, sobald ein entity einen Wert (auch den gleichen) zugewiesen bekommen hat

Ich hab viel gelesen - und wenn ich nichts übersehen habe - gibt es in HA keine state_update trigger? Ich schließe das vor allem aus der Anmerkung in der State-Doku

Note that writing the exact same state including attributes will not result in this field being updated.

Und alle Experimente, die ich mit automations gemacht habe, sprechen auch dafür, dass diese nur aufgerufen werden, wenn sich Werte geändert haben, aber nicht, wenn erneut der gleiche Wert geschrieben wird.

Jetzt meine Fragen, zu denen ich trotz viel lesen im HA-Forum keine befriedigenden Antworten gefunden habe:

• In den meisten Fällen will man ja nur bei Änderungen etwas auslösen. Aber wie erreicht man es, dass auch bei gleichem Wert getriggert wird?
• In der KNX-Integration kann ich so was ja durch "ignore_state" erreichen, aber wie mach ich das mit reinen HA-Entities?
• Falls das nicht "einfach" in HA zu realisieren gibt, gibt es ein Pattern, wie man das macht? Mir ist nur "hilfs-entity" eingefallen mit einer automation, die selbst ein "update-trigger" verschickt und den Wert sofort wieder löscht (und auf die Löschung natürlich nicht reagiert). Erscheint mir aber aufwändig, man braucht dann immer einen eindeutigen "gelöscht"-Wert, was bei boolean schwierig ist etc.

Mir ist klar, dass man update-change nicht so oft braucht wie state-change und dass man für spezielle Fälle auch immer Lösungen finden kann, aber ich würde gerne eine Art Pattern haben, dass ich an mehreren Stellen ohne groß nachzudenken verwenden kann. Wenn es da was gibt und jemand was weiß, würde ich mich freuen, einen entsprechenden Tipp zu bekommen.

Gruß, Waldemar

[meti]

Ja das ist wirklich etwas eigenartig. Besonders wenn man sich https://github.com/home-assistant/co...entity.py#L217 ansieht. Ich war auch immer der Meinung dass `ignore_internal_state` immer ein state_changed event auslöst. Macht es aber garnicht 🙃 Ich wollte dazu mal ein issue öffnen, bin aber noch nicht dazu gekommen.
Von einem state_update event hab ich noch nix gelesen...

Es kommt etwas drauf an was du brauchst. Wenn dein binary_sensor immer nur 1en schickt kannst du ihn per automation auf 0 zurücksetzen. Dann hast du für jede 1 ein sauberes state_changed event. Wenn du beides brauchst hilft dir das auch nix.
Dann könntest du einen `context_timeout` konfigurieren. Der ist eigentlich dazu gedacht doppel-drücker auf Schaltern zu detektieren. Aber als ergebnis bekommst du ein "counter" state attribute das sich jedes mal ändert. Allerdings auch wenn der context_timeout ausläuft - dann auf 0 zurück. Du hast also mehrere events pro telegram - eins mit counter: x und eins mit counter: 0 - das kann man dan in ner automation matchen.

Andere Möglichkeit ist ein "knx_event". Dazu musst du unter `knx: ` `fire_event: True` und `fire_event_filter` konfigurieren. Das macht ein event pro eingehendem Telegram. Allerdings bekommst du hier nur raw payloads - was bei DPT1 egal ist, bei DPT9 nervig.

Brauchst du das für andere DPTs als 1 kannst du einen `sensor` mit `always_callback: True` machen. Das sollte das gleiche sein wie ein binary_sensor mit `ignore_internal_state: True` nur eben für nicht-binäre sensoren - vielleicht hilfts ja, probiers aus.

[mumpf]

Hi,

vielen Dank für die ausführliche Erklärung. Ich meinte zwar gar nicht die knx-Seite, sondern das Verhalten von HA im allgemein, aber jetzt ist auch die knx-Seite beleuchtet. Vor allem, dass ignore_internal_state nicht immer ein state_changed auslöst, ist interessant. Ich dachte, ich hab das ausprobiert und es klappt, aber vielleicht hab ich es missinterpretiert...

Dein Tipp mit knx_event ist super zum Auswerten von knx-Szenen (also der Weg, dass eine knx-Szene was in HA steuert). Danke...

Das Problem, das ich hatte, war beim Anbinden vom Fingerprint. Der Sendet eben immer das gleiche Telegramm, wenn die gleiche Person den Finger durchzieht. Und dieses Telegramm löst nur beim ersten Mal eine automation aus. Aber da hab ich ja schon eine Lösung gefunden.

Mich hat es nur überrascht, dass es kein einfaches Konzept in HA gibt für Updates. Ich hätte so was wie ein Attribut "force_update" an einer Entität erwartet. Aber was solls, man bekommt es ja anders hin...

Gruß, Waldemar

[meti]

Das Attribut "force_update" gibts ja eh, und ich hab's dir oben (#216) verlinkt ^^

Wie hast du's jetzt gemacht?

[mumpf]

Hi meti,

wie/an wen sollte ich so was melden:

2020-11-21 11:24:08 WARNING (MainThread) [xknx.log] CEMI not supported: <UnsupportedCEMIMessage description="CEMI too small. Length: 10; CEMI: b')\x00\xb0P\x11\x00\x00\x00\x00\xc2'" />
2020-11-21 11:24:08 ERROR (MainThread) [xknx.log] <CouldNotParseKNXIP description="KNXIP data has wrong length" />
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/xknx/io/udp_client.py", line 86, in data_received_callback
    knxipframe.from_knx(raw)
  File "/usr/local/lib/python3.8/site-packages/xknx/knxip/knxip.py", line 80, in from_knx
    raise CouldNotParseKNXIP("KNXIP data has wrong length")
xknx.exceptions.exception.CouldNotParseKNXIP: <CouldNotParseKNXIP description="KNXIP data has wrong length" />
2020-11-21 11:24:09 WARNING (MainThread) [xknx.log] CEMI not supported: <UnsupportedCEMIMessage description="CEMI too small. Length: 10; CEMI: b')\x00\xb0P\x11\x00\x00\x00\x00\xc2'" />
2020-11-21 11:24:09 ERROR (MainThread) [xknx.log] <CouldNotParseKNXIP description="KNXIP data has wrong length" />
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/xknx/io/udp_client.py", line 86, in data_received_callback
    knxipframe.from_knx(raw)
  File "/usr/local/lib/python3.8/site-packages/xknx/knxip/knxip.py", line 80, in from_knx
    raise CouldNotParseKNXIP("KNXIP data has wrong length")
xknx.exceptions.exception.CouldNotParseKNXIP: <CouldNotParseKNXIP description="KNXIP data has wrong length" />

Das hat vorhin um 11:24 einfach so begonnen und HA kommt da nicht mehr raus. Es ist jetzt 11:47 und es geht immer noch so weiter. Es kann noch von HA nach KNX gesendet werden. Aber HA empfängt nichts mehr von KNX. Der Bus an sich funktioniert normal, die Schnittstelle auch, ich kann über die ETS über die selbe Schittstelle an den Bus dran. Achja: Ich habe nichts "ausprobiert" oder so, war mitten im Betrieb.

Ein schlechtes/kaputtes Telegramm kann ja mal sein, aber ich hätte erwartet, dass xknx da wieder raus kommt und nicht endlos in so einem Zustand bleibt.

Ich werde jetzt erstmal das Ganze neu starten. Würde das aber gerne offiziell melden.

Gruß, Waldemar

[crazyfx]

Hier kannst du ein Issue erstellen:
https://github.com/XKNX/xknx/issues

[meti]

Crazyfx hat recht, Github ist der perfekte Ort dafür. Dort könntest du auch danach suchen und würdest sehen, dass das dieser Fehler in der aktuellen Version bereits behoben ist. (das "CEMI too small. Length: 10" kommt von nem ETS Linien-Scan oder evtl. von OpenHAB).

Normal würd ich sagen "mach mal n Update" aber das ist aktuell eher mit Vorsicht zu genießen - in HA 0.118 ist auch noch nicht alles golden.

[mumpf]

Vielen Dank euch beiden. Ich habe mir jetzt das Problem und auch die anderen offenen Probleme gelesen. Ich werde wohl derzeit nicht die 0.118 installieren .

Wie hast du's jetzt gemacht?

Ich habe ein input_text definiert, da schreibe ich das Telegramm vom eKey-Fingerprint rein. Darauf ist eine automation registriert, die bei einem state change losläuft. Die letzte action dieser automation löscht dieses input_text-Feld. Somit wird selbst bei einem wiederholten identischen Telegramm die automation neu gestartet.

Gruß, Waldemar

[mumpf]

Hi,

ich bin es mal wieder . Ich hab mal ne Frage, wie das mit dem "Finetuning" der HA <-> KNX Kommunikation gedacht ist. Eigentlich hat doch hier 2 unterschiedliche Systeme mit ihren jeweiligen Eigenheiten. Ich würde erwarten, dass man den "Übergang" zwischen den Systemen steuern kann. Nur habe ich nichts gefunden und stelle mir die Frage, wie das gedacht ist. Worum geht es im Einzelnen:

• Ich möchte eigentlich pro GA bestimmen, ob diese beim Start/Restart von HA neu gelesen wird. Sensoren haben da "sync_state: init", aber was ist mit den anderen Gerätetypen wie cover, light, climate etc.? Bei light möchte ich z.B. bestimmen, ob "address" oder "state_address" oder beide gelesen werden.
• Ebenso das Senden der Werte zum KNX hin: Man muss doch an der GA sagen, ob diese nur bei change sendet oder auch bei einem update (also den gleichen Wert erneut setzen). Bisher gibt es nur Settings, die bestimmen, wie bei KNX-Telegrammeingang die HA-Infrastruktur informiert wird, und das wiederum nur bei Sensoren (ignore_internal_state, always_callback). Wie spezifiziere ich das Sendeverhalten in Richtung KNX?
• HA ist eher zustandsbasiert (auch wenn es mit Triggern auch eine eventbasierte Komponente gibt), das merkt man vor allem an templates und automations. Normalerweise bewirken nur Zustandsänderungen was (man muss sich anstrengen, damit ein mehrfaches Senden des selben Wertes etwas bewirkt). KNX ist rein Telegrammbasiert (also Eventbasiert), hier ist es üblich, dass z.B. das 3-fache Senden einer 1 auf ein KO einen Lüfter von Stufe 0 auf Stufe 3 schaltet. Ich erkenne den Versuch, in der KNX-Integration darauf einzugehen (reset_after bei switch und binary_sensor), aber zumindest beim Switch würde ich dann erwarten, dass man einen Filter setzen kann, der verhindert, dass die 0 nach "reset_after" wieder auf den KNX-Bus gesendet wird.
• In KNX ist es üblich, auf mehrere GA zu hören. Ich habe bisher keine Möglichkeit gesehen, dass die KNX-Integration auf mehrere GA hört (state_address).

Man kann zwar für die meisten Probleme Workarounds finden, aber ich hab immer das Gefühl, dass ich nur irgendwas nicht verstanden oder nicht gefunden habe, wenn ich dann statt einem einfachen switch ein switch-template mit einigen Automatisierungen "drumrum" mache, damit es so funktioniert, wie es soll. Und es ist aufwändig.

Gibt es da ein Konzept, wie das funktionieren soll (selbst wenn noch nicht alles implementiert ist)? Oder gibt es noch irgendwo Einstellungen und ich hab sie nur nicht gefunden (so was wie Flags in der ETS, von den ich auch lange dachte, dass die nicht veränderbar sind und nur vom Hersteller gesetzt werden)?

Gruß, Waldemar

[meti]

Bei light möchte ich z.B. bestimmen, ob "address" oder "state_address" oder beide gelesen werden.

https://knx-user-forum.de/forum/öffe...23#post1566223 Das gilt nach wie vor. Wieso sollte man beide lesen?

reset_after bei switch

Das gibt es doch nicht. https://github.com/home-assistant/co...ion_r522007397
Aber es gibt Events.

Wie spezifiziere ich das Sendeverhalten in Richtung KNX?

Das Sendeverhalten wovon? https://knx-user-forum.de/forum/öffe...87#post1555387

In KNX ist es üblich, auf mehrere GA zu hören

Mit Status Adressen und Szenen kommt man da meistens gut ans Ziel.

HA ist halt keine KNX-Visualisierung sondern eher eine Universelle. Die meisten Dinge lassen sich gut abbilden, und für Spezialfälle gibt es auch immer Lösungen (Templates, Automations). Aber ohne konkretes Beispiel kann ich dir da auch nicht weiterhelfen.