Stateengine Plugin Support

[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

[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

[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

[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.

[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.

[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

[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.

[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 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]

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]

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