Universelles Interface-Plugin - Ideen/Vorschläge

[Morg]

Moin,

nachdem Onkelandy das Thema "geräteunabhängiges universelles Plugin für alle Interfaceaufgaben" (ich übertreibe etwas) angesprochen hatte, hat mir die Idee noch nicht ausreichend Ruhe gelassen, um im Homeoffice nicht doch immer wieder in Richtung SublimeText zu schielen...

Nach einigen Überlegungen, verworfenen Ideen und viel Rumkrauterei habe ich mir etwas überlegt, das ich euch - als Idee, als Anregung, als Vorschlag, als Grundlage zur weiteren Entwicklung - vorstellen möchte.

Aus meiner Sicht und - bescheidenen - Erfahrung teilt sich die Arbeit bei Interface-Plugins im Wesentlichen in zwei Teile:

a) der geräteabhängige Teil mit "hardwarenaher" Kommunikation, Datenwandlung und Auswertung
b) der geräteunabhängige Teil mit Plugin- und Itemverwaltung.

Teil a) lässt sich kaum sinnvoll generalisieren; wenn ich mir die drei Plugins

• yamahayxc (netzwerkbasiert, Abfrage in URL mit mehreren Komponenten, teilweise POST-Daten, Rückgabe in JSON mit verschachtelten Strukturen, Push-Notifications auf dafür notwendigen Unicast-Server),
• SMLx (binäres Protokoll über USB/seriell, nur lesen von zyklischen "Push"-Informationen) und
• Viessmann (anderes binäres Protokoll über USB/seriell, aufwändiger Handshake, sehr komplexe (und schlecht dokumentierte) Befehls- und Datenlage)

anschaue, finde ich wenig Gemeinsamkeiten.

Das Viessmann-Plugin (basiert wohl auf dem Comfoair-Plugin) hat eine komplexe, aber relativ flexible Gerätekonfiguration über umfangreiche Datenfelder, die aus einer Datei eingelesen werden. Idee 1.

Das yamahayxc-Plugin habe ich (um es "ordentlicher" zu machen) mal komplett auf Papier in Ablaufdiagramme gebracht, bei denen ich mir die Datenströme im Plugin und die entsprechenden Strukturen im Code angeschaut habe. Idee 2.

Dann bin ich noch über einen Artikel zur OOP gestolpert, der mich an eine Idee erinnert hat, die ich schon fast vergessen hatte... Idee 3

Damit bin ich jetzt bei einer neuen Klasse, bzw. bei drei neuen Klassen gelandet:

• class SmartDevicePlugin(SmartPlugin)
  Diese definiert den Rahmen der oben beschriebenen geräteunabhängigen Funktionen und hat von den Geräten und Befehlen keine Ahnung. Es liest die Geräte- und Befehlskonfiguration aus den Items aus. Die Instanz dieser Klasse kann MultiInstance benutzen oder ein oder mehrere Geräte in einer shng-Instanz verwalten.
  Für jedes gefundene Gerät erzeugt es eine neue Instanz der Klasse
• class SmartDeviceEntity()
  Diese definiert ein Gerät, die "physikalisch" Verbindung mit Auf- und Abbau und den Befehlssatz. Hauptaufgabe ist die "Verwaltung" des Gerätes und der Verbindungen. Der Datenaustausch wird hier organisiert und verwaltet; aber zu jedem Gerät gehört ein sog. Protokoll. Für das Protokoll gibt es jeweils eine Instanz der Klasse
• class SmartDeviceProperty()
  Diese definiert Datentransformation (shng: num <-> device: int unsigned 2 byte, transformiert 1/10, oder wasauchimmer), Befehlsumsetzung von "Klartextbefehlen" in shng zu strings, URLs oder bytearrays und die tatsächliche Transformation der Daten (Bitschieberei, Checksummen usw)

Das ist erstmal etwas komplex, hat aus meiner Sicht aber folgende Vorteile:

• die Klasse SmartDevicePlugin ist quasi fertig, weil ich die aus den drei genannten Plugins so zusammengeschrieben habe, dass fast alle Funktionen 1:1 abgebildet werden, gleichzeitig aber abstrakt genug, dass ich mich nicht um gerätespezifischen Kleinkram kümmern musste
• die Klasse SmartDeviceEntity wird einen akzeptablen Anteil der Arbeit verursachen, weil die Routinen zur Kommunikation nach Seriell und Netzwerk getrennt modular aufgebaut sind, aber von der Klasse äußerlich unterschiedslos bedient werden. Die eigentlichen Kommunikationsroutinen können zu großen Teilen wiederverwendet werden aus anderen Plugins; aufgrund der vereinfachten Datenverarbeitung aber deutlich vereinfacht
• die Klasse SmartDeviceProtocol wird - zusammen mit der Konfigurationsdatei - wahrscheinlich in Konzept und Umsetzung die meiste Arbeit machen, ist dafür aber flexibel und erweiterbar, da jedes auf SDP basierende Plugin seine eigenen Definitionen mitbringen und einbringen kann.

Ob es sich lohnt, bestehende Plugins umzuschreiben, glaube ich erstmal nicht; der Sprung ist noch größer als von "klassischen" zu SmartPlugins. Aber wer sich mit neuen Geräte oder "von Grund auf" mit vorhandenen Plugins auseinander setzen will, kann viel Arbeit sparen, denke ich.

So, wenn ihr bis hierher folgen konntet, dann würde ich mich über Feedback, Kritik, Zuarbeit oder wasauchimmer freuen

Das Repo ist hier: https://github.com/Morg42/smartdevic...n/tree/develop

[Onkelandy]

Super Sache. Bin selbst zu wenig Entwickler, um bei der Struktur viel beitragen zu können. Aber ein bisschen testen und hacken gerne. Früher oder später würde ich mir die Arbeit schon antun, bestehende Plugins umzuschreiben

[bmx]

Im Prinzip keine schlechte Idee. Ich fürchte allerdings wir verzetteln uns und hängen selbst ambitionierte Nichtprogrammierer damit langsam ab weil keiner da mehr richtig durchsteigt.Wenn SHNG ein kommerzielles Produkt wäre läge die Sache wohl anders. Solange wir es aber nicht einmal hinbekommen alle Pluginersteller/Maintainer dazu zu bringen ihre Plugins stubenrein zu bekommen und z.B. die Sache mit der plugin.yaml sauber zu implementieren sehe ich da schwarz.

[Morg]

Ich kann da im Moment nur für mich sprechen - wenn ich ein Plugin "ans Laufen" bekommen habe, und es tut, was es soll, bekommt ich hier teilweise auch länger gar nicht mit, was oder ob hier passiert. Für viele ist das ja auch ein "wenn es läuft, will ich nix mehr davon sehen". Solche "Maintainer" wirst du natürlich nur schwer zur aktiveren Mitarbeit bekommen.

Auf der anderen Seite gibt es immer wieder Anfragen, ob denn ein Gerät xy unterstützt wird. Wenn ich mich weiter um diese "Vorlagenklasse" kümmere, würden sicher auch lauffähige Beispiele mit entsprechenden Beschreibungen rausfallen, das gehört für mich dazu. Ob sich jemand findet, der das als Neueinsteiger nutzen will, kann ich schlecht beurteilen.

Bis jetzt ist das alles noch im vertretbaren Rahmen gewesen. Wenn ich die Rückmeldung bekomme, dass niemand sowas braucht, stecke ich da auch nix mehr rein; die Plugins, an denen ich beteiligt bin, laufen ja

Wenn da Interesse dran besteht, baue ich das soweit weiter aus, dass man besser verstehen kann, um was es geht. Ggf. würde ich sogar noch erläutern, was im "Hauptteil" passiert (auch wenn das eigentlich nur der Rahmen ist, und der Hauptteil jeweils neu geschrieben werden muss...

Grundsätzlich bin ich für jedes Feedback dankbar, auch euch beiden.

@Bernd: ich stehe nicht überall ausreichend im Stoff, aber wenn es "verwaiste" Plugins gibt, die man als reine Fleißarbeit stubenrein machen soll, dann gib mir mal ein paar Namen. Zeit habe ich momentag genug, und das Wetter soll auch wieder schlechter werden

[bmx]

Morg Siehe z.B. Plugin Issue #345 oder auch Issue #230.

Im Unterverzeichnis tools findet sich plugin_metadata_checker.py. Damit kann man die plugin.yaml der einzelnen Plugins prüfen. Das ist wichtig, damit die Plugins über die Admin GUI konfiguriert werden können.

Ich habe einige Plugins zu SmartPlugins umgebaut und dort fehlen noch Implementationen für Webinterfaces.

[Onkelandy]

Ich denke, dass solch ein Ansatz sogar eher dazu führen könnte, dass neue Plugins oder Devices schneller, einfacher und sauberer integriert werden können, nicht?

Selbst hab ich jetzt schon eine Menge an Plugin durchgesehen und aufgepeppt - viele tun das Gleiche, aber keines tut es gleich

[Sisamiwe]

Hallo,

ich ich finde die Idee auch super. Ähnlich wie Onkelandy bin ich auch zu wenig SW-Entwickler, um bei der Struktur wirklich mitzuspielen.
Nichtsdestotrotz werfe ich mal das Modul in den Ring. Könnte man den Kern nicht auch als Modul abbilden, so dass Plugins das nutzen können? Vorbild wäre das MQTT Modul.

Zum Thema Komplexität: Das AVM Plugin ist so ein Beispiel, das zumindest für mich ziemlich komplex ist. Hier steht auch Arbeit an, um auf das AHA HTTP Interface zu wechseln.

hängen selbst ambitionierte Nichtprogrammierer damit langsam ab weil keiner da mehr richtig durchsteigt.

Ich selbst nutze das das Viessmann Plugin und das Smlx. Unterstützen tue ich gern.

Michael

[Morg]

Michael, ich kann nur raten, was du meinst:

den "Kern", also das Gerüst der Pluginklasse in ein Modul auslagern? Das geht mMn nicht, weil das die eigentliche Funktionalität des Plugins darstellt - aber dafür brauchst du auch kein Modul. Das Ding hier ist ja kein Beispielplugin, sondern eine Klasse. Du machst eine neue Klasse auf Basis von dieser hier auf, und das gesamte Gerüst ist fertig. Da musst du nichts programmieren, einstellen oder anpassen.

Was du tun musst, ist, die ganzen Konvertierungsroutinen und die Datenmatrix (bei dir: commands.py) schreiben, außerdem den Code für serielle oder Netzwerkverbindungen. Den kann man sich aber aus anderen Plugins holen, und dafür würde ich Beispiele dazu packen.

Oder verstehe ich jetzt an dir vorbei?

Das Modul (zB MQTT) wäre für ein anderes Protokoll - enOcean, ZigBee oder so - sicher super, aber das Plugin müsstest du immer noch selbst schreiben. Das will ich den Leuten ja - teilweise - abnehmen (wenn sie sich drauf einlassen wollen )

[Sisamiwe]

Oder verstehe ich jetzt an dir vorbei?

Richtig geraten. Aber ich verstehe, dass mein Gedanke falsch war. Hab also noch viel zu lernen.

Ich schaue mir bei Gelegenheit mal das Repo an, vielleicht verstehe ich das dann besser.

[Morg]

Dir wird die Struktur wahrscheinlich bekannt vorkommen aber in den Details habe ich viel generalisiert