Autoblind-/StateEngine-Plugin Status - Wie gehts weiter?

[Onkelandy]

Eine andere Frage, die sich mir stellt.. Ob man nicht automatisch beim Pluginstart "on the fly" Items generieren kann. Theoretisch müsste es ja funktionieren, für alle Items, bei denen das Attribut se_plugin vorhanden ist, die Item-Hierarchie in einem neuen gemeinsamen zzz_stateengine.yaml nachzubauen und dort die nötigen Child Items stateengine_id, stateengine_name, stateengine_suspend_end, lock und suspend anzulegen. Oder könnte es da zu Komplikationen kommen? Somit könnte man sich auch die Einträge unter "rules" wie zB se_laststate_item_id sparen.

[smai]

Sowas ähnliches hatte ich auch schon für die UZSU geäussert, damit man nicht für jedes zu schaltende Item manuell ein dict-Item hinzufügen muss.
Der Vorschlag wurde aber nicht so richtig motiviert angenommen.

Es gibt irgendwie die items.yaml, welche man im Plugin-Ordner anlegen kann. Soweit ich weiss ist dies aber nur zu Dokumentationszwecken gedacht.
Ich habe keine Dokumentation dazu gefunden und es wird bisher anscheinend nur im Simulation Plugin verwendet. Vielleicht wissen Msinn oder psilo da Bescheid.

[psilo]

items.yaml im pluginordner? wäre mir neu.. kenne nur die plugin.yaml im plugin ordner

[smai]

Beim Simulation Plugin hast du die Datei angelegt, deshalb bin ich auf dich gekommen.

[psilo]

smai ich glaube die gab es mal als .conf, einfach eine vorlage für die items die das plugin verwendet.. die wird aber nicht automatisch irgendwo geladen etc.

im rahmen der wartung habe ich halt .yaml draus gemacht

[Onkelandy]

So Beispiel-Items gibt es ja auch in anderen Plugins, zB hab ich mal was in wetter.com abgelegt. Wenn man das 1:1 copy-pasten kann finde ich das auch gut genug. Ein automatisches Kopieren könnte da eventuell verwirren.

Aber ja, für die UZSU wäre das auch interessant. Dann müsste das uzsu_item Attribut aber anders gebastelt werden. Dann bräuchte es ein uszu: yes, wie zB beim network Plugin, etc. Ja, das wäre super.

Theoretisch könnte man so ein Konstrukt ja auch ins Plugin einbauen, aber im Core wäre das besser verankert. Vielleicht gibt's diesmal ja ein positiveres Echo für die Idee

[Msinn]

Ich glaube, eine Menge Komplexität entsteht dadurch, dass stateengine so flexibel zu konfigurieren ist.

z.B.:

se_laststate_item_id: und se_laststate_item_name: erlauben es diese Hilfsitems irgendwo in den Itemtree zu legen und beliebig zu benennen. Ich sehe darin aber erstmal (wenn ich auf der grünen Wiese mit Zustandsautomaten anfange) keinen Benefit.

Eine automatisch generierte Struktur (wie von Onkelandy vorgeschlagen) könnte Komplexität entfernen. Eine Festlegung wo die Items liegen und wie sie heißen, macht die Definition generisch:

stateengine:
    type: foo
    rules:
        se_laststate_item_id: ..stateengine_id
        se_laststate_item_name: ..stateengine_name

    stateengine_id:
         type: str
         visu_acl: r
         cache: True
    stateengine_name:
         type: str
         visu_acl: r
         cache: True

Man muss nur sehen, wie man dann damit umgeht, wenn diese Strukturen (aus Vorlagen) mit der aktuellen Kombination aus den items.yaml Dateien gemerged werden (Wer gewinnt bei Key-Gleichheit?).

Ich könnte mir vorstellen, solche Templates evtl. als "komplexe Datentypen" zu handhaben.

Man könnte dann die "Best of both worlds" wählen:

# items.yaml
my_stateengine:
    type: foo

    ...

ergibt zur Laufzeit:

my_stateengine:
    type: foo

    ... # weitere Definitionen aus items.yaml

oder

# items.yaml
my_stateengine:
    type: stateengine
    rules:
        ....

    ...

ergibt zur Laufzeit:

my_stateengine:
    type: foo
    rules:
        se_laststate_item_id: ..stateengine_id
        se_laststate_item_name: ..stateengine_name
        ... # rules aus itmes.yaml

    stateengine_id:
         type: str
         visu_acl: r
         cache: True
    stateengine_name:
         type: str
         visu_acl: r
         cache: True

    ... # weitere Definitionen aus items.yaml

[smai]

Als type würde bei der UZSU nicht funktionieren, weil diese auf Items unterschiedlicher Typen angewendet werden kann.

Bei Key-Gleichheit müsste mMn ein Error geloggt werden und eher die Struktur aus dem Plugin gewinnen, weil sonst das Plugin nicht korrekt ausgeführt werden kann.
Falls technisch möglich wäre ein Merge auf Attribut-Ebene noch besser,. Damit könnte man in den eigenen Items z.B. Attribute weiterer Plugins hinzufügen.

[Onkelandy]

Ist es nicht bei den env Items eh schon so, dass diese vom System vorgegeben sind, aber noch vom User überschrieben/ergänzt werden können?
Ergänzen wäre natürlich perfekt, damit man zB die vorgegebenen Items auch mit den entsprechenden Attributen in ne Datenbank schreiben oder übers Netzwerk schicken kann.

Und sollten widersprüchliche Angaben zB zum Typ gemacht werden, gewinnt tatsächlich das Plugin. Auf die Schnelle fände ich eine Funktion schön, die im parse_item implementiert werden kann. Man muss ja irgendwo auch angeben können, in welcher Hierarchieebene die Items erstellt werden sollen (bei uzsu zB als Child, bei stateengine als parent)

[smai]

parse_item ist aber zu spät. Da müssen die Items bereits angelegt sein, damit andere Plugins sie auch parsen können.

[bmx]

Das ist sicher richtig. Aber vielleicht muß man auch einfach das API aufbohren, damit man zur Laufzeit Items hinzufügen, umbenennen, verschieben und löschen kann. Das ist aber ein ziemlich tiefer Eingriff in den Core. Und da müssen dann die Plugins auch nachziehen. Viele von den Plugins, die ich kenne, speichern beim parse_item die items auf die sie reagieren sollen. Die müßten das dann natürlich mitbekommen, das sich was ändert. Und in der Zwischenzeit könnte man annehmen, das es Probleme mit Threads geben könnte weil es ja zu jeder Zeit Änderungen in der Itemstruktur geben kann. Also muß man zu jeder Item Änderung ein Plugin erstmal informieren was passieren soll damit das Plugin dann entscheiden kann ob es Referenzen löschen muß oder nicht oder ob es gar nicht erlauben kann ein Item entfernen oder umbenennen zu lassen. Gerade die Items, die ein Plugin selbst erstellen würde, dürften ja ggf. nur verschoben aber nicht gelöscht oder umbenannt werden.

Im ersten Step könnte man also allenfalls Items hinzufügen. Dabei muß aber sehr genau darauf geachtet werden, das der Weg in Richtung dynamische Items nicht verbaut wird.

[Msinn]

Das müsste losgelöst von der Initialisierung der Plugins bereits viel eher erfolgen, wenn die Items initialisiert werden.

das ist nicht mit den env.* Items zu vergleichen. env.* Items sind einfach in einer yaml Datei definiert, die nur halt woanders liegen. Das ist kein Template, dass an mehreren Stellen in den geladenen Itemtree gemerged werden müssen.

Einen Konflikt (z.B. Mit UZSU) sehe ich nicht, da nach dem Laden der erweiterte Datentyp im itemtree nicht mehr auftaucht (siehe Post 22)

[smai]

Einen Konflikt (z.B. Mit UZSU) sehe ich nicht, da nach dem Laden der erweiterte Datentyp im itemtree nicht mehr auftaucht (siehe Post 22)

Das zu steuernde Item kann aber einen beliebigen Type haben. Wenn nun der Type auf dem Item auf "uzsu" gesetzt werden muss, kann man den eigentlichen Type nicht mehr angeben.
Zudem können auch mehrere Plugins auf dasselbe Item angewendet werden, das würde mit dem complex type auch nicht gehen.

Für UZSU müsste es etwa so sein:

plugin/uzsu/item.yaml

uzsu:
    type: dict
    uszu_item: ..

user.yaml

schalten:
    type: bool
    uzsu: true

Ergebnis

schalten:
    type: bool
    uzsu:
        type: dict
        uszu_item: ..

Jetzt wo ich das so schreibe, habe ich noch eine dritte Idee: Man könnte ein Import-Attribut einführen:

plugin/uzsu/item.yaml

uzsu:
    type: dict
    uszu_item: ..

plugin/foo/item.yaml

foo:
    type: foo
    foo_bar: blup

user.yaml

schalten:
    type: bool
    import:
      - uzsu
      - foo

Ergebnis

schalten:
    type: bool
    uzsu:
        type: dict
        uszu_item: ..
    foo:
        type: foo
        foo_bar: blup

Und beim Schreiben davon erweitert sich die Idee gleich noch einmal: Warum den Import auf Plugins beschränken?
Man könnte darüber auch User Templates ermöglichen (z.B. in einem Ordner "items/templates"). Beim Import muss man dann einen Pseudopfad in der Art plugins/uzsu/items.yaml bzw. templates/my.yaml angeben.

[Msinn]

Ich kann den Beispielen (3 input Dateien?) nicht ganz folgen, da ich UZSU nicht kenne.

Mein Ansatz ist erstmal Plugin unabhängig und beschreibt „komplexe Item Typen“, die nur zur Laufzeit entstehen. Dabei wird ein Item aus items.yaml ersetzt durch eine Teil-Tree, wenn aly type ein komplexer Typ angegeben wird. Dabei wird die Type Angabe mit ersetzt.

[smai]

Ich kann den Beispielen (3 input Dateien?) nicht ganz folgen, da ich UZSU nicht kenne.

Das foo im Beispiel hat nichts mit UZSU zu tun sondern repräsentiert ein weiteres Plugin.

Dabei wird ein Item aus items.yaml ersetzt durch eine Teil-Tree, wenn aly type ein komplexer Typ angegeben wird. Dabei wird die Type Angabe mit ersetzt.

Kurz zur Struktur der UZSU:
Man hat ein Item mit beliebigem Type (bool, num, string, ...). Im Beispiel ist das   schalten .

Nun kann man eine UZSU definieren, welche dieses Item steuert. Im Beispiel   schalten.uzsu . Dieses Control-Item hat den Type dict sowie ein Attribut uzsu_item mit der Referenz zu dem zu steuernden Item (relativ oder absolut). In diesem Dict werden die Schaltzeiten und -Werte sowie weitere Optionen gespeichert.

Das ursprüngliche Item   schalten  bleibt aber ein gewöhnliches Item, welches auch auf jedem anderen Weg benutzt/verändert werden kann.

Würde man nun in   schalten  einen komplexen Type verwenden, kann man ihm nicht mehr einen tatsächlichen Typ zuweisen.
Allgemein formuliert: Das Item selbst soll gar nicht verändert werden, sondern nur ein Child-Item hinzugefügt werden.