Wer nutzt denn eigentlich alles Home Assistant?

[mumpf]

Hi,

ich hatte versprochen noch was zu State Machines (Zustandsautomaten) zu schreiben. Ich hab mal meinen aktuellen Versuch aufgemalt, das versuche ich dann auch mal mit Home Assistant abzubilden:

Statemachine-Geschirrspueler.PNG
Kurzerklärung: Ovale sind Zustände, Pfeile sind Zustandsübergänge, die normalerweise irgendwie getriggert werden. Der Übergang findet nur Statt, wenn die Bedingung vom Zielzustand auch wirklich erfüllt ist. Sobald ein Zustand betreten wird, werden die dem Zustand zugeordneten Aktionen ausgeführt. So ein Zustandsautomat kann sich nur in genau einem Zustand befinden.

Was sehen wir hier: Ich versuche, meinen alten Geschirrspüler smart zu machen. Ich will den normal anmachen können, er soll aber erst waschen, wenn genügend PV-Energie da ist. Oder wenn man die "Trotzdem waschen"-Taste drückt. Falls der Geschirrspüler gestartet wurde und nicht genug PV-Strom da ist, wird man über einen Piepton (PV-Warnung) informiert.

Ich würde jetzt versuchen, das mit automations zu realisieren. Ich würde das auch gerne dann hier einstellen und mit euch diskutieren, ob das dann besser geht. Was besseres als automations habe ich noch nicht gefunden. Falls es da was gibt, bin ich für jeden Hinweis dankbar. Ich finde Zustandsautomaten recht einfach, weil man nur die Bedingungen für die Zustandsübergänge beachten muss und die vergessen kann, die zu diesem Zustand geführt haben. Das macht es einfacher und übersichtlicher.

Gruß, Waldemar

[MarkusLa]

Vielleicht habe ich es auch übersehen: Wo stellst Du sicher, dass die Steckdose an bleibt wenn das Programm läuft und Präsenz aus geht?

[mumpf]

Hi,

Danke für den Hinweis und dass Du Dir das angesehen hast. Wenn das Waschprogramm läuft, ist er im Zustand "Geschirr waschen". Aus dem Zustand geht es nur raus, wenn das Programm fertig ist (gemessen über einen Strommessaktor, wird auch jetzt schon zuverlässig ausgegeben). Dann gibt es einen "Geschirr fertig"-Piep (übrigens nicht in der Küche, sondern im Zimmer meines Sohnes im DG, da es sein Job ist, den Geschirrspüler auszuräumen). Und von da aus geht es wieder zu "Steckdose ein". Und erst von da aus geht es zu "Steckdose aus", wenn in den letzten 30 Minuten keiner in der Küche war.

Eigentlich sollte das so laufen, hab ich aber noch nicht realisiert. Kämpfe etwas mit automations und versuche gerade, das Logging dafür detaillierter hinzubekommen. Wird noch etwas dauern, ich lerne ja noch

Gruß, Waldemar

[trollvottel]

Eigentlich sollte das so laufen

Ah und ich dachte, es scheitert an Sohnemanns Pflichtbewußtsein

[heckmannju]

Dann gibt es einen "Geschirr fertig"-Piep (übrigens nicht in der Küche, sondern im Zimmer meines Sohnes im DG, da es sein Job ist, den Geschirrspüler

Arbeitest du schon dran das er mit 18 Ausszieht? :-)

[mumpf]

Hi,

ich suche mich mal wieder zu Tode... vielleicht weiß jemand ein Stichwort. Ich hab das Problem, dass einige "Automations", die sonst korrekt laufen, bei einem Startup nicht getriggert werden. Ich kann mir das nur so erklären, dass die "Automations" erst nach KNX geladen werden, sonst müsste das doch klappen, wenn die Antworten auf die KNX-ReadRequests eintrudeln.

Ich wollte die entsprechenden "Automations" dann über

trigger:
  - platform: homeassistant
    event: start

loslaufen lassen, aber entweder mach ich da was falsch oder das event kommt auch bevor die knx-Sachen geladen sind. Jetzt suche ich nach einer Möglichkeit, beim Startup eine bestimmte Reihenfolge zu erreichen, also erst "Automations" laden, dann KNX, dann alles passend abzuarbeiten.

Hintergrund: Falls ich HA als meine neue Logik- und Visu-Engine einsetze, muss ich ein definiertes Startup-Verhalten sicherstellen können. Ich will nicht, dass durch einen Restart des Servers (sei es durch manuelle Auslösung oder irgend einen automatischen Restart) plötzlich mitten in der Nacht die Rolläden laufen, nur weil die Zeitinformation (mitten in der Nacht) erst verfügbar ist, nachdem die Rolladenlogik festgestellt hat, dass alle Rolläden hoch sollen).

Weiß jemand, wo ich da nachschauen muss bzw. was nachlesen kann?

Gruß, Waldemar

[moe01325]

Hi,

ich suche mich mal wieder zu Tode... vielleicht weiß jemand ein Stichwort. Ich hab das Problem, dass einige "Automations", die sonst korrekt laufen, bei einem Startup nicht getriggert werden. Ich kann mir das nur so erklären, dass die "Automations" erst nach KNX geladen werden, sonst müsste das doch klappen, wenn die Antworten auf die KNX-ReadRequests eintrudeln.

Ich wollte die entsprechenden "Automations" dann über

trigger:
- platform: homeassistant
event: start

loslaufen lassen, aber entweder mach ich da was falsch oder das event kommt auch bevor die knx-Sachen geladen sind. Jetzt suche ich nach einer Möglichkeit, beim Startup eine bestimmte Reihenfolge zu erreichen, also erst "Automations" laden, dann KNX, dann alles passend abzuarbeiten.

Hintergrund: Falls ich HA als meine neue Logik- und Visu-Engine einsetze, muss ich ein definiertes Startup-Verhalten sicherstellen können. Ich will nicht, dass durch einen Restart des Servers (sei es durch manuelle Auslösung oder irgend einen automatischen Restart) plötzlich mitten in der Nacht die Rolläden laufen, nur weil die Zeitinformation (mitten in der Nacht) erst verfügbar ist, nachdem die Rolladenlogik festgestellt hat, dass alle Rolläden hoch sollen).

Weiß jemand, wo ich da nachschauen muss bzw. was nachlesen kann?

Gruß, Waldemar

interessante frage, direkt beantworten kann ichs leider auch nicht.

entweder du versuchst mittels logfile analyse herauszufinden was zuerst fertig ist, oder du machst in die HA startup trigger automations noch einen zusätzlichen delay hinein? einfach um praktisch sicher zu stellend dass knx module etc schon geladen sind?

[meti]

Soweit ich weiß speichert HA die Zustände der Entities. Vielleicht wird nix getriggert (sofern nicht anders konfiguriert) wenn der Wert sich zum gespeicherten nicht geändert hat.

Hast du ein Beispiel für so ne Automation?

[mumpf]

Hi meti,

ich mache jetzt erstmal ein paar Tests, um das Verhalten genau zu verstehen.

Vielleicht wird nix getriggert (sofern nicht anders konfiguriert) wenn der Wert sich zum gespeicherten nicht geändert hat.

So wie ich das derzeit sehe/verstehe, werden beim Startup gar keine automations getriggert, egal was mit dem Wert passiert. Ich habe folgendes mal gemacht:

automation:
  # startup tests
  - alias: 'test_trigger_source'
    description: Triggerquelle
    trigger:
      - platform: state
        entity_id: 
          - light.licht_bett_rechts
        to: 'on'
    action:
      - service: notify.mobile_app_nokia_9
        data:
          title: Test
          message: "automation gestartet"
          data:
            timeout: 60

Wenn ich im Normalbetrieb "light.licht_bett_links" schalte (das Licht ist über KNX geschaltet), bekomme ich brav eine Notification aufs Handy, wenn das Licht eingeschaltet wird, egal ob über HA oder KNX - so soll das sein.
Nach einem Startup bekomme ich keine Notification, und zwar egal, ob sich der Wert von "light.licht_bett_links" geändert hat oder nicht. Ich hab auch explizit den Test gemacht, dass ich vor dem Startup das Licht ausschalte und dann während des Startup einschalte. Im Lovelace-UI bekomme ich dann:

• unten die Meldung, dass HA startet und somit nicht alle Elemente verfügbar sind
• meine light-entity ist im UI gelb mit dem gleichen Text
• dann wird das light-entity erzeugt, man sieht es im UI mit "off"
• dann kommt wohl der "GroupValueRead" zurück, die light-entity geht auf "on"
• kein notify aufs Handy

Jetzt muss ich es noch schaffen, über den homeassistant.start-Trigger vorher noch ein notify aufs Handy zu bekommen, dann hab ich auch ausgeschlossen, dass die notify-plattform noch nicht geladen war.

Wahrscheinlich ist es gar nicht dumm, beim startup keine automations zu starten, denn es können sehr viele werden und damit viele (auch unerwünschte) Aktionen ausgelöst werden. Aber ich will auch in Sync mit den KNX-KO sein, und da fällt mir immer wieder auf, dass das sporadisch nicht so ist.

Wenn man dann mit Zustandsautomaten arbeiten möchte, wird das Problem schlimmer, weil nach einem Restart potentiell ein Zustandsautomat in einem Zustand ist, der nicht mehr zu dem Zustand auf dem KNX-Bus passt und es womöglich keinen Weg mehr gibt, der aus diesem Zustand "rausführt". Da muss ich noch weiter forschen.

Vielleicht wird nix getriggert (sofern nicht anders konfiguriert)

Du schreibst "sofern nicht anders konfiguriert"... gibt es denn da Möglichkeiten, was zu konfigurieren? Ich hab nichts gefunden... oder meinst Du   ignore_internal_state ? Das ist bei mir auf true, damit immer ein Trigger gesendet wird.

Gruß, Waldemar

P.S.: Ich hab jetzt mal meinen Zustandsautomaten für den Geschirrspüler implementiert, der läuft auch, aber bleibt eben manchmal in einem Zustand hängen, wenn ich HA neu starte (was ich wegen meiner vielen Versuche durchaus häufiger mache). Insofern ist das noch nicht gut genug, um hier vorgestellt zu werden...

[meti]

Ja das mein ich. Dabei wird aber absichtlich nicht bei GroupValueRead requests getriggert (es sei denn der State hat sich geändert) weil sonst der StateUpdater automations auslösen könnte. (stand xknx 0.15.3). Das kann man zwar durch eine from: Klausel verhindern, aber wer macht das schon 🤣

selbes gilt für always_callback bei Sensoren.

Edit: das gilt nicht im startup Fall weil da die values None waren (in xknx, nicht HA)

[mumpf]

Hi,

Das kann man zwar durch eine from: Klausel verhindern, aber wer macht das schon

das habe ich ehrlich gesagt nicht verstanden. Welche from: Klausel? Und wo wird die angegeben? Ich verwende übrigens nur das eingebaute (x)knx. Macht es irgendwie Sinn, auf xknx zu gehen? Kann man da mehr ausdrücken?

In dem Zusammenhang noch ne noob-Frage: Ich habe es nicht geschafft, bei knx entities friendly_name: bzw. icon: zu spezifizieren. Geht das nicht, gibt es einen Trick oder mach ich was falsch? Wenn man name: lesbar macht, wird der name der entity verunglimpft. Und für icon: muss man immer im UI was spezifizieren, das ist blöd, vor allem, weil auf Hilfsdialogen dann trotzdem die von der Integration vorgegebenen icons drauf sind.

Gruß, Waldemar

[meti]

Welche from: Klausel?

Du kannst in einem Automation trigger nicht nur "to: "on", sondern auch "from: off" angeben, dann sind zB calls von periodisch sendenden GAs gefiltert.

Macht es irgendwie Sinn, auf xknx zu gehen? Kann man da mehr ausdrücken?

Nur wenn du beim Beta-testen helfen willst. Nein.

Ich habe es nicht geschafft, bei knx entities friendly_name: bzw. icon: zu spezifizieren.

Das geht von über customize, nicht über den knx key. https://www.home-assistant.io/docs/c...izing-devices/
Es gibt aber ne Diskussion düber hier: https://github.com/XKNX/xknx/issues/296

[Tontechniker]

Kann mir hier jemand hefen?
Ich habe den KNX-daemon von Franz Koch versucht für meine KNX TPUART-Anwendung einzusetzen. Leider arbeitet er mit der Schnittstelle ttyACM0 (externer TPUART über USB). Ich habe auf meinem Raspi aber eine interne TPUART, die über ttyAMA0 angesprochen wird. Was muß ich ändern, damit ich von Home Assistent auf KNX zugreifen kann?
Gruß
Hans

[meti]

Die knx Integration von HA spricht ausschließlich KNX-IP (tunneling und routing), kein TP. Vielleicht kann man das irgendwie mit knxd machen, sowas hab ich nie probiert.

[mumpf]

Hallo Hans,

läuft Dein KNX-TPUART mit knxd? Ich habe HA erfolgreich mit dem eibd (Vorläufer vom knxd) + USB-Schnittstelle und alternativ mit einer MDT-Schnittstelle getestet, läuft beides. Wenn Du also knxd auf Deinen Raspi bekommst, wird das wahrscheinlich klappen. Dem kann man auf jeden fall die Schnittstelle mitgeben, über die er kommunizieren soll. Und der knxd kann seinerseits von IP nach KNX tunneln.

Gruß, Waldemar