Ankündigung

Einklappen
Keine Ankündigung bisher.

Stateengine Plugin Support

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Stateengine Plugin Support

    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
    Zuletzt geändert von Onkelandy; 18.07.2019, 23:23.

    #2
    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
    Code:
    ...
                item(item.conf[self.__byattr], caller=StateEngineDefaults.plugin_identification)
    ...
    StateEngineDefaults.py:
    Code:
    ...
    plugin_identification = "StateEngine Plugin"
    ...
    StateEngineItem.py
    Code:
            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?

    Kommentar


      #3
      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.
      Zuletzt geändert von Onkelandy; 18.07.2019, 23:21. Grund: Ändern der Funktionalität

      Kommentar


        #4
        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...)

        Kommentar


          #5
          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:
          Code:
          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.
          Zuletzt geändert von Onkelandy; 18.07.2019, 23:34.

          Kommentar


            #6
            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?

            Code:
            2019-06-27  10:15:09 WARNING  system.datum_uhrzeit.sonne.aufgang DEPRECATED: Used function 'sh.tzinfo()', called in 'class Item (lib.item)' by '__run_eval -> _task -> _worker -> run -> _bootstrap_inner -> _bootstrap' - use the Shtime-API instead
            
            2019-06-27  10:15:10 WARNING  stateengine  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
            Zuletzt geändert von schloessl; 28.06.2019, 15:59. Grund: Nachtrag

            Kommentar


              #7
              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.
              Viele Grüße
              Martin

              Stay away from negative people. They have a problem for every solution.

              Kommentar


                #8
                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.

                Kommentar


                  #9
                  Ich kämpfe mich in die struct hinein.

                  Hierbei fiel mir eine unklare Meldung in Develop Stateeingine auf

                  Code:
                  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 WARNING  Main         add_struct_to_template: '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
                  Zuletzt geändert von schloessl; 17.07.2019, 17:22.

                  Kommentar


                    #10
                    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
                    Zuletzt geändert von schloessl; 17.07.2019, 17:25.

                    Kommentar


                      #11
                      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
                      Zuletzt geändert von Onkelandy; 18.07.2019, 23:15.

                      Kommentar


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

                        Kommentar


                          #13
                          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
                          Code:
                          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)
                          Code:
                          se_laststate_item_name
                          ?

                          Kommentar


                            #14
                            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.

                            Kommentar


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

                              Kommentar

                              Lädt...
                              X