Stateengine Plugin Support

[Onkelandy]

Gibt im develop wieder paar neue Features. Siehe auch readme Datei

[Hasenradball]

Hi OA,

funktioniert das SE auch mit emacean?

[Onkelandy]

Hi OA,

funktioniert das SE auch mit emacean?

Was du wie schaltest ist völlig egal

[Onkelandy]

Erneutes Update auf 1.7.3 mit kleinen Codeänderungen, bitte testen.
Außerdem gibt es nun einige Items, um das neue SV widget von wvhn clock.countdown nutzen zu können. So könnt ihr zB die verbleibende Suspendzeit anzeigen lassen:

clock.countdown('', 'screens.westen_s3.automatik.suspend', 'screens.westen_s3.automatik.suspend_start.unix_timestamp', 'screens.westen_s3.automatik.settings.suspendduration.duration_format', '1s', '')

Die entsprechenden Items werden automatisch im suspend_state struct bereitgestellt, ist also "Plug and Play". Freue mich über Feedback

[firefox]

Guten Morgen Onkelandy,
ich hab in meiner SE Config irgend einen Fehler, finde ihn aber nicht. Die se_eval.get_variable Anweisung wird nicht ausgeführt, oder der .format Teil nicht eingesetzt.

stateengine_default_raffstore:
  settings:
    Nacht:
      hoehe:
        type: num
        cache: True
        initial_value: 100

  rules:
    
    se_template_setvalue: "eval:se_eval.get_relative_itemvalue('..settings.{}.hoehe'.format(se_eval.get_variable('current.state_name')))"

    # Zustand Nacht
    Nacht:
      type: foo
      name: Nacht
      # Aktionen:
      # - Behang ganz herunterfahren
      se_action_hoehe:
       - 'function: set'
       - 'to: template:setvalue'

In der Log Datei taucht dann folgendes auf:

2020-11-13 07:47:02 WARNING plugins.stateengine.EG.Essen.RolloWest.automatik.r ules Determined item 'EG.Essen.RolloWest.automatik.settings..hoehe' does not exist.
2020-11-13 07:47:02 WARNING plugins.stateengine.EG.Essen.RolloWest.automatik.r ules Problem evaluating value of '..settings..hoehe': 'NoneType' object has no attribute 'property'

Ich würde sagen es klappt alles bis auf den fehlenden State_Name in der Item ID. Habs mit dem eval checker versucht, aber der kennt wohl die se_eval Anweisungen nicht.

Was mache ich falsch?

Danke und Grüße
Thomas

[Onkelandy]

se_eval.get_variable('current.state_name') bringt dir den Namen des zustands, der gerade evaluiert wird. Deine Aktionen werden aber NACH der Evaluierung ausgeführt, zu dem Zeitpunkt ist die Variable schon wieder leer. Allerdings ist das Item "state_name" schon befüllt. Daher kannst du das hier stattdessen nutzen:


se_eval.get_relative_itemvalue('..state_name')

in der Doku ist das prinzipiell richtig drin, allerdings müsste ich wohl dezidiert auf diese Unterscheidung hinweisen: https://github.com/onkelandy/plugins..._variablen.rst

Update ist erfolgt: https://github.com/onkelandy/plugins..._variablen.rst
Passt das so?

[firefox]

Update ist erfolgt: https://github.com/onkelandy/plugins..._variablen.rst
Passt das so?

Für mich verständlich so, vielen Dank. Klappt jetzt wunderbar.
😀

[gama]

Guten Morgen,

zunächst ein gesundes und glückliches Jahr 2021 und herzlichen Dank für all die tollen code Zeilen aus 2020!
Über die Feiertage hate ich etwas Zeit, meine Konfiguration umzustellen und insgesamt wieder auf aktuellen Stand zu bringen.

Ich hätte eine Bitte bzw. Idee für Erklärung oder Erweiterung bei der Verwendung von structs - die zunächst eine tolle Sache sind. Jedoch kann man bei zusammenführen in einem Item z.B. die Reihenfolge der Zustände nicht beeinflussen. Es gibt bei mir z.B. den Fall, dass im Nachmodus ein vorheriger suspend aufgelöst werden soll. Somit müsste ich meinen Nacht-Zustand (in etc/struct.yaml definiert) vor den (in der plugin.yaml definiert) suspend Zustand bringen. Jetzt müsste man für jeden eigenen Zustand ein eigenes Struct definieren, sodass man die Reihenfolge beim Item festlegen kann, oder es wäre hilfreich, eine se_prio_* einzuführen, wo man den Zustände entsprechend der Abarbeitung priorisieren könnte.

Vielen Dank und Grüße
Markus

[Onkelandy]

Das Anliegen ist mir klar - ich hab das bei mir auch. Aber mir ist noch nicht ganz klar, wo das Problem liegt. Ich referenziere die structs wie folg:

        osten_bad:
            automatik:
                rules:
                    eval_trigger:
                        - merge_unique*
                        - jalousien.stateengine.jalousientrigger_eg
                struct:
                  - beschattung_se_nachtsettings
                  - stateengine.general
                  - beschattung_se_state_wind
                  - stateengine.state_release
                  - stateengine.state_lock
                  - beschattung_se_state_suspend_nacht
                  - beschattung_se_state_nacht

Und hab einfach noch den normalen Suspend als beschattung_se_state_suspend_nacht mit leichten Änderungen angelegt, damit ich doch auch in der Nacht manuellen Betrieb fahren kann.

Was würde das se_prio machen?

[gama]

Nichts Wesentliches, nur dass man die Templates zusammenfassen könnte und die Auflistungsreihenfolge unter structs nicht mehr kritisch ist.

Achja, noch eine Frage: warum hast Du die Suspend Duration in Minuten angegeben, obwohl diese beim setzen mit " .. * 60" wieder in Sekunden umgerechnet wird? Wäre die Einheit "Sekunden" könnte man direkt das widget basic.input(...'duration'..) verwenden.

[Onkelandy]

Kannst du mir mit einem konkreten Beispiel auf die Sprünge helfen? Du meinst ein struct mit substructs? Aber warum auch dort nicht einfach in der richtigen Reihenfolge listen? Sehe da eher Problempotenzial, wenn man die Reihenfolge dann intern wieder überschreibt, nicht..?

suspend_duration: Ja, das wäre schon ne Möglichkeit gewesen. Ich nutze hier halt immer einen Slider und nicht basic. input. Deinen Ansatz find ich gut, aber ich wüsste jetzt nicht, wie ich das als non breaking Change umsetzen sollte. Du könntest höchstens dein eigenes supsend_template anlegen mit struct: stateengine.suspend und dort einfach se_suspend_time neu definieren und somit das aus dem plugin struct überschreiben? Alternativ könnte ich ein plugin Attribut suspend_time_format einbinden, das standardmäßig minutes ist. Und wenn man es auf seconds setzt, wird der Wert bei der Evaluierung nochmals durch 60 geteilt.. Was meinst du?

[gama]

Für mich war halt die Frage, wie jemand der mit stateengine Neuland betritt, möglichst schnell einen Einstieg und das System zum Laufen bekommt. Daher die Frage, ob es einen speziellen Grund für das Minutenraster gibt. Natürlich, kann man (bzw. ich für meine Installation) eigene Konfigurationen erstellen, aber es wäre m.E. für die Verbreitung und Akzeptanz von StateEngine ein weiterer Schritt... ist aber nur eine Anregung und soll nicht bedeuten, dass jetzt das Plugin meinetwegen geändert werden soll. Ich kann das auch drumherum bauen - ist wirklich kein Problem.

[Onkelandy]

Ne, ich bin da ganz bei dir, dass es möglichst einfach sein soll. Daher bin ich von der prio Sache noch nicht ganz überzeugt Das mit den Sekunden macht aber Sinn. Ich bin da eh schon dran, muss noch intensiv testen und werden dann einen PR erstellen. Musst also nix selbst basteln, nur dann testen.

[gama]

Das Testen übernehme ich gerne.
Einen Gedanken hätte ich noch, da ich gerne einen Status inkl. zugehörigen Settings in ein Struct (quasi als Modul) zusammenfassen möchten:

Aktuell nutzt Du ja auch 3 getrennte Templates für einen zusätzlichen Status:
- beschattung_se_nachtsettings
- beschattung_se_state_suspend_nacht
- beschattung_se_state_nacht

Da beschattung_se_nachtsettings eigentlich keine Reihenfolge benötigt und *_nacht zusammen liegen, könnten doch alle 3 structs zusammengeführt werden, oder übersehe ich da was?

[Onkelandy]

Die Nachtsettings nutze ich global für mehrere Zustände, daher als getrenntes struct. Aber normalerweise hab ich ja settings und rules auch in einem struct (so wie im plugin.yaml ja auch).
Suspend_nacht ist bei mir ein eigener State mit anderen Aktionen als Nacht. Daher zwei unterschiedliche structs. Aber ja, klar, man könnte die auch zusammenfassen, zB als sub-structs. Aber das wäre für mich wieder verwirrend, da ich dann im Item selbst nicht direkt sehe, was ich da genau konfiguriert habe..