Und der State der HA entity schon? HomeKit läuft über HA und sollte davon aktualisiert werden, oder?
Ankündigung
Einklappen
Keine Ankündigung bisher.
Wer nutzt denn eigentlich alles Home Assistant?
Einklappen
Dieses Thema ist geschlossen.
X
X
-
Ignoriere mal HomeKit und schau nur aufs HA Interface. Am besten hier: https://my.home-assistant.io/redirect/developer_states/Zuletzt geändert von meti; 06.11.2021, 17:17.
Kommentar
-
Mit 2021.12 kommen ein paar große Neuerungen - und Breaking changes
https://rc.home-assistant.io/blog/20...eaking-changes
Wäre cool wenn ihr mal die Beta ausprobiert und Berichtet ob alles glatt läuft.
- Likes 1
Kommentar
-
Hallo Matthias,
ich habe mir die Tage eine Home-Assistant Instanz aufgesetzt. Nach viel Suchen und Probieren soll Home-Assistant meine neue Visu werden. Ich habe einen (alten) Eisbär zu laufen, aber ich möchte kein Windows-System mehr und fand die Möglichkeiten bei HA besser als bei anderen.
Wie wohl viele kämpfe ich mit der yaml Konfiguration (Raffstore, RTR). Mühsam aber geht.
Ziel ist eigentlich eine Visu mit mehreren Seiten. Ein Teil davon auf einem Grundriss (z.B. Floorplan) und zum Teil Lovelace Karten.
Wenn ich die "breaking news" richtig verstehe, werden in Zukunft knx Komponenten nicht mehr über yaml eingebunden?
Macht es Sinn jetzt noch alle KNX-Geräte in yaml einzufügen?
Wenn ich Lovelace nutzten will, müssen dann alle KNX-Geräte (derzeit) erst im yaml file sein, oder kann ich die auch direkt in den Lovelace Karten eintragen?
Habe leider dazu in der Doku nichts gefunden.
Gruß Matthias
Kommentar
-
ReinerDaniel das hast du falsch verstanden, nur die Connection Daten, also Ip Adressen zB, werden über das UI eingestellt.
Die Entities bleiben über yaml konfigurierbar.
Falls du Hilfe zur config brauchst kannst du auch gern am Discord server vorbei schauen (englisch) https://discord.gg/EuAQDXU
Entities haben mit dem UI erstmal nix zu tun, die werden immer über yaml von Core geladen und erzeugt. Wie du sie dann in Lovelace darstellst (custom cards etc) ist eine andere Sache (mit der ich mich allerdings 0 auskenne).
Kommentar
-
Sorry, hab da einen falschen Link gepastet. Ist oben korrigiert. Der Server ist für xknx - die lib die von HA verwendet wird. Da findest du meistens auch Hilfe für die Knx Integration.
Wenn du den großen HA Discord Server suchst:
https://discord.gg/c5DvZ4e
Kommentar
-
Hi,
ich kann zwar die 2021.12 beta nicht testen, habe aber die Doku schon mal gelesen. Dabei ist mir folgender Satz aufgefallen (bei READ):
You can use the homeassistant.update_entity service call to issue GroupValueRead requests for all *state_address of an entity.- Ein KO in KNX kann auch nur auf die erste GA senden
- Ein GroupValueRead auf mehrere GA macht überhaupt keinen Sinn, da die letzte Antwort gewinnt. Hörende GA (also alle außer der ersten) sind auch dazu gedacht, nur auf bestimmte Trigger (also nur 0 oder nur 1) zu reagieren. Wenn also mehr als eine GA abgefragt wird, ist die Antwort häufig nicht korrekt, falls nicht alle GA nicht den gleichen Wert liefern.
- Es widerspricht dem Grundgedanken des (langsamen) KNX-Bus, mit einer Aktion mehrere GA zu verschicken. Hier ist es noch schlimmer, weil mehrere Read-Requests geschickt werden, die dann alle auch noch zu einer Antwort führen und alle bis auf eine Antwort (die letzte) sind überflüssig. Wenn dann auch noch die GA jeweils mehreren KO zugewiesen sind, die alle ein L-Flag haben, gibt das schon eine Kaskade von GroupValueResponse-Telegrammen.
Weiß jemand, ob wirklich auf alle GA ein GroupValueRead gesendet wird?
Gruß, Waldemar
Kommentar
-
Hallo Waldemar,
ich denke, Du solltest das direkt mit Matthias Alphart diskutieren. Du findest ihn im HA-Forum als farmio.
Er ist äußerst kompetent und tief in der Materie drin. Außerdem ist er einer der Maintainer der KNX-Integration in HA.
Wenn Du ihn dort persönlich anschreibst, kannst Du das sicher auch auf Deutsch tun.
Gruß
Jörg
Kommentar
-
Jpsy bin ja eh hier 👋
mumpf Hier sind nicht mehrere Adressen für eine Funktion gemeint sondern pro Funktion eine state_address - die passiven Adressen (die erst lange nach der update_entity funktion eingeführt wurden) werden *niemals* gelesen.
Hier ein Beispiel:
Code:light: - name: "Licht1" address: '1/1/21' state_address: '1/0/21' brightness_address: '1/1/22' brightness_state_address: '1/0/22' - name: "Licht2" address: - '2/1/21' - '3/0/1' - '3/0/2' state_address: - '2/0/21' - '3/0/3' - '3/0/4' brightness_address: - '2/1/22' - '3/1/5' - '3/1/6' brightness_state_address: - '2/0/22' - '3/1/7' - '3/1/8'
Bei Licht2 werden mit `update_entity` die Adressen 2/0/21 und 2/0/22 gelesen. Alle passiven Adressen - also alle 3/0/* für on/off und 3/1/* für brightness kommen in einen Topf, egal ob sie bei `brightness` oder `brightness_state` stehen - die werden nicht gelesen.
Zitat von mumpf Beitrag anzeigenEs widerspricht dem Grundgedanken des (langsamen) KNX-Bus, mit einer Aktion mehrere GA zu verschicken.
Man könnte sagen wir haben uns dabei schon was gedacht 😉
Diese ganze passive_address Geschichte ist eigentlich für Geräte gedacht die keine Status-KOs haben. Wenn das Gerät seinen Status sowieso aktualisiert wird man das recht selten brauchen.Zuletzt geändert von meti; 04.12.2021, 20:00.
Kommentar
-
Hi Matthias,
vielen Dank für die ausführliche und kompetente Antwort. Dein Beispiel zeigt, dass es so funktioniert, wie ich es gehofft hatte. Das ist super. Mit der Information weiß ich auch, wie die Doku das gemeint hat! Mit all in
requests for all *state_address
Zitat von meti Beitrag anzeigenMan könnte sagen wir haben uns dabei schon was gedacht 😉!
Zitat von meti Beitrag anzeigenWenn das Gerät seinen Status sowieso aktualisiert wird man das recht selten brauchen.
Gruß, Waldemar
- Likes 1
Kommentar
Kommentar