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

[Msinn]

Würde man nun in schalten einen komplexen Type verwenden, kann man ihm nicht mehr einen tatsächlichen Typ zuweisen.

Nein, so ist das nicht gemeint. Im . Beispiel in #22 wird ja genau das Item my_statemachine durch den Teilbaum statemachine ersetzt und erhält dabei den (nicht-komplexen) Typ foo der im komplexen Datentyp statemaschine definiert ist.

Das Item selbst soll gar nicht verändert werden, sondern nur ein Child-Item hinzugefügt werden.

Genau das passiert ja wenn ich im Tree irgendwo my_stateengine als Item eintrage. Damit lege ich ja nur fest, dass ich an dieser Stelle ein komplexes Item einfügen möchte und es den Namen my_stateengine tragen soll.

In der items.yaml Datei ist im einfachen Fall my_stateengine also nur ein Platzhalter für das einzufügende Child. Für die statemachine muss es jedoch möglich sein, ergänzende Teile für für diesen Teilbaum zu spezifizieren (Alltribute und weitere Childs), was bei dem von mir beschriebenen Ansatz auch möglich wäre.

Zur Verdeutlichung: Diese Ersetzung müsste sehr früh erfolgen. Als erstes werden nacheinander die items.yaml Dateien eingelesen und es wird ein Item-Tree in Form eines Dicts aufgebaut. Anschließend werden die Items durch abarbeiten dieses Dicts angelegt. Die Ersetzung müsste bereits beim parsen der einzelnen yaml Datei erfolgen (in lib.config), damit der als Dict aufgebaute Item-Tree bereits alle Ersetzungen/Einfügungen enthält und in diesem Dict keine Verweise auf komplexe Datentypen mehr vorkommen.

[smai]

Ich glaube, unsere Ideen sind gar nicht so unterschiedlich.
Der Unterschied ist wahrscheinlich einzig, dass bei dir ein Platzhalter-Item vorhanden sein muss, welches bei meiner Idee ebenfalls wegfällt.

Bei der UZSU würde ein Platzhalter wenig Sinn machen. Ich möchte ja genau vermeiden, dass der User ein zusätzliches Item anlegen muss, nur weil er ein Plugin nutzen will. So würde die UZSU einfach für ein Item aktiviert, indem man den entsprechenden Import angibt.

Ich kenne die Stateengine nicht wirklich, aber so wie ich die Doku interpretiere, gibt es auch dort unterhalb des zu steuernden Items einen Baum.
Es müsste also auch da einfach ein   import: plugins/stateengine/items.yaml  auf dem übergeordneten Item möglich sein.
Das Ergänzen bzw. Mergen mit den User-Items wäre auch bei meinem Vorschlag möglich.

P.S.: Dieses Root-Item mit   type: foo  finde ich in der Doku gar nicht. Dort gibt es nur ein Item   automatik  ohne type. Ist das foo da überhaupt notwendig?

[Msinn]

Eine Stateengine wird durch einen Teilbaum definiert. Die zu steuernden Item können (und sollten) außerhalb dieses Teilbaums definiert werden.

Foo ist. Icht notwendig. Ein nicht angegebener Type wird immer auf foo gesetzt. Ich habe hier foo nur angegeben, um das analog zur Doku des stateengine Plugins zunhalten.

[smai]

Gibt es diesen Teilbaum dann einmalig für das System oder für jedes zu steuernde Item?
In der UZSU ist es zweiteres.

Unterdessen habe ich per Zufall noch im Simulation-Plugin gesehen, dass dort auch ein Baum gebraucht wird. Dieser ist aber einmalig pro System, ist fix vorgegeben und muss zwingend unter dem Item   sim  auf oberster Ebene liegen.
Das ist nochmal ein anderer Use Case. Für einen solchen Fall wäre es evtl. sinnvoll, wenn es zusätzlich eine Struktur z.B. env.plugin.pluginname gäbe, in welche vordefinierte Items des Plugins automatisch gemerged werden.

Ich habe dann noch stichprobenartig gesucht und bin auf wettercom gestossen, welches wohl auch eine fixe Struktur braucht.

[bmx]

Naja das noch nicht publizierte Indego Plugin braucht das auch zwingenderweise. Momentan muß das vom User angelegt werden.

[Msinn]

Für das stateengine Plugin braucht man je anzulegenden Zustandsautomaten eine Tree Struktur.

[smai]

OK, dann braucht man tatsächlich jeweils ein User-Item. Trotzdem liesse sich auch das genauso mit dem Import abdecken.

Ich fände den Import wie erwähnt auch für eigene Items.
Ich habe z.B. für jedes Fenster inkl. Rolladen immer dieselbe Struktur mit gleichen Typen, eval usw. Wenn es templates gäbe, müsste ich jeweils nur noch die KNX GA einzeln angeben, der Rest wäre zentral pflegbar.

[Msinn]

Wenn es templates gäbe, müsste ich jeweils nur noch die KNX GA einzeln angeben, der Rest wäre zentral pflegbar.

Wie würdest Du denn die KNX GAs in die jeweilige Instanz des Templates einpflegen wollen?

[smai]

Auch durch mergen. Sprich ich müsste die Struktur der KNX-Items zwar noch anlegen, aber nicht mehr jedes Mal alle Attribute.
Dadurch würden die Item-Dateien deutlich übersichtlicher.

Ähnlich wäre es ja dann auch beim Autostate


Konkret würde dann bei mir aus folgendem Konstrukt:

Buero:
    name: Büro
    sv_page: room
    sv_img: scene_office.svg
    visu: 'yes'
    visu_acl: r

    Beschattung:
        name: Rollladen
        sv_widget: "{{ device.shutter('item', '', 'item.auf_ab', 'item.stopp', 'item.Position', '', '', 'item.Preset', 0, 100 ) }} <br />Steuerung {{ basic.flip('item_automatik', 'item.Automatik', 'Auto', 'Manuell') }}"

        auf_ab:
            knx_dpt: 1
            knx_listen: 11/2/10
            knx_send: 11/2/10
            name: auf/ab
            type: bool
            visu_acl: rw
            enforce_updates: 'yes'

        stopp:
            knx_dpt: 1
            knx_listen: 11/2/11
            knx_send: 11/2/11
            name: stopp
            type: bool
            visu_acl: rw
            enforce_updates: 'yes'

        Position:
            knx_dpt: '5.001'
            knx_cache: 11/2/22
            knx_send: 11/2/12
            name: Position
            type: num
            visu_acl: rw

        Preset:
            knx_dpt: 1
            knx_listen: 11/2/13
            knx_send: 11/2/13
            name: Beschattung
            type: bool
            visu_acl: rw
            enforce_updates: 'yes'

        AutoLueftung:
            knx_dpt: 1
            knx_listen: 11/2/14
            knx_send: 11/2/14
            name: AutoLueftung
            type: bool
            enforce_updates: 'yes'

            Trigger_bewegen:
                # reagiert, wenn der Rollladen manuell bewegt wird
                knx_listen: 11/2/12    # Position ändern
                eval_trigger:
                  - ...auf_ab
                  - ...stopp
                  - ...Preset
                eval: self.return_parent().AutoSchliessen(0) or self.return_parent().Abfahrend(0) or 0
                type: bool
                enforce_updates: 'yes'

            Trigger_AufAb:
                # Beim ersten Abfahren nach Öffnen des Fensters wird Schlitzstellung angefahren; beim zweiten Abfahren wird nicht eingegriffen (der Rollladen schliesst normal).
                eval_trigger: B_ro.Beschattung.auf_ab
                eval: (self.return_parent()(1) if value == 1 and self.return_parent().AutoSchliessen() == 0 and self.return_parent().Fenster() == 0 else self.return_parent().Abfahrend(value)) or 0
                type: bool
                enforce_updates: 'yes'

            Fenster:
                # Beim Öffnen des Fensters wird bei geschlossenem Rollladen Schlitzstellung angefahren; beim Schliessen des Fensters wird der Rollladen heruntergefahren, wenn er seit der letzten automatischen Schlitzstellung nicht bewegt wurde.
                eval_trigger: ....Fenster.offen_zu
                eval: (self.return_parent()(1) if value == 0 and (self.return_parent().return_parent().Endlage.unten() == 1 or self.return_parent().Abfahrend() == 1) else self.return_parent()(0) if value == 1 and self.return_parent().AutoSchliessen() == 1 else None) or value
                type: bool
                enforce_updates: 'yes'

            Abfahrend:
                # Beim ersten Abfahren nach Öffnen des Fensters wird Schlitzstellung angefahren; beim zweiten Abfahren wird nicht eingegriffen (der Rollladen schliesst normal).
                # eval_trigger = ....auf_ab
                # eval = (self.return_parent()(1) if value == 1 and self.return_parent().AutoSchliessen() == 0 and self.return_parent().Fenster() == 0 else None) or value
                type: bool
                enforce_updates: 'yes'

            AutoSchliessen:
                # Soll beim Schliessen des Fensters der Rollladen geschlossen werden?
                eval_trigger: ..
                eval: value
                type: bool
                enforce_updates: 'yes'

        Automatik:
            knx_dpt: 1
            knx_cache: 11/2/25
            knx_send: 11/2/15
            name: Automatik
            type: bool
            visu_acl: rw

        sperren:
            knx_dpt: 1
            knx_cache: 11/2/16
            knx_send: 11/2/16
            name: sperren
            type: bool
            visu_acl: rw

        Endlage:

            oben:
                knx_dpt: 1
                knx_cache: 11/2/23
                name: Endlage oben
                type: bool
                visu_acl: r

            unten:
                knx_dpt: 1
                knx_cache: 11/2/24
                name: Endlage unten
                type: bool
                visu_acl: r

    Fenster:
        name: Fenster
        sv_widget: "{{ basic.symbol('item_offen', 'item.offen_zu', 'item.name offen', 'fts_window_2w_open_lr.svg', 0, '', 'or') }} {{ basic.symbol('item_zu', 'item.offen_zu', 'item.name geschlossen', 'fts_window_2w.svg', 1, '', 'bl') }}"

        offen_zu:
            knx_dpt: 1
            knx_cache: 11/4/10
            name: offen/zu
            type: bool
            visu_acl: r
            visu: 'yes'

Noch das hier übrig bleiben:

Buero:
    name: Büro
    sv_page: room
    sv_img: scene_office.svg
    visu: 'yes'
    visu_acl: r
    import: template/fenster.yaml

    Beschattung:
        auf_ab:
            knx_listen: 11/2/10
            knx_send: 11/2/10
        stopp:
            knx_listen: 11/2/11
            knx_send: 11/2/11
        Position:
            knx_cache: 11/2/22
            knx_send: 11/2/12
        Preset:
            knx_listen: 11/2/13
            knx_send: 11/2/13
        AutoLueftung:
            knx_listen: 11/2/14
            knx_send: 11/2/14
            Trigger_bewegen:
                knx_listen: 11/2/12    # Position ändern
        Automatik:
            knx_cache: 11/2/25
            knx_send: 11/2/15
        sperren:
            knx_cache: 11/2/16
            knx_send: 11/2/16
        Endlage:
            oben:
                knx_cache: 11/2/23
            unten:
                knx_cache: 11/2/24
    Fenster:
        offen_zu:
            knx_cache: 11/4/10

Ich bin sicher, dass jeder User solche sich wiederholenden Passagen in den Items hat, wenn auch nicht immer gleich mit dieser Komplexität.
So gibt es z.B. auch für Licht (Dimmer / tunable white LED / RGB) oder auch RTR sich immer wiederholende Items mit gleicher Struktur.

[Tontechniker]

Das würde auch bei mir z.B. die Items für meine Rauchmelder wesentlich vereinfachen. Pro Rauchmelder sind das diese Items:

[Rm]
    [[StatusRM1]]
        [[[Alarm]]]
            type = bool
            name = Alarm
            visu_acl = ro
            knx_dpt = 1
            knx_cache = 3/1/0
            sqlite = init
            enforce_updates = true
        [[[Testalarm]]]
            type = bool
            name = Testalarm
            visu_acl = ro
            knx_dpt = 1
            knx_cache = 3/1/1
            sqlite = init
            enforce_updates = true
        [[[Seriennummer]]]
            type = num
            name = Seriennummer
            visu_acl = ro
            knx_dpt = 12
            knx_cache = 3/1/2
            sqlite = init
            enforce_updates = true
        [[[Betriebszeit]]]
            type = num
            name = Betriebszeit
            visu_acl = ro
            knx_dpt = 7
            sqlite = yes
            cache = yes
            enforce_updates = true
            knx_cache = 3/1/3
        [[[Rauchkammerwert]]]
            type = num
            name = Rauchkammer
            visu_acl = ro
            knx_dpt = 9
            knx_cache = 3/1/4
            sqlite = init
            enforce_updates = true
        [[[Verschmutzungsgrad]]]
            type = num
            name = Verschmutzungsgrad
            visu_acl = ro
            knx_dpt = 5.001
            knx_cache = 3/1/5
            sqlite = init
            enforce_updates = true
        [[[Batteriespannung]]]
            type = num
            eval = value / 1000
            name = Batteriespannung
            visu_acl = ro
            knx_dpt = 9
            knx_cache = 3/1/6
            sqlite = init
            enforce_updates = true
        [[[Temperatur]]]
            type = num
            name = Temperatur
            visu_acl = ro
            knx_dpt = 9
            sqlite = yes
            cache = yes
            enforce_updates = true
            knx_cache = 3/1/7
        [[[Fehlercode]]]
            type = num
            name = Fehlercode
            visu_acl = ro
            knx_dpt = 5
            knx_cache = 3/1/8
            sqlite = init
            enforce_updates = true

[smai]

Wenn man es noch weiter treiben möchte/kann, wären sogar noch Platzhalter wünschenswert.
So könnte man z.B. Teile der GA an das Template übergeben und würde sich die Struktur in den individuellen Items ganz sparen.

Bei meinem Beispiel könnte das etwa so aussehen:

Template:

Beschattung:
        name: Rollladen
        sv_widget: "{{ device.shutter('item', '', 'item.auf_ab', 'item.stopp', 'item.Position', '', '', 'item.Preset', 0, 100 ) }} <br />Steuerung {{ basic.flip('item_automatik', 'item.Automatik', 'Auto', 'Manuell') }}"

        auf_ab:
            knx_dpt: 1
            knx_listen: [MARKIEREN]{0}[/MARKIEREN]0
            knx_send: [MARKIEREN]{0}[/MARKIEREN]0
            name: auf/ab
            type: bool
            visu_acl: rw
            enforce_updates: 'yes'

        stopp:
            knx_dpt: 1
            knx_listen: [MARKIEREN]{0}[/MARKIEREN]1
            knx_send: [MARKIEREN]{0}[/MARKIEREN]1
            name: stopp
            type: bool
            visu_acl: rw
            enforce_updates: 'yes'
...

Item:

Buero:
    name: Büro
    sv_page: room
    sv_img: scene_office.svg
    visu: 'yes'
    visu_acl: r
    import:
        - template/fenster.yaml:
            - 11/2/1

[Onkelandy]

Die Idee mit Template und Platzhalter finde ich sehr schön. Das hat dann aber mit Plugins in dem Sinne nichts mehr zu tun, oder? Es wäre einfach die Möglichkeit für Plugins, im eigenen Ordner ein Template yaml anzubieten, das die User dann manuell in die Item-Struktur einbinden müssten. Und natürlich auch eigene Item-Strukturen zu vereinfachen. Aber es wäre immer nur möglich, Child-Strukturen einzubinden, oder?

In einem weiteren Schritt wäre es dann natürlich schön, den Plugins die Möglichkeit zu geben, die Templates automatisch an eine relativ angegebene Position in der Hierarchie zu setzen.

Im Übrigen fallen mir noch einige andere Plugins ein, die davon profitieren könnten. Kodi, Logitech Squeezebox, avdevice, etc. z.B.

squeezebox_kg:
    type: foo
    squeezebox_playerid: MAC

    power:
        type: bool
        knx_dpt: 1
        squeezebox_send: <playerid> power {}
        squeezebox_recv: <playerid> prefset server power
        squeezebox_init: <playerid> power

    mute:
        type: bool
        visu_acl: rw
        enforce_updates: 'True'
        squeezebox_send: <playerid> mixer muting {}
        squeezebox_recv: <playerid> prefset server mute
        squeezebox_init: <playerid> mixer muting

    volume:
        type: num
        visu_acl: rw
        squeezebox_recv: <playerid> prefset server volume
        squeezebox_init: <playerid> mixer volume
        squeezebox_send: <playerid> mixer volume {}

[smai]

Die Idee mit Template und Platzhalter finde ich sehr schön. Das hat dann aber mit Plugins in dem Sinne nichts mehr zu tun, oder?

Nicht direkt. Aber die Plathalter könnten natürlich auch in den items.yaml der Plugins verwendet werden, etwa für die squeezebox_playerid.

[Msinn]

items.yaml der Plugins

So was gibt das nicht. Was soll das sein?

[Msinn]

Das hat dann aber mit Plugins in dem Sinne nichts mehr zu tun, oder?

Nein und Ja.

Nein, weil es eine allgemeine im Core implementierte Funktionalität wäre (wie ich schon schrieb), die auch ohne spezifische Plugins genutzt werden kann.
Ja, weil Plugins für sie passende Struktur/Teil-Tree - Templates mitliefern könnten.