Hi,
hier mal ein kleiner Hinweis Thread für alle, die wie ich nicht warm werden mit Automatisierungen in HA oder NodeRed.
Die Definition von Automations in YAML ist in meinen Augen so starr und hölzern und dann braucht es Helper und Gedöhns… ich glaube, das ist, um die Einstiegshürde niedrig zu halten, damit jeder ein Licht anbekommt, der noch nie eine Zeile Quellcode geschrieben hat.
Mein Gamechanger ist Appdaemon! Ein echtes Pythonframework mit Zugriff auf alle relevanten Aspekte von HA und Python Bibliotheken.
Man schreibt sich eine generische Klasse zur Automatisierung und kann diese dann über ein zentrales Yaml als Automation-App mit Parametern wie Entitäten aus HA beliebig oft instanzieren.
Appdaemon liefert einfache Methoden sich Listener auf bestimmte Entities, Services zu legen… wird dort eines relevantes Ereignis erkannt, kann man seine selbst definierte „Callback“ Methode rufen und dort beliebig aussteuern was man möchte.
Die instanzierten Apps bleiben geladen und man kann so Daten zwischen Läufen einfach in Variablen ablegen.
Es ist möchlich mit self.set_state(„sensor.käsekuchen“, state=“lecker“) eine Entity in HA anzulegen, upzudaten, die dann in Dashboards angezeigt werden kann… nix template_sensor oder input_boolean rumklicken
Entitäten lassen sich aus HA als Objekte laden und dann deren state und agrumente sowas von nett auslesen
Echte Formeln sind ein Segen… keine Klimmzüge im YAML und wenn ich Median oder Sinus möchte, dann bekomme ich den.
Ich kann jetzt Logik beliebig tief schachteln und in Methoden auslagern.
Ich kann jetzt Apps mit Apps rufen und so zB Notification über ein Framework zentral abbilden.
Ich habe richtige Datenstrukturen, um über Entitäten regelbasiert zu iterieren.
Und es läuft völlig parallel zu HA Automations… die Weihnachtsdeko mache ich dort an und aus.
Für mich ist das ein riesiger Gewinn an Übersicht. Ich konnte jede Menge Helper und Automations verwerfen und habe die Kontrolle zurück. Wer nicht gern programmiert, ist da sicher nicht glücklich. Wer sich aber in Code wohlfühlt, der findet all das, was in HA umständlich oder garnicht klappt.
Ich vermute, für Entwickler bringt dies große Flexibilität, für HA Einsteiger neue große? Hürden.
Wer pflegt eigentlich so ein Framework, fixt und entwickelt?
Kannst du ein Beispiel veröffentlichen und dieses mit einer gleichen Automatisation vergleichen? Dann werden die Vorteile sicher ersichtlicher.
Hi,
für Leute, die in Python programmieren können sicher ideal
Müsste mir eventuell Python mal ansehen, bisher nutze ich NR, da ich dort auch die meisten deiner genannten Vorzüge habe.
Aber je mehr verschiedene Möglichkeiten man hat sein Vorhaben umzusetzen, um so besser!
Danke für deinen Tipp!
In NR geht auch viel, weil du am Ende alles in Function-Node schreibst und dort JS ausführst.
Kennst du Scratch? Super liebevolles Tool, um mit Kindern Programmieren zu lernen auf graphische Weise.
Es wird dann aber bei komplexen Projekten schnell unübersichtlich und mich nervt das Klicken und Rumschieben mit der Mouse.
Ich persönlich mache triviale Sachen noch immer in HA. Bei komplexen Ideen hat mir NR aber auch keinen Spaß gemacht.
Python ist nicht mein Traum, mag Ruby Syntax und Konzepte, aber das fällt auf den noch immer trivialen Level von Haussteuerung nicht ins Gewicht.
Wer irgendeine OO Sprache kann, der kommt mit Python klar.
Einziges Problem sind oft die schlechten Dokus im HA Umfeld. Da wird Komplexität vor Endnutzern versteckt, was zb Service Aufrufe angeht und dann braucht man es in Python plötzlich genauer.
Also in NR arbeite ich nur sehr selten mit Function Nodes, da die meisten Nodes JSONATA verstehen, bzw. es Nodes gibt,die die gewünschte Funktion bieten.
Scratch kenne ich, da auch mein Sohn damit angefangen hat. Ist ja im Prinzip Blockly, welches in der IOBROKER-Community stark vertreten ist. Wie auch immer, Python wäre natürlich im HA Umfeld die erste Wahl, da HA ja auch darin programmiert wurde, aber auch NR erweitert die Möglichkeiten in HA sehr stark.
Da gibt es ein paar 1:1 Bsp hinter dem Link zur Doku.
Die Message ist aber, dass es kein Ersatz für HAA sein muss, damit geht halt ontop viel mehr.
Es ist definitiv nichts, um mit Programmieren anzufangen, weil das ist bestimmt frustrierend.
Wenn man aber im Primzip eine OO Sprache beherrscht fällt es einem viel leichter und man kann super viel Geklicke, Helper und Gedöhns sparen.
Ja, das denke ich auch und finde die Idee wirklich interessant. Man muß Phyton und Objektorientierung nur beherrschen. Ich zweifele, daß dies hier die Mehrheit kann. Aber wie der Vorredner schon sagte
dein Beitrag bringt es echt auf den Punkt – AppDaemon ist einfach genial für alle, die lieber programmieren, als sich mit YAML und zig Helfern rumzuschlagen. Ich finde es mega, was man mit Python alles machen kann: Ob Machine-Learning-Bibliotheken für smartere Sensorauswertungen oder schnell mal eine externe API einbinden, um Daten zu holen, die als Integration fehlen – mit AppDaemon geht das echt flexibel und ohne großen Aufwand.
Ich kann aber auch die Bedenken einiger hier verstehen, dass AppDaemon für Einsteiger etwas anspruchsvoller wirkt. Der Einstieg ist vielleicht nicht ganz so intuitiv wie bei YAML, aber sobald man drin ist, eröffnet es unfassbar viele Möglichkeiten. Aber genau da liegt auch die Stärke: Man kann klein anfangen und dann immer mehr aufbauen, während YAML für komplexere Automatisierungen oft schnell an seine Grenzen stößt.
Ich hatte ebenfalls vor ein paar Tagen auch begonnen, in diesem Forum einen Beitrag zu AppDaemon zu Erstellen, bin aber zeitlich nicht dazu gekommen, die Automation fertigzustellen, die die Vorteile wirklich auf den Punkt demonstriert. In meinem Blog habe ich bereits sowohl eine allgemeine Einführung in AppDaemon als auch einige Automationen vorgestellt, die für Interessierte ein guter Startpunkt sein können.
Vielen Dank für deinen Beitrag, Marc – es ist klasse zu sehen, dass es mehr Leute gibt die Stärken von AppDaemon erkennen und hier Erfahrungen teilen.
Haha,
Ich bin also nicht alleine … schön!
Mir fehlen noch ein paar Puzzleteile, vielleicht hast du ja da schon mehr Know-how?
Das Framework vererbt sehr viel über hass an die App Klasse.
Darunter auch die logger.
Sobald ich Logik in eigene Klassen auslagere, die nicht Kinder von Apps sind, stehe ich ohne Logs zum Debuggen da…
Nutzt du dann einfach eigen logger? Finde schon Pfade in dem Container Gewirr unklar…
Nutze die Visual studio add on in HA.
Hatte auch mal VS per SSH an Container eingewählt aber habe nie einen echten Debugger zum Laufen bekommen, der dann ohne Beschwerden Appdaemon geladen hätte…
Geht alles auch ohne aber vor allem, weil ich Kummer gewöhnt bin und gern rumfrickele.
Aber trotz allem: ich habe jetzt notification framework gebaut.
Jetzt muss ich nicht mehr an 100 Stellen rumbasteln, sondern kann zentral sagen welche Automation wo Ausgaben erzeugt und wo nicht.
Dazu habe ich sauberes logging und nicht diese furchtbaren traces aus HA
ML? Nunja für tensor flow hatte ich noch kein scenario;)
das hass-Objekt bzw. die ADAPI-Basis-Klasse bildet die zentrale Schnittstelle zu AppDaemon und bündelt alles in einer Fassade – praktisch für den Einstieg, auch wenn es nicht immer die sauberste Lösung ist.
Eine Möglichkeit wäre, das hass-Objekt oder gezielt Teile davon, wie das Logging-Objekt, an eigene Klassen im Konstruktor zu übergeben. So bleibt der Code modular und klarer getrennt. Für meinen Teil lagere ich nur den Logikteil komplett in eigene Klassen aus, während z.b. Logging oder setzen/lesen von States in der App verbleibt. Die App nutze ich dann als “Glue-Code”, um die Logik mit Home-Assistant zu verbinden. Dadurch kann ich die Logik-Klassen unabhängig testen und sicherstellen, dass bei gegebenem Input die gewünschte Reaktion erfolgt. Diese Trennung erhöht die Wiederverwendbarkeit und macht es einfacher, die Logik unabhängig und in einer einfach main zu testen.
Was Debugging angeht, liegt hier ein weiterer Vorteil von AppDaemon: Da es sich einfach per WebSocket mit Home Assistant verbindet, kannst du mehrere Instanzen parallel starten. Für die Entwicklung nutze ich eine lokale AppDaemon-Instanz, in der ich gezielt nur die Module lade, die ich benötige. So kann ich problemlos einen Debugger anhängen und gezielt testen, ohne die produktive Umgebung zu beeinflussen.
Was TensorFlow oder ML angeht: Du hast recht, es muss nicht immer das große Geschütz sein. Es gibt viele leichtere Bibliotheken wie Scipy oder Scikit-learn, die mit einfachen Mitteln schon enormen Mehrwert bieten. Sei es für einfache Regressionen, Klassifikationen oder einfach nur um Sensordaten zu interpolieren oder zu extrapolieren.
Man muss sich wohl davon trennen das Appdaemon add-on in HA zum Debuggen nehmen zu wollen.
Ich bin ja im Prinzip mit SSH drangekommen aber es hat nicht gereicht wirklich debuggen zu können.
Zudem hat der Maintainer das Logging stillschweigend auf Systemd Journaling umgestellt.
Im Betrieb super aber in DEV nervt es.
Zum Logger: natürlich könnte ich mir die AppInstanz übergeben fürs logging.
Hauptgrund war aber tatsächlich nur „inline debugging“ wenn HA mich wieder mit unerwartetem State verwöhnt. On of true false unavailable unknown undefined … was da alles fliegt.
Ich hatte denselben Wunsch, vor allem wenn mehrere Entities verarbeitet werden. Allerdings führte das Logging irgendwann zu einer wahren Flut an Einträgen, was es ziemlich mühsam machte, die problematischen Stellen zu identifizieren und nachzuvollziehen.
Deshalb habe ich mir angewöhnt, komplett auf Member-Variablen in der App zu verzichten. Stattdessen speichere ich alle relevanten Informationen direkt als State in Home Assistant. Dadurch kann ich den Verlauf von Variablen und Entities bequem nebeneinander analysieren. Um den Zugriff darauf etwas komfortabler zu gestalten, nutze ich Properties.
In meinem Beitrag zur Beleuchtungssteuerung habe ich diesen Vorteil zwar nicht explizit erwähnt, aber er veranschaulicht das Prinzip:
Jetzt schrecken wir jeden mit Interesse an Appdaemon aber ab
Mit dem Setzen von Variablen in HA direkt kam ich in Trouble mit Threading.
AD feuert den Status zumindest bei Services zum HA mit “fire and forget”
Fragst du den Status aber wieder sehr zeitnah ab, dann bekommst du evtl noch den alten Wert und dann sehr wirres Verhalten, weil der Setter noch nicht durch war, Python aber schon mal weitermacht in anderem Thread.
Ganz extrem war es bei zB alexa_mediaplayer… der dreht noch ne Runde über das Internet zu Amazon und dann muss man aktiv per self.call_in warten, damit zb die Lautstärke zum Ausgabezeitpunkt auch echt angepasst wurde.
Es ist schon wie du sagst, aber in dem konkreten Fall sind es ja AppDeamon verwaltete Entities die nur asynchron an HA gespiegelt werden. Der State wird direkt übernommen (siehe Link) und ist auch im get_state direkt verfügbar.
Das self.call_in ist ja ein grundsätzlicher Mechanismus von HA und gilt auch zum Beispiel für das Einschalten des Lichts. Das wird auch noch mal dadurch verdeutlicht, das zum Ändern eines States immer ein Service bzw. eine Action aufgerufen werden muss.
Wie wäre es, wenn wir mehr AppDaemon-Apps veröffentlichen und so etwas wie Blueprints basteln, um sie einfacher zu teilen? Dann muss nicht jeder gleich coden können, um die coolen Features von AppDaemon zu nutzen.
Ich komme von Java und wollte für mein privates Coden was Netteres lernen mit weniger public static void Gedöhns.
Habe mir dann vor X Jahren Ruby, Python, D angesehen und bin bei der schlagend eleganten Ruby Ecke hängen geblieben, die sowas von konsistent und sexy ist.
Leider ist google auf den anderen Zug aufgesprungen
=> Ich halte meinen RubyCode für relativ konform zu Matz’ Ideen und Konzepten. Mein Python nährt sich im wesentlichen von Ähnlichkeiten zu Ruby und ich falle dann regelmäßig auf Annahmen rein, die in Python schlicht nicht zutreffen Ich kenne auch viele Konventionen nicht.
=> Ich habe keinen Stress meine Sachen in Git zu setzen aber mein Python ist noch improvisiert…
Ich war lange auf der Suche, nach einem “richtigen” Programmier-AddOn.
Mit AppDaemon bin ich da fündig geworden.
Allerdings finde ich die Installations-/Einrichtungs-Anleitungen sehr komplex und ungenügend.
Ich bekomme es zwar hin, einen Trigger mit einer entsprechenden Verarbeitung zu setzen, Aber viele Dinge laufen bei mir noch nichts:
_wo erfolgt überhaupt die Konfiguration?
Per Anleitung soll man unter Config ein Verzeichnis appdaemon anlegen und dort eine appdaemon.yaml. Da hat gar nichts funktioniert.
Dann habe ich unter /root/a0d7b954_appdaemon eine appdaemon.yaml gefunden. Dort kann ich bedingt konfigurieren.
_zusätzliche Loggings. Ich bekomme zwar Meldungen in dem “Standard”-Log, aber ein eigens Log bekomme ich nicht erstellt. Das anzulegende Verzeichnins /logs bleibt leer.
_Einbindung von Secrest läuft auf Fehler.
Das gehört wohl zu dem Thema Konfiguration.
_Neustart von Apps funktioniert nur stellenweise
Eigentlich sollte ja beim Ändern einer App diese neu gestartet werden.
In dem Logging sehe ich dann aber, dass die vorherige Version wieder gestartet wurde.
Nach den Ferien werde ich mir mal den Blog von cemzim anschauen. Vielleicht bekomme ich dann eine Erleuchtung.
Hi @GreatEMU,
da ich leider das Addons Feature von HA nicht nutze, kann ich nur die beiden Varianten mittels pip und docker beitragen:
Als Addon brauchst du eigentlich keine weitere Einrichtung vornehmen… Tokens und HA-Url werden automatisch gesetzt:
Ich nehme an das es mit dem Addon genau so funktionieren muss, testen und verifizieren kann ich es leider nicht. Laut dieser Beschreibung und dem Repository müsste es aber einen apps-Ordner geben, welche die hello.py und apps.yaml enthält. Nach dem selben Schema kannst du dann auch weitere Python Script erzeugen und in der apps.yaml ergänzen.
Zusätzlich kann man Automationen aber auch noch weiter untergliedern, in dem man Ordner unterhalb apps erzeugt die dann jeweils eine yaml mit dem selben Schema enthält. AppDaemon überwacht das gesamte apps-Verzeichnis und verwendet alle yaml- und py-Dateien die es findet:
@anon78667161
vielen dank für das teilen deiner app! das sieht interessant aus und werde es mir näher anschauen. Bzgl. der Abhängigkeiten kann ich nur lose Kopplungen empfehlen:
AppDaemon is a loosely coupled, multi-threaded, sandboxed python execution environment for writing automation apps for home automation projects, and any environment that requires a robust event driven architecture.
Ich bin Eingangs auch wie du dran gegangen und habe Logik in eigene Klasse ausgelagert, die ich dann wiederum in meinen Apps wiederverwendet habe. Bis mir dann aufgefallen ist, das genau dies ja eigentlich AppDaemon für mich macht.
Man kann die App ja als die Einheit Betrachten die wiederverwendet wird und mehrere dieser Apps kann ich ja mittels “externer”-Sensoren mit einander koppeln. So bleiben die Einheiten/Module/Klassen weiterhin schön lose und ich kann mit wenigen Apps schon viele Automatisierungen abbilden.
Als Beispiel der Binary-Converter (siehe oben) nutzt verschiedene “Transformationen” um den Input diverser Sensoren zu kombinieren und als Output bereitzustellen. Zusätzlich habe ich einen DebounceConverter der das entprellen bzw. verzögern von State Changes vornimmt, so das ein State für eine konfigurierbare Zeit vorliegen muss:
Ja, dies lässt sich effizienter in einer einzelnen Klasse abbilden in dem es direkt die einzelnen Fenster/Türen/etc… als Input bekommt und mittels Alexa oder Notify die Benachrichtigung rausschickt, aber so kann ich es relativ einfach mit einander kombinieren und muss dafür “nur” eine Konfiguration Erstellen.
Habe ich komplexere Inputs, welche den Rahmen dieses generisch Ansatz sprengen würden, kann ich ja immer noch eine App Erstellen die mir am Ende ein binary_sensor erzeugt und kann den NotifyController verwenden, um die gewünschte Notification zu erzeugen.
Andersrum ließe sich das jetzt auch als Input für etwas anderes nutzen, um es z.B. neben einer Notification auch für das abschalten der Heizung zu nutzen.
BTW: das ist kein Alarm System, sondern soll uns nur daran erinnern nach dem Lüften die Fenster zu schließen
