Stateengine Plugin Support

[Onkelandy]

Inzwischen ist das autoblind Plugin von offline ja als stateengine im develop von smarthomeNG angelangt und funktionstüchtig. Es steht seit 1.6 Release für alle zur Verfügung.

Etwaige Fragen bezüglich Handhabung also bitte ab sofort hier rein. Zum Start eignet sich auch der Blogeintrag auf der SmarthomeNG Seite:
https://www.smarthomeng.de/tag/stateengine

Ansonsten hilft die Doku, die ich ebenfalls massiv überarbeitet habe: https://www.smarthomeng.de/user/plug...user_doc1.html

[gama]

Hi,
ich haben ein Issue (Bug?) für StateEngine entdeckt:

Bei mir laufen zwei Arten von StateEngine, "HOME" ermittelt den Hauszustand, z.B. Anwesend, Abwesend, Urlaub, etc. und "SHUTTER" die Raffstore/Rolladen Position.
Jetzt habe ich einen Shutter-Zustand, der nur bei "Abwesend" aktiv werden soll. HOME setzt bei Abwesend ein entsprechendes Item, welches wiederum SHUTTER triggert. Das funktioniert auch soweit, jedoch wird eine daran geknüpfte Zustandsermittlung ignoriert und nicht ausgeführt, da der Trigger "StateEngine" ist und eigens getriggerte Items ignoriert werden - klar, die Gefahr einer Endlosschleife...

Technisch gibt wird der "caller" als "StateEngine Plugin" gesetzt und dann wieder identifiziert, sobald das item aus einem StateEngine heraus gesetzt wird.

StateEngineAction.py

...
            item(item.conf[self.__byattr], caller=StateEngineDefaults.plugin_identification)
...

StateEngineDefaults.py:

...
plugin_identification = "StateEngine Plugin"
...

StateEngineItem.py

        if orig_caller == StateEngineDefaults.plugin_identification or caller == StateEngineDefaults.plugin_identification:
            self.__logger.debug("Ignoring changes from {0}", StateEngineDefaults.plugin_identification)
            self.__update_in_progress = False
            return

Ich bin jetzt nicht so tief drin, aber soweit ich es sehe, wäre mit unterschiedlichen plugin_identification für HOME und SHUTTER das Thema vom Tisch, oder?
Vielleicht könnte man ja das über den SH Multi Instanz Ansatz eine String Erweiterung setzen?

Was meint Ihr?

[Onkelandy]

Ich trau's mich ja kaum sagen, aber ich glaub mit dem letzten commit hab ich das Problem recht elegant gelöst. Der Caller heißt jetzt immer "Stateengine Plugin <NAME DES RULES ITEMS>". Dadurch kann unterschieden werden, ob das Update nun von der eigenen Stateengine oder von einer anderen kommt.

EDIT: Ich habe die Sache inzwischen so gelöst, dass nicht der Caller anders heißt, sondern die "Source" mitgegeben wird und beim erneuten Evaluieren der Stati auch diese Source gecheckt wird. Effekt ist der gleiche: es sollte nun möglich sein, Stateengines von anderen Stateengines zu triggern.

Mich wundert, dass mir das Problem davor nie aufgefallen ist, da ich eine ähnliche Situation wie du bei mir umgesetzt habe....
Müsste man jetzt halt noch in allen Varianten probieren, aber ich denke, es sollte klappen.

[gama]

Ok, ich probiere es mal aus. Danke!

Bei mir ging es auch im Rahmen der zyklischen Zustandsermittlung, aber eben nicht per Ereignis (ist doof, wenn man nach Haus kommt und die Rolladen noch 5 Minuten zu bleiben...)

[Onkelandy]

Ich hab früher auch immer wieder mal ein Retriggering durchgeführt, indem ich das rules Item direkt nochmals aufgerufen habe. Das funktioniert jetzt auch nicht mehr. Daher habe ich nun eine weitere special Funktion in den PR eingefügt. Vorerst sollte die Arbeit am Plugin mal erledigt sein. Bin gerade dabei, meine Items massiv umzuschreiben und mittels struct Vorlagen zu vereinfachen. Und da haben mir beim. Plugin so manche Funktionen gefehlt. https://github.com/smarthomeNG/plugins/pull/246

Die retrigger Funktion funzt so:

se_action_whatever:
 - function: special
 - value: retrigger:..retrigger

..retrigger referenziert dabei ein boolsches Item namens "retrigger" mit enforce_updates: True. Wichtig is natürlich, das Item auch in das eval_trigger der rules zu nehmen.

[schloessl]

Nahezu nach unseren Wünschen läuft meine Verschattung jetzt rund. Bei kleineren Nachbesserungen fielen mir nachfolgende Warnungen noch auf.

Mindestens bei der zweiten Warnung kann ich auf smarthome schließen, deshalb mein Versuch hier.

Die erste Warnung vermute ich im UZSU.

Gibt es einen Hinweis wo ich suchen kann, bzw. schon eine Lösung?

2019-06-27  10:15:09 WARNING  system.datum_uhrzeit.sonne.aufgang DEPRECATED: Used function[COLOR=#FF0000] 'sh.tzinfo()', called in 'class Item (lib.item)[/COLOR]' by '__run_eval -> _task -> _worker -> run -> _bootstrap_inner -> _bootstrap' - use the Shtime-API instead

2019-06-27  10:15:10 WARNING  [COLOR=#FF0000]stateengine[/COLOR]  DEPRECATED: Used function 'sh.return_item()', called in 'a logic?' by 'find_attribute' - use the Items-API instead

Nachtrag :aktuelles 1.6 über Raspi-Image

[Msinn]

Da brauchst Du im Moment nichts zu tun. Du hast nur Deprecated Warnings in etc/smarthome.yaml aktiviert und siehst die Warnungen deshalb. Die Depr ated Warnungen sollen nur Plugin Entwickler darauf hinweisen, dass sie die veralteten sh.xxx Aufrufe durch die neuen ersetzen, die in den entsprechenden lib Modulen definiert sind.

[Onkelandy]

Danke dennoch für den Hinweis. Beim Stateengine hab ich das aktualisiert, beim UZSU war es im aktuellen develop bereits aktualisiert.

Für das stateengine Plugin könnte ich noch Teste der neuen Funktionen brauchen. Ich werde meinen PR mal mergen, da die Zeit reif dafür ist Gerne also von der develop Version mal das Plugin ziehen und im README bzw. user_doc die neuen Funktionen checken.

[schloessl]

Ich kämpfe mich in die struct hinein.

Hierbei fiel mir eine unklare Meldung in Develop Stateeingine auf

2019-07-16  15:10:06 INFO     Main         add_struct_to_template: 'struct' 'stateengine.general' reference found in item 'hmblind5.raffstore3.automatik', instance ''
2019-07-16  15:10:06 INFO     Main         add_struct_to_template: 'struct' 'stateengine.state_lock' reference found in item 'hmblind5.raffstore3.automatik', instance ''
2019-07-16  15:10:06 INFO     Main         add_struct_to_template: 'struct' 'stateengine.state_suspend' reference found in item 'hmblind5.raffstore3.automatik', instance ''
2019-07-16  15:10:06 INFO     Main         add_struct_to_template: 'struct' 'stateengine.release' reference found in item 'hmblind5.raffstore3.automatik', instance ''
2019-07-16  15:10:06 [COLOR=#FF0000]WARNING  Main         add_struct_to_template[/COLOR]: 'struct' definition for 'stateengine.release' not found (referenced in item hmblind5.raffstore3.automatik)

.
Eine Zeile vorher sah es noch richtig aus.
Mein Fehler oder noch eine Testmeldung?


Er ledigt: hier fehlte das "state_" vor dem release

[schloessl]

Eine Verständnisfrage zu den Structs.

Ich habe 4 Blinds in der altten Version zufriedenstellend laufen. Trotzdem versuche ich gerade die Struct-Variante aus dem Develope zu testen.
Ich hatte die Daten in den Stateengine.xx -Vorlagen durch die eigenen Daten für ein Fenster ergänzt (so hatte ich es aus der Doku verstanden)

Bis dahin sah alles gut aus,
Für das 2. Fenster versuchte ich die Statengine.xxx-Structs irgend wie umzubenennen, leider erfolglos.

Wie ist Deine Idee bei mehreren Blinds mit geringen Abweichungen in den Vorgaben die Struct -Lösung zu optimieren?

Im Moment bin ich ratlos, würde aber gerne weiter testen. Irgendwo geistert ein 'Instance': '' herum.
Ist da die Lösung der Zukunft zu sehen?

Danke für jeden Hinweis

[Onkelandy]

Vorlage heißt state_release.
ich bin bei mir noch am Umstellen. Danach kommt bestimmt ein großer Blog Beitrag

du kannst struct beliebig ergänzen und Teile überschreiben. Funzt übrigens mit der Masterversion. Check mal die Doku zu den structs. Ist ja eine core und keine plugin Sache

[Onkelandy]

schloessl Ich habe nun den Blogeintrag mit einem struct Beispiel ergänzt. Hoffe, nun ist alles klar.

[gama]

Hi,
nach dem letzten git pull (auf develop) habe ich gesehen, dass se_lastconditionset_item_name und *_id eingeführt wurden.
Auch im Log kommt

WARNING  StateEngineLogger ...  Problem with attribute 'se_lastconditionset_item_name'.

Werde aber auch mittels der plugin.yaml nicht schlau was diese Funktion leisten soll. Hast Du ein Beispiel? Ersetzt es (zukünftig)

se_laststate_item_name

?

[Onkelandy]

Ne, das ist eine Zusatzfunktion. Wenn du struct: stateengine.general nutzt, kommt die Meldung auch nicht.
Beispiele zum Einsatz hab ich.. die werden dann auch mal sauber verschriftlicht

Ich möchte zB für Sonnenstand nur einen Zustand einführen, aber mehrere Bedingungssets - so ist das sauberer und übersichtlicher. Jetzt würde das aber ohne dem conditionset mit Hysterese für verschiedene Bedingungen nicht wirklich funktionieren. Sprich, ich möchte zum einen eine Hysterese für die Helligkeit, zum anderen für die Temperatur. Die "stay" Conditions Sets richten sich daher nicht nur nach dem letzten state sondern auch letzten condition set.

Außerdem habe ich Situationen, in denen ich Aktionen nur dann ausführen will, wenn der Zustand wegen eines bestimmten Condition Sets aktiviert wurde. Beispiel: "Sicherheit" ist "Sperrzustand" übergeordnet. Ich möchte aber, dass nach Verlassen des Sicherheitszustands die Sperre wieder aktiviert wird, falls sie das vorher auch war.

[gama]

Danke... ich habe es mittlerweile begriffen... cool!