Stateengine Plugin Support

[Onkelandy]

Das se_released Feature ist jetzt im develop Branch. Wäre schön, es würde jemand in Bälde testen.

[mike]

Vielen Dank! Die Änderung funktioniert.

[Onkelandy]

Ja, genau, das habe ich auch entdeckt Werde das entsprechend fixen. Außerdem hab ich einen Fix implementiert, dass die stateengine auch weiterläuft, sollte die Logdatei nicht (mehr) existieren. Werde ich in einigen Minuten in den Develop Branch der Plugins pushen.
Danke fürs Aufdecken.

Kannst du das hier bitte testen mit deinem Setup?
https://github.com/smarthomeNG/plugins/pull/482

[mike]

Ich habe noch ein bischen weitergeforscht.

Der log_level ist global auf 0. Nur bei einer Stateengine ist der log_level auf 2 gesetzt. In __init__.py:65 sehe ich gerade, dass nur wenn log_level > 0 ein Teil durchlaufen wird, wo das log_directory um base erweitert wird ...

[Onkelandy]

Hi!
Bezüglich des Pfades ist eigentlich schon ewig nichts geändert worden. Aufgefallen ist mir, dass du vor dem rules überall ein Leerzeichen hast. Kommt das vom Copy Paste oder passt da was in deinem yaml File nicht..? Klappt es bei anderen Items? Wird das Verzeichnis angelegt?

Wenn du im logging.yaml einen Eintrag für plugins.stateengine.general anlegst, bekommst du dort zum Start auch ein paar Infos zum Log Directory.

Hast du schon mal probiert, das Directory selbst anzugeben im plugin.yaml?

[mike]

Ich habe ein Problem mit dem eingebauten StateEngine-Logging in 1.8.1.
chalte ich den log_level auf z.B. 2 dann soll ja geloggt werden. Das wird auch versucht, allerdings kommt es dabei immer zu einer Fehlermeldung

2021-02-13 14:35:35 ERROR lib.item.item Item heizenlueften.effiziento.heizstaberlaubt.automatik .rules: problem running <bound method SeItem.update_state of heizenlueften.effiziento.heizstaberlaubt.automatik .rules>: [Errno 2] Datei oder Verzeichnis nicht gefunden: 'var/log/StateEngine/2021-02-13-heizenlueften_effiziento_heizstaberlaubt_automatik _rules.log'
Traceback (most recent call last):
File "/usr/local/smarthome/lib/item/item.py", line 1352, in __update
method(self, caller, source, dest)
File "/usr/local/smarthome/plugins/stateengine/StateEngineItem.py", line 426, in update_state
self.__logger.debug("Run queue to update state. Item: {}, caller: {}, source: {}".format(item, caller, source))
File "/usr/local/smarthome/plugins/stateengine/StateEngineLogger.py", line 176, in debug
self.log(2, text, *args)
File "/usr/local/smarthome/plugins/stateengine/StateEngineLogger.py", line 152, in log
with open(self.__filename, mode="a", encoding="utf-8") as f:
FileNotFoundError: [Errno 2] Datei oder Verzeichnis nicht gefunden: 'var/log/StateEngine/2021-02-13-heizenlueften_effiziento_heizstaberlaubt_automatik _rules.log'

Zwischendurch hatte das aber auch einmal funktioniert, da ich im log-File Einträge hatte.

Nun kann ich nicht kontrollieren, ob die Meldung stimmt, da der Pfad ja relativ ist und ich somit glauben muss, dass in dem Pfad wo das probiert wurde dieser Pfad tatsächlich nicht vorhanden ist. Ich habe daher in die Fehlermeldung eine Ausgabe des current-working-directories eingebaut und siehe da das cwd ist: /usr/local/smarthome/plugins. Dort gibt es tatsächlich kein var-Verzeichnis.

Ich starte smarthomeng so:

 [smarthome@smarthome /usr/local/smarthome]$ python3 bin/smarthome.py -f

Also im Verzeichnis /usr/local/smarthome, dem Basisverzeichnis. Wer das cwd dann nach /usr/local/smarthome/plugins ändert ist mir unklar.

Im plugin.yaml von stateengine steht bei der Hilfe zu log_directory:

Die Logdateien der erweiterten Protokollierung werden in das
hier angegebene Verzeichnis geschrieben.
Wenn der angegebene Verzeichnisname mit "/" beginnt wird er als
absoluter Verzeichnisname behandelt. Alle anderen
Verzeichnisnamen werden als Unterverzeichnisse des smarthomeNG
Basisverzeichnisses behandelt. Das angegebene Verzeichnis wird
angelegt, wenn es nicht existiert.
Wenn hier kein abweichendes Verzeichnis angegeben ist, wird das
Verzeichnis ``<smarthome_base_directory>/var/log/AutoState/``
verwendet.

das liest sich für mich so, als ob geprüft wird ob das erste Zeichen des log_directory ein "/" ist und wenn nicht dann wird das Basisverzeichnis von SmarthomeNG davor gesetzt. Wie man aber an der Fehlermeldung sieht fehlt das Basis-Verzeichnis am Anfang. Im Koding habe ich auch nichts gefunden.

Schade ist ausserdem dass der Fehler beim Logging zu der Exception und damit zum Abbruch der ganzen Aktion führt ...

Wie gebe ich nun das Log-Directory relativ zum Basisverzeichnis an?

[gama]

Nein, leider noch nicht wirklich. Ich hoffe auf diese Woche...

[Onkelandy]

gama Schon getestet? Hast du Ideen für den Code..? Ich hab mir überlegt, manche Infos in die States als Properties auszulagern, aber richtig was bringt das auch nicht.

Was vermutlich vernünftig wäre.. beim ersten Start dafür zu sorgen, dass der Suspend nicht gleich aufgelöst werden kann, falls der auflösende Zustand eingenommen werden könnte. Sondern erst beim nächsten Mal..?

[Onkelandy]

Es ist vollbracht - zieht euch am besten die aktuellste Version von meinem github Repo hier: https://github.com/onkelandy/plugins...ne/stateengine

Der Code zum se_released_by Feature hat sich leider im Laufe der Tests und anpassungen zu einer Katastrophe entwickelt. Funktionieren müsste es - aber da geh ich nochmals drüber. Falls jemand Tipps hat, wie das alles nobler zu bewerkstelligen wäre, sehr gerne. Ich blick selber nicht mehr ganz durch, da sich die Funktionsweise von se_released_by als doch recht komplex herausgestellt hat.

Die Doku ist auch aktualisiert, also am besten dort unter 13_sonstiges nachlesen.

[gama]

Cool. Vielleicht teilst Du mal den Code, wenn Du durch bist. Sehe ich mir gerne an...

[Onkelandy]

Das mit Lock und Release State ist ja prinzipiell "klar" bzw. easy, weil beide Stati oberhalb von Suspend sind.. Ich hab hier mal einen prove of concept erfolgreich zum Laufen gebracht mit einem se_releasedby Attribut. Das finde ich schlüssig und sehr flexibel und auch sehr einfach zu konfigurieren. Versuche nun, das Ganze noch so hinzubekommen, dass man auch Listen angeben und das Attribut bei beliebigen States einsetzen kann.

[gama]

Mit dem Auflösen geht es weiter. In meinem Fall, löse ich den Suspend dadurch auf, indem ich lock aktiviere und gleich wieder deaktiviere. Das hat den Vorteil, dass ich nur einen Taster auf dem MDT Schalter belegen muss, aber zwei Funktionen mittels dem "Doppelklick Sperren/Entsperren" auslösen kann. Ich glaube, dass wenn es über eine Standardanwendung hinaus geht, man einen eigenen, vollen struct anlegen muss.

[Onkelandy]

Für 1.8.1 wird der suspend Modus wieder normal wie vorher.. Die manipulierte Variante bleibt aber als state_suspend_dynamic als Struct erhalten. Ich dreh mich grad massiv im Kreis. Weder Sub-Structs, noch se_use helfen irgendwie, einfach einen vernünftigen zweiten Suspend-State zu konfigurieren. Kommt sicher auch drauf an, was man genau möchte. Das Sinnvollste schiene mir, man definiert den suspend ganz oben (unter lock und release) und kann festlegen, welche States den Suspend auflösen können. z.B. durch ein Attribut "se_releasedby" und Angabe der State IDs...?

[Onkelandy]

hi gama Das Update hat es in den neuen 1.8 Release geschafft. Hab für se_use noch ne Optimierung für den develop am Start, aber generell sollte es passen.
Deinen Vorschlag hatte ich sogar schon umgesetzt. Die Structs sind nun als eigene Objekte angelegt und man kann beliebig drauf zugreifen. Aktuell wird es halt von se_use nur für States unterstützt, aber das ließe sich ja ändern. Aber ich sehe noch nicht ganz, wie das die Sache nun einfacher macht - vielleicht du ?

Du kannst dir's ja mal ansehen. Der Suspendmodus hat nun ein paar neue Items im Struct und passt sich dynamisch an, wenn nötig. Aber auch das überzeugt mich noch nicht ganz

[gama]

Das Update sehe ich mir gerne an. Danke schon einmal für die Umsetzung!

Eigentlich bräuchte man klassische Objekte für unser Vorhaben. Gerfühlt kommt man mit se_use und structs sehr schnell an die Grenzen - insbesondre wenn es einfach bleiben soll. Ich glaube mittlerweile, es ist am einfachsten wenn man den code der structs aus plugin.yaml in einen eigenen struct kopiert, sofern es (wie z.B. mit zwei Suspend Modi) komplexer wird. Oder man legt einfach einen von Haus aus weiteren struct im plugin.yaml an, der über 2 suspend States verfügt.