Should we get rid of the instance-parameter in multi instance plugins?

[msinn]

When configuring more than one instance of a plugin, the instance parameter is used to bind item attributes to a specific instance of a plugin.

On the other hand, we already have an identifier, that points to the specific instance of those plugins. Each configured plugin has a section name in etc/plugin.yaml. That section name could be used for the same purpose.

That way we could solve some irritations about the configuration of multi instance plugins.

If it is the way to go, I would dig into the code to see how to implement it and to show a migration path.

Questions to address

1. Should we still use the default plugin handling?
2. What happens with attributes without instance name? Used by all or only by default plugin?
3. Should settings of a multi-instance plugin always need an instance name?
4. Can an item use multiple instances (e.g. using settings with different instance names)?
5. Can an item use plugin settings with instance names and without instance names (e.g. AVM plugin)?

Solutions

TDB.

[ohinckel]

That section name could be used for the same purpose.

This was something I implemented already in #127 - but there was the opinion that the instance name should be not coupled with the section name. Further it seems to be not a good idea to have two possibilities to reference the plugin in the configuration (the section name and plugin instance name).

But still, I prefer my approach to reduce confusion, so I'm a little bit happy to see others have also issues with it :)

When implementing such a thing we should decide if we still need two instance names. I would avoid using two plugin names and just use with the section name of the plugin (which is also already used in sh.<sectionname>.plugin_method() to reference the plugin in the SHNG instance).

[maddinador]

When working at pr/144 I stumbled across this instance name thing - and fell.
At first I didn't enter the instance name and received a warning. Why do I additionally need to enter an instance name when I already entered a section name? And concerning items/logics/... when do I use which one?
I didn't found an answer in the doc at writing plugins > multi-instance. Looking at examples helps, but takes some time...
Can the instance name be set to the section name automatically!?

[psilo909]

@msinn i think @cstrassburg had an example where the section name would make problems, but currently i dont remember.. hopefully i do the next days

[cstrassburg]

In #127 steht es drin. Das habe ich damals so implementiert, damit man überhaupt noch ein default Plugin für die Items hat.
Wenn immer nur über den Namen gegangen wird, muss dann zwingend jedes Attribut
bla@name : True
geschrieben werden. Auch wenn ich nur eine Instanz des Plugins verwende.
Worauf geht dann aber:
bla2 : False

Diese bisherige schreibweise der Attribute würde dann ganz wegfallen weil ich immer einen Namen habe und viele Plugins Multiinstance fähig sind.

[msinn]

Ok,
ich kam auf die Idee weil ich in letzter Zeit zwei Support Cases hatte, die genau die oben beschriebenen Probleme/Fragen hatten. Dabei kam auch die Frage hoch, ob ein Item-Attribut in einer MI Umgebung, welches ohne Instance Angabe spezifiziert ist für alle Instanzen gilt, oder ob das für eine Instanz mit dem „speziellen Instancenamen“ leer gilt.

Ein möglicher Lösungsansatz könnte sein, die Instance bei MI Plugins im Hintergrund mitzuführen und bei der Initialisierung aus den Abschnittsnamen zu befüllen. Wenn man Plugins hat, von denen nur eine Instanz geladen wird, würde der Instance Name leer bleiben und die klassische Schreibweise bliebe gültig.

Erhalten bliebe dabei weiterhin das Thema, dass ein MI Plugin mit mehreren Item Attributen erwartet, dass jedem Attribut der Instancename hinzugefügt werden muss, obwohl es höchst unwahrscheinlich ist, dass ein Item einzelne Attribute der verschiedenen Instanzen eines Plugins ansprechen möchte.

Bei diesem Issue geht es mir als erstes darum, dass ein verständliches einfach zu erklärendes Handling entsteht.

[ohinckel]

damit man überhaupt noch ein default Plugin für die Items hat.

Nein, das fällt nicht weg. Jedenfalls nicht mit den Anpassungen aus #127. Damit gibt es weiterhin das Defaut-Plugin, was in der Konfiguration hinterlegt werden muss.

Vielleicht sollten MI Plugins immer den Instanznamen bei den Items gesetzt haben. Falls nicht gibt es eine Fehlermeldung im Log. Wäre aber dann ein breaking change.

Alternativ könnte man einfach das erste MI Plugin in der Konfiguration als das Default-Plugin ansehen. Item-Konfigurationen ohne Instanz würden dem dann zugeordnet. Können dort aber auch mit Instanznamen konfiguriert werden.

In beiden Fällen könnte man auf das zusätzliche instance Attribut in der Plugin-Konfiguration verzichten.

Vielleicht sollten wir die unterschiedlichen Lösungen als Vorschläge in der Beschreibung oben zusammenfassen.

[msinn]

@ohinckel Würdest Du an der Version eines "Default Plugins" festhalten wollen, wenn kein @instance am Item Attribut angegeben ist? Das würde eigentlich bedeuten, dass alle Attribute eines items die sich auf das Plugin beziehen, ein @instance haben müssten. So sind aber nicht alle Plugins implementiert.

Beispiel AVM Plugin:

        uptime_wt:
            type: num
            avm_data_type@willy_tel: uptime
            avm_identifier: willy_tel

Hier bewirkt das avm_data_type@willy_tel, dass für dieses Item die Plugin Instanz *willy_tel genutzt wird. Das Plugin liest dann den avm_identifier ein, obwohl dort nur avm_identifierund nicht avm_identifier@willy_telsteht.

Wenn ich 2 Instanzen (willy_tel und telekom) habe, würde eine Konfiguration wir

        uptime_wt:
            type: num
            avm_data_type@willy_tel: uptime
            avm_identifier@telekom: willy_tel

auch keinen Sinn machen. Ich sehe keinen Fall, bei dem ein Item die Attribute unterschiedlicher Instanzen des selben Plugins referenzieren/nutzen will oder soll.

Dadurch entsteht die Frage: Wie wird ein Item auf eine Plugin Instanz gebunden?

1. dadurch das ein beliebiges Attribut des Plugins ein @instance hat?
2. dadurch das ein bestimmtes Attribut des Plugins ein @instance hat?
3. ganz anders?

Bei 3. wäre z.B. ein Syntax wie folgender denkbar:

        uptime_wt:
            type: num
            avm_instance: willy_tel
            avm_data_type: uptime
            avm_identifier: willy_tel

Ich werde in den kommenden Tagen die bisherigen (und evtl. noch kommende) Vorschläge im 1. Post zusammenfassen.

[psilo909]

Alternativ könnte man einfach das erste MI Plugin in der Konfiguration als das Default-Plugin ansehen.

das finde ich irgendwie noch verwirrender als überall @instance zu nutzen

Ich frage mich auch, wie das mal wird, wenn items eines tages via GUI konfiguriert werden.. vielleicht auch über den use case nachdenken..

[ohinckel]

Das erste Plugin als Default hatte ich nur vorgeschlagen weil es auch Summen gab die sagten "Alle Items anzupassen, nur weil man eine weitere Instanz konfiguriert ist mir zu viel Aufwand".

Mir wäre es am liebsten, wenn man die Instanz angeben muss sobald man mehrere Instanzen konfiguriert hat. In anderen Fällen ist die Abgabe optional.

Ich halte daher nicht unbedingt am Default-Plugin-Handling fest. Mir ging es nur um "einfachere Migrationswege".

Wie das mit den AVM-Plugin harmoniert kann ich nicht sagen. Die Frage ist auch, ob das dort richtig implementiert ist (Zugriff auf Einstellungen ohne Instanzangabe bei den Items).

@msinn ich denke ein Item muss nicht nur einer Plugin-Instanz zugeordnet werden können, sondern kann auch mehreren zugelegt werden. Ausreichen dafür ist eine Einstellung für das Plugin, also mit Angabe der Instanz.

[cstrassburg]

Mir wäre es am liebsten, wenn man die Instanz angeben muss sobald man mehrere Instanzen konfiguriert hat. In anderen Fällen ist die Abgabe optional.

Und genauso ist es doch implementiert (oder war zumindes so)

Wo liegt eigentlich das technische Problem hier? Wenn Du nur eine Plugin Instanz verwendest, musst du nirgendwo etwas angeben. Wenn man mehrere Instanzen verwenden möchte muss man sich Gedanken machen was über die Instanzen laufen soll.
Wo ist denn der Anwendungsfall aus der Praxis für ein Item das von mehreren Plugin Instanzen verwendet wird?
Die Plugin Instanzen sind in der Regel dazu da um mehrere gleiche Hardware-Komponenten anzusprechen. zwei Stromzähler, zwei AVM Geräte, zweiter KNX Bus, etc.

[ohinckel]

Und genauso ist es doch implementiert (oder war zumindes so)

Wenn man den Kommentaren glauben soll, ist das nicht so: man möchte nicht alle Items anpassen müssen, wenn man später eine zusätzliche Plugin-Instanz konfiguriert, sondern nur die für die neue.

Für mich ist das kein Argument, nur weil es einem die Arbeit erspart. Dann bräuchte man sich auch keine Gedanken über das Default Plugin machen. Nur meine Meinung, und evtl. erspart das einen Anwender tatsächlich Arbeit. Mit wäre es egal, aber dazu diskutieren wir hier ja.

Wo ist denn der Anwendungsfall aus der Praxis für ein Item das von mehreren Plugin Instanzen verwendet wird?

Ob man das braucht oder unterstützen sollte weiß ich auch nicht so genau. Vielleicht handelt man sich damit nur noch mehr Ärger ein.

Das AVM Plugin beispielsweise verwendet aber Item-Konfiguration mit und ohne Instanzangaben (siehe oben). Direktes Verwenden von Item.conf macht's möglich und wird auch bisher nicht verhindert.

Ich habe aber auch z.B. das Database Plugin mit mehreren Instanzen konfiguriert (normales Logging und Reporting Logging) und habe somit Items die an mehreren Instanzen eines Plugins gebunden sind.

Ich könnte mir auch noch andere Fälle vorstellen (z.B. operationlog Plugin mit dem man Logs parallel in unterschiedlichen Logs verteilen möchte). So ganz abwegig ist das also nicht.

[Morg42]

Ich finde die nicht zwingend einheitliche Benennung des Plugins in der plugin.yaml sowie die Instanz auch nicht hilfreich.

Wenn nur ein Plugin da ist, braucht man keine Angaben zur Instanz o.ä.

Ich wäre dafür, dass bei mehreren Instanzen eines Plugins dann z.B. den Namen des Plugins aus der plugin.yaml als Instanzbezeichner benutzt.

Die Notwendigkeit bzw. Möglichkeit, in einem Item mehrere Instanzen desselben Plugins zu verwenden, sehe ich auch nicht. Es wäre also auch eine "item-weite" Deklaration möglich, wie oben schon genannt

uptime_wt:
    type: num
    plugin1_identifier: <name von plugin1> # möglicherweise für mehrere Plugins in einem Item...
    plugin1_attr1: foo

Damit würde komplett auf die zusätzliche Deklaration von instance verzichtet werden können.

Nachteilig wäre sicher, dass es mehr Schreibaufwand ist, wenn nur ein oder zwei Attribute verwendet werden.

[Morg42]

Noch eine Idee:

im Prinzip wie oben den "identifier" aus der plugin.yaml

1. als Instanznamen benutzen,

item:
    instance: plugin_id

    subitem:
        instance: ..:.

# oder, wenn Attribute mehrerer Plugins verwendet werden:
item2:
    instance:
        - id_1
        - id_2

Die Mechaniken, das auszulesen, sind alle vorhanden und nonbreaking; allein der Wechsel des Instanzbezeichners

• vom Attributsuffix zum Attributparameter (val@foo -> instance: foo)
• vom selbst vergebenen Instanznamen zum Plugin"namen"
  wären zu kommunizieren und umzusetzen.

Das sollte sogar relativ simpel per Skript machbar sein. Wenn wir entscheiden, diesen Weg zu gehen, schreib' ich das Skript ;) (bash oder Logik? :-D )

[onkelandy]

Letzteren Ansatz mit dem Attribut finde ich nicht so schlecht - das korreliert auch mit der Funktion, wie sie momentan bei structs umgesetzt ist.

[Morg42]

Wenn man den usecase "ein Item mit mehreren Instanzen desselben Plugins" berücksichtigt, wäre vielleicht noch eine weitere Variante:

• als Instanzbezeichnung kommt der Plugin-Identifier (key aus dem plugins.yaml-dict) zum tragen.
• bei nur einem Plugin keine Instanz notwendig
• bei mehreren Plugins entweder
  • alle Items mit Instanzen versehen, oder
  • ein plugin mit 'default_instance: true' markieren
• bei mehreren Plugins ohne default und Item-Attribute ohne Instanz eine Warnung oder ggf. Fehler ausgeben -> nicht zugeordnet.

Damit wären die Fälle

• default (ohne Instanzangabe)
• eindeutige Instanzangabe pro Attribut
• mehrere Instanzen auf einem Item
• mehrere Plugins, jedes mit Instanz
• mehrere Plugins, eins (default) ohne Instanz

alle abgedeckt. Die Instanz könnte weiter als item_attr@identifier: <val> angegeben werden.

Damit wäre es - außer bei Mischung von Attributen mit und ohne Instanz - nonbreaking mit Ausnahme des Wechsels von instance: foo zum Plugin-Bezeichner.

Durch die Nutzung des Plugin-Bezeichners könnte (analog struct-Vorschlag) auch systemweit eine eindeutige Referenzierung auf das Plugin erfolgen.

[Morg42]

Bei den structs ist es möglich,

item:
  struct: <plugin>.<struct>
  instance: <foo>

oder

item:
  struct: <plugin>.<struct>@<foo>

Mit dem (noch nicht gemergten) PR #692 wird <plugin> durch den Identifier (im Code config_name, also den Abschnittsnamen aus der plugin.yaml) identifiziert.

Plugins werden im sh-Object (und im sh.plugins-Objekt) ebenfalls mit ihrem Identifier eingebunden.

Von daher finde ich den Ansatz von ohinckel, die Instanz für Item-Attribute ebenfalls über den Identifier zu spezifizieren, zielführend und konsistent.

Aus meiner Sicht spräche auch nichts dagegen, so wie bei Structs entweder

item:
  item_attribute1@<foo>: bar

oder

item:
  item_attribute1: bar
  instance: <foo>

zu erlauben. Ja, das ist eine Redundanz (aber dieselbe Redundanz wie bei den structs). Und ich kann mir im Moment auch keinen Anwendungsfall vorstellen, wo ich einem Item sowohl ein Struct als auch zusätzliche Item-Attribute für ein anderes (oder mehr als ein) Plugin zuweise - in dem Fall wäre die Spezifizierung mit instance: <foo> nicht eindeutig; die Angabe mit item_attrib1@<foo>: bar bzw. struct: <plugin>.<struct>@<foo> ist immer eindeutig.

Ich würde mehr Schwerpunkt auf einheitliche Bezeichnung legen als auf zwingende Beibehaltung aller Konventionen; insofern wäre mein Vorschlag, den Identifier zu benutzen und beide Instanzmöglichkeiten zu erlauben.

Das ist - bis auf den Identifier - nonbreaking, eindeutig und (wie ich finde) verständlich.

Wir müssten dann allerdings entscheiden, ob MI-Plugins immer mit Instanzangaben angegeben werden müssen, oder ob es einen default_instance: true-Parameter geben soll. Ich wäre hier für die erste Möglichkeit.

Wollen wir mal versuchen, hier zu einer Einigung zu kommen, so dass wir das nach dem Release implementieren können? Das meiste davon ist schon vorhanden, und soweit ich das sehen kann, auch (fast) trivial zu implementieren.

Ob man dann den instance-Parameter weiter mitschleppt und mit dem Plugin-Identifier belegt (spart Anpassungen im Inneren von lib.items.item, smartplugin und AdminUI), oder komplett darauf verzichten (sauberer, weniger Overhead, später ggf. einfacher zu warten), ist davon unabhängig.

@msinn, @bmxp, @onkelandy, @psilo909: Habt ihr eine Meinung dazu, oder würdet ihr euch eine bilden?

[onkelandy]

Generell finde ich den Ansatz mit den Identifiern vernünftig, die waren sonst bisher doch immer recht verwirrend. Man müsste dann halt noch darüber nachdenken, wie man die Methode sh.plugins.get() bzw. return_plugin oder was es dort alles gibt "sortiert" bzw. positioniert..?
Das erzwungene Angeben einer Instanz bei einem MI Plugin fände ich ehrlich gesagt nicht so prickelnd. Könnte man nicht einfach checken, ob ein Plugin 1 oder mehrfach im plugin.yaml deklariert ist und entsprechend korrekt automatisiert intern zuordnen..?

[Morg42]

Das erzwungene Angeben einer Instanz bei einem MI Plugin fände ich ehrlich gesagt nicht so prickelnd.

Nur zum Verständnis: natürlich nur, wenn das Plugin auch mehrfach eingebunden ist...

Wie geschrieben können wir auch die default-Mechanik beibehalten (erstes in der Liste oder manuell bestimmt...)