Wer nutzt denn eigentlich alles Home Assistant?

[meti]

Ja, beides geht indem man für die Entity in `customize` `assumed_state = True` konfiguriert.

[crazyfx]

Ich habe mein Garagentor an einem KNX Aktor, und kann es mit Auf / Ab bzw. 1 / 0 steuern. Jedoch habe ich keine Zustandsabfrage und somit keine state address.

Im Openhab ist das kein Problem, da ich dort immer beide Pfeile zum für Auf / Ab aktiv habe.

Im HA ist das aber leider ein Problem, da beim Cover ein Pfeil ausgegraut ist.
ha.PNG
Da das Garagentor auch noch über den normalen Drücker verwendet wird, stimmt der Status öfters nicht.

Das hast du meti hier https://github.com/XKNX/xknx/issues/314 schonmal gefixt. Jedoch funktioniert das nur, solange die Garage immer über KNX verfahren wird.

Gibt es eine Möglichkeit im HA entweder:
- Eine Cover zu erstellen wo beide Pfeile immer aktiv sind. Das war ja mein Vorschlag im xknx issue und ich finde das nach wie vor als die beste Lösung: Wenn keine position_address definiert ist, sollte immer beide Pfeile aktiv sein.
- Einen Switch zu erstellen, wo ebenfalls "ein" und "aus" getrennt jederzeit klickbar ist.

[meti]

Ja ^^ https://github.com/home-assistant/core/pull/43645
release Kalender gibts unter https://developers.home-assistant.io

[FRO]

Ok...Danke für Info. War das dann ein Bug ? (0.119 kommt ja soweit ich weiß am 13.12.)

[meti]

Wird in 0.119 wieder funktionieren. Morgen beginnt die Beta.

[FRO]

Hat einer von euch Rolläden/Jalousien in HA aingebunden ? Ich hab seit ein paar Tagen/Wochen das Problem, dass HA scheinbar die aktuellen Positionen nicht mehr mitbekommt und völlig veraltete Stati anzeigt. Hat sich hier was geändert, was ich vielleicht verpasst habe ?
Ein typischer Rolladen sieht bei mir z.B. so aus:

[COLOR=#d4d4d4]---[/COLOR]
[COLOR=#569cd6]name[/COLOR][COLOR=#d4d4d4]: [/COLOR][COLOR=#ce9178]"EG Bad Rolladen"[/COLOR]
[COLOR=#569cd6]move_long_address[/COLOR][COLOR=#d4d4d4]: [/COLOR][COLOR=#ce9178]'3/1/208'[/COLOR]
[COLOR=#6a9955]# move_short_address: '3/1/209'[/COLOR]
[COLOR=#569cd6]stop_address[/COLOR][COLOR=#d4d4d4]: [/COLOR][COLOR=#ce9178]'3/1/209'[/COLOR]
[COLOR=#569cd6]position_address[/COLOR][COLOR=#d4d4d4]: [/COLOR][COLOR=#ce9178]'3/1/214'[/COLOR]
[COLOR=#569cd6]position_state_address[/COLOR][COLOR=#d4d4d4]: [/COLOR][COLOR=#ce9178]'3/1/215'[/COLOR]
[COLOR=#569cd6]travelling_time_down[/COLOR][COLOR=#d4d4d4]: [/COLOR][COLOR=#b5cea8]51[/COLOR]
[COLOR=#569cd6]travelling_time_up[/COLOR][COLOR=#d4d4d4]: [/COLOR][COLOR=#b5cea8]61[/COLOR]

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

[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

[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

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

[crazyfx]

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

[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

[meti]

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

Wie hast du's jetzt gemacht?

[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]

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.