Naming Brainstorming für Module (und Modulhierarchie)

[RichardCZ]

Ich bräuchte Hilfe, bzw. denke ich, dass mit kollektiver Anstrengung von Leuten die sich gut mit den verschiedenen Geräte-/Serviceklassen auskennen hier das Ergebnis besser wird.

Ziel ist (für mich, aber ich werde auch für FHEM einen Migrationspfad vorschlagen) von einer flachen NN_<Modulname>.pm "Hierarchie" zu einer

lib/Klasse/Unterklasse/... Hierarchie für die Module zu kommen. Siehe auch https://forum.fhem.de/index.php/topic,109522.msg1035912.html#msg1035912
wo man hoffentich sieht, dass so eine Modularität auch der Wiederverwendbarkeit von Code zugutekommt. Für künftige Modulentwicklung hätte das den Vorteil, dass man Module leichter und mächtiger zusammenstöpseln kann und vermutlich mit dem halben Codeumfang.

Bevor man aber soweit denken kann, muss erstmal eine vernünftige Klassifizierung und Hierarchie gefunden werden, und da wäre die FHEM Community Schwarmintelligenz gefragt:

Es gibt "Protokolle" (RS485, SNMP, ...) es gibt "Systeme" (Somfy, Sonos, HomeMatic) es gibt "Devices" physisch und virtuell, es gibt "Interfaces", "Agenten" (TelegramBot u.ä.) und vermutlich noch etliche andere. Das alles sitzt da wie ein verfilztes Wollknäuel - sowohl auf Festplatte wie auch in meinem Kopf.

Ein paar Sachen sind durch die Namensgebung relativ offensichtlich, wie z.B.

36_EleroDrive.pm 36_EleroStick.pm 36_EleroSwitch.pm

Elero.pm
Elero/Drive.pm
Elero/Stick.pm
Elero/Switch.pm

wobei ja die Hoffnung ist, dass man  in Elero.pm z.B. den Code unterbringt, der den Modulen in der Hierarchie gemeinsam ist und dort einfach nur als redundante Duplikate rumhängt.

Die Frage ist dann zum Beispiel: muss man Elero als hersteller, als Geräteklasse oder als sonst etwas anderes betrachten?

Macht es Sinn eine AV Klasse zu haben und dann

AV/YAMAHA/...
AV/ONKYO/...

Anstatt Top-Level nach Hersteller zu gehen. Ich frage ergebnisoffen, weil ich selbst in der Sache noch keine Klarheit habe und möchte jetzt nicht irgendwas im Elfenbeinturm entwerfen was komplett an der Realität vorbeigeht.

[Beta-User]

 

Das kommt mir - nur aus einem ganz anderen Blickwinkel - einigermaßen bekannt vor...

Weiß nicht, ob das jetzt wirklich weiterhilft, was ich hier zusammenschreibe:

Wir hatten vor einiger Zeit mal eine hübsche Diskussion um diesen Wiki-Artikel hier: https://wiki.fhem.de/wiki/System%C3%BCbersicht (https://forum.fhem.de/index.php/topic,101736.0.html). Wenn man sich das ansieht, wird einigermaßen schnell klar, dass du dir damit eine Herkulesaufgabe gestellt hast...

Es gibt Dinge, die (vermutlich) eng zusammengehören mit je einem Interface und dann einem oder mehreren "Client-Modul(en)" (Elero ist vermutlich sowas, MySensors jedenfalls ist sowas, aber auch da gibt es eine "RS485-Variante", die sich aber im Handling in FHEM nicht von einem anderen physischen Transport-Layern unterscheidet).

Bei "IT" (und anderen 433MHz-Protokollen, insbes. auch "Somfy") ist es so, dass wir mehrere Interfaces kennen (mind. CUL (incl. diverser Derivate...) und Signalduino), die aber in der Regel dieselben Client-Module bedienen.

"Homematic" ist noch "schillernder: Da gibt es 2 grundsätzlich unterschiedliche Interface-Familien (wenn man die RS485-"classic"-Variante dazunimmt sogar 3 (?)), die jeweils komplett andere Clients bedienen.

RS485 ist jedenfalls eher ein "Transport-Layer" denn ein (eigenes logisches) Protokoll.

MQTT2_DEVICE schließlich ist als Client-Modul mMn. so universell, dass man "eigentlich" jedes Interface "davorklemmen" könnte, wenn das die empfangenen Daten auf einen MQTT-Standard runterbricht (mit MYSENSORS_DEVICE wäre es btw. ähnlich, das kennt sogar standardisierte "Werteklassen", bei denen man direkt weiß, ob es sich um einen Temperaturwert oder eine Voltage handelt...

Bin mal gespannt, ob es dazu ein greifbares Ergebnis geben wird .
MMn. ist bei derartigen Operationen aber die Gefahr riesig, dass irgendwo eine wechselseitige Abhängigkeit übersehen wird, und ins Leere gehende Funktionsaufrufe sind nicht eben prickelnd, was das user-feedback angeht .

Gruß und viel Spaß beim Reinfuchsen in die ganzen Details,

Beta-User

[KernSani]

Hi Richard,

ich will nicht den Spielverderber spielen und auch nicht völlig ausschliessen, dass man in gewissen Bereichen auf eine eingeschränkte Hierarchie kommen könnte. Das Ganze konsequent und nachvollziehbar zu machen dürfte aber schwierig werden. Schon die Unterscheidung in Geräte- und Hilfsmodule in der Commandref ist m.E. teilweise nicht völlig trennscharf.
Nehmen wir als Beispiel die TRX*-Module, die ich geerbt habe. Damit können Geräte verschiedenster Hersteller, verschiedenster Geräteklassen gesteuert werden. Wesentlicher gemeinsamer Nenner ist, dass sie auf 433Mhz funken (und nichtmal das ist richtig - es gibt auch 866MHz TRXe, die sind aber meines Wissens kaum verbreitet). Die gleichen Geräte (oder zumindest ein Teil davon) kann aber auch mit einem Signalduino oder CUL o.ä. gesteuert werden, die völlig anders arbeiten. Damit wird eine "logische" Hierarchie schonmal quasi unmöglich (oder ich habe "Intertechno" als Kind von 27 Eltern). Jetzt könnte man noch auf eine technische Ebene gehen. Das wird heute schon beim zweistufigen Modell (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module) an vielen Stellen praktiziert, nur im Dateisystem (und natürlich im Namensraum, aber das ist ein anderes Thema) nicht hierarchisch abgebildet. (Ich kenne Elero nicht, nehme aber an, dass es sich dabei genau um so ein zweistufiges Modell handelt)
Sicher gibt es eine Menge redundanten Codings innerhalb der FHEM Module, dies lässt sich aber m.E. eher durch generische Libs (wir hatten es ja z.B. mal von der ganzen JSON-Bearbeitung) lösen, als durch deinen Vorschlag.

Grüße,

Oli     

[Wzut]

es gibt leider nicht nur zweistufige Module sondern wie bei MAX auch dreistufige ....
00_CUL empfängt das Funktelegramm und gibt es wenn es ein MAX Telegramm ist an 14_CUL_MAX weiter , 14_CUL_MAX verarbeitet es entweder selbst oder reicht es 10_MAX weiter. Der Rückweg erfolgt i.d.R dann auch über alle drei 10_MAX -> 14_CUL_MAX -> 00_CUL
Die Namensgebung eng am Hersteller hat IMHO schon den Vorteil leichter feststellen zu können ob es für meinen Haarschneider der Fa. Glatzkopf vllt. ein FHEM Modul namens 33_Glatzkopf gibt.   

[KernSani]

Ja, Namensgebung eng am Hersteller oder am Protokoll (z.B. MQTT) macht Sinn, allerdings wird's doof, wenn Fa. Rastalocke baugleiche Haarschneider herstellt Oder - wie ich gerade schmerzlich feststellen muss - ein Grünbeck SD 18 eine ganz andere Sprache spricht, als der SC 18...


Gesendet von iPhone mit Tapatalk

[RichardCZ]

Wie ich schrieb: ergebnisoffen.

Ob das Ergebnis nun ist

"Wir lassen's so wie es ist"
"Werden wir zumindest die Zahlen los"
"göttliche 1-Baum Hierarchie mit den abstraktesten der abstrakten Klassen. Sir!"
"mehrere Bäume-Hierarchie" (so wie in der Taxonomie)
...

bin ich schmerzfrei solange man am Ende der Diskussion der Ansicht sein kann, die Entscheidung ist begründet. Momentan sind wir noch nichtmal in der Diskussion, sondern im Brainstorming. Und die erste Regel des Brainstorming lautet: Es gibt keine schlechten Ideen.

Ich denke, ein Hauptproblem ist, dass sich nicht alles in starre Hierarchien zwängen lässt. So wie ich das sehe, haben die meisten Module eher sowas wie Attribute. Ohne vorgreifen zu wollen, würde ich momentan intuitiv sagen, dass eine Hierarchisierung nach Hersteller wohl eher nicht zu empfehlen ist.

Sonst hat man bei Samsung mal eben Schiffe neben Fernsehern. 

Ich könnte durchaus mit einer "multi-Baum" leben. TRX-Baum, HomeMatic-Baum ... und rein vom pragmatischen Ansatz her könnte (eher: müsste) man den Übergang ohnehin fliessend gestalten: sprich die einzelnen Bäume würden nach und nach aus der "flachen Ursuppe" der Module herauswachsen.

https://wiki.fhem.de/w/images/a/ab/System%C3%BCbersicht.png

Ist ziemlich hifreich. Unten rechts in der Legende sind ja mal so ganz abstrakte Klassen von Kommunikationswegen dargestellt. Könnten das nicht Basisklassen sein?

[RichardCZ]

Die Namensgebung eng am Hersteller hat IMHO schon den Vorteil leichter feststellen zu können ob es für meinen Haarschneider der Fa. Glatzkopf vllt. ein FHEM Modul namens 33_Glatzkopf gibt.

Woher weisst Du dann die 33? Und was machst Du wenn Fa. Glatzkopf neben Haarschneidern auch Sexpuppen herstellt? Da würde ich letztere schon lieber irgendwo im FHEM Rotlichtbezirk unter

Entertainment/Dolls/Glatzkopf/Turbo9000.pm
Entertainment/Dolls/RealDoll/Schatzi2.0.pm
...

sehen.

[Beta-User]

Ist ziemlich hifreich. Unten rechts in der Legende sind ja mal so ganz abstrakte Klassen von Kommunikationswegen dargestellt. Könnten das nicht Basisklassen sein?

...manche nennen es zurecht "überfrachtet" (aber mir ist bisher auch noch nichts besseres eingefallen)...

Das mit den "Basisklassen" kann man ggf. so sehen, aber das sind mMn. eher Unterscheidungen, die (vielleicht/offentlich) für Kaufentscheidungen eine Rolle spielen mögen, aber einen weiteren "Mehrwert" (im Sinne der Modulentwicklung) kann ich im Moment nicht erkennen, und auch der Transport-Layer "Kabel" oder "Luftschnittstelle" ist völlig sekundär. Darüber hinaus ist es (aus Modulsicht) fast egal, ob etwas unidirektional oder bidirektional ist (will sagen: der "Sendeoverhead" ist in der Regel beim Clientmodul gering, und der Hauptanteil liegt eher beim Codieren der zu sendenden Daten, oder?

Und dann gibt es ja eine ganze Reihe von Modulen, die nicht so richtig auf dem Schaubild zu finden sind (praktisch das ganze IP-Zeug ist irgendwo "in der Wolke", dto. für generische Dinge wie HTTPMOD&Co oder Messanger-Dienste).
Das "organisierte Chaos" spiegelt sich ja zum Teil auch in der Gliederung des Forums wieder...

Das war jetzt kein "dafür" oder "dagegen", ich mache grundsätzlich bei allem mit, was irgendwie Sinn macht - sei es aus Usersicht, sei es aus Entwicklersicht...

Aus Nutzersicht würde es eventuell Sinn machen, die Module anders präsentiert zu bekommen als Alphabetisch in den bekannten drei Kategorien. Im Sinne des Brainstormings sei mal eine "order"-Option in den Raum geworfen, wie wir sie von attrTemplate her teils kennen, das ganze hier aber dann ggf. mehrdimensional. Damit könnte man z.B. die 433-MHz-Geräte "zusammensortieren" - getrennt in Interface und Client, oder das, was zu CUL_HM gehört (aber dann wieder: nur das?!? Eher nicht, dann auch HMCCU.*). Kann sein, dass Meta teilweise was in die Richtung ermöglicht, aber eigentlich wäre sowas dann eher ein Thema für commandref-modular-2.

Woher weisst Du dann die 33?

Mwn ging es da "ganz früher" mal drum, die Ladereihenfolge beeinflussen zu können. Deswegen haben fast alle seriellen IO's die "00", und das "Logikzeug" kommt irgendwo hinten.
Ansonsten ist es schlicht ziemlich willkürlich und für den User schon gleich gar nicht irgendwo zu sehen...

[rudolfkoenig]

Mwn ging es da "ganz früher" mal drum, die Ladereihenfolge beeinflussen zu können.

ganz frueher ist noch nicht vorbei: $hash->{ORDER} (abgeleitet vom Nummer) im modul-Hash  bestimmt clientArray, und damit in welcher Reihenfolge die virtuellen Module benachrichtigt werden, wenn ein Paket von physischen Modul verarbeitet werden soll.

[nils_]

passt das zur Beschreibung/Erklärung im wiki?
https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Dateiname

Schlüsselnummer - Eine zweistellige Zahl zwischen 00 - 99. Die Schlüsselnummer hat aktuell keine technische Relevanz mehr. In früheren FHEM-Versionen ist sie relevant für zweistufige Module (Reihenfolge für Dispatch() um logische Module zu prüfen). .....

[Dr. Boris Neubert]

passt das zur Beschreibung/Erklärung im wiki?
https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Dateiname

Nee, das Wiki stimmt nicht.

[RichardCZ]

Ich hab' da mal was vorbereitet

$ lstree2 HoBo
HoBo
+- Module
|   +- Air
|   +- Control
|   +- Energy
|   +- Multimedia
|   +- Security
|   +- Service
|   +- UI
|   `- Water
`- System

Da eine strikte Hierarchie eh nicht möglich sein wird, und z.B. sowas wie

"Hauswasserwerk"
"Gartenbewässerung"
"Brunnensteuerung"
"..."

bei mir unter HoBo::Module::Water::* landet, aber man durchaus wird logische Cluster wie "Garden" haben wollen, wo außer Gartenbewässerung eben auch die Mähroboter (keine Ahnung ... HoBo::Module::Device::Bot::Lawn::*) sind, wird es eben auch solche Bundles/Cluster geben, die man sich aber zusammendefiniert - oder am besten "zusammenklickt".

Das wird sich noch alles sehr ändern und ich jongliere da noch rum im Kopf. Aber irgendwo muss man jemand ja anfangen.
zu dem zeitpunkt wo das jemand liest, hat sich das sicher schon geändert. 

[KernSani]

Ich hatte ursprünglich verstanden, dass du eine Modularität erreichen willst, die (u.a.) auch redundanten Code verhindern soll. Deine aktuelle Idee orientiert sich jetzt aber eher an einer Art logischer Geräteklassen o.ä. und das "Garden" Beispiel geht in Richtung Anwendungsbereich. Mir ist nicht ganz klar, was das Ziel der Hierarchisierung jetzt ist und was damit erreicht werden soll, kann. Was ich hier jetzt sehe, liese sich m.E. mit einem Tag-basiertem System (wie z.B. Meta/Installer) ganz gut abbilden (dann kann die Brunnensteuerung nämlich sowohl in "water" als auch in "Garden" eingeordnet werden und vielleicht zusätzlich auch noch bei "MQTT" etc...). Das ist aber eher eine Endanwender-Sicht, die möglicherweise ein gewisses Mass an technischer Modularisierung erfordert, aber nicht notwendigerweise zu besserem oder modularerem Code führt. Vielleicht können wir mal festlegen was die Ziele sind (und vielleicht auch klar abgrenzen, was man nicht damit erreichen will) und dann die Schwarmintelligenz darauf loslassen

[RichardCZ]

Ich hatte ursprünglich verstanden, dass du eine Modularität erreichen willst, die (u.a.) auch redundanten Code verhindern soll.

Ja, das ist ja weiterhin das Ziel:

Module::Device::Bot::Lawn::BoschXYZ.pm
Module::Device::Bot::Lawn::GardenaFoo.pm
Module::Device::Bot::Lawn::HusqvarnaBar.pm

könnten ja immer noch auf Gemeinsamen Code unter  Module::Device::Bot::Lawn.pm zurückgreifen. (Vmtl. fackelt man etliches auch durch Aliase ab, wenn baugleich)

Und ganz hart genommen sogar

Module::Device::Bot::Vacuum::iRobot::Dummbeutel.pm
Module::Device::Bot::Vacuum::LG::SuckOMat.pm

-> Module::Device::Bot::Vacuum.pm

und besagte *Bot::Lawn.pm und *Bot::Vacuum.pm eban auf *::Bot.pm

Deine aktuelle Idee orientiert sich jetzt aber eher an einer Art logischer Geräteklassen o.ä. und das "Garden" Beispiel geht in Richtung Anwendungsbereich.

Das kommt dazu. Sprich "Garden" ist ein Bundle aus diversen Dingen "Bewässerung (Modul XYZ)", "Rasenmäher (Modul ABC)", "Springbrunnen (Modul FGH)" ...

Vielleicht können wir mal festlegen was die Ziele sind (und vielleicht auch klar abgrenzen, was man nicht damit erreichen will) und dann die Schwarmintelligenz darauf loslassen

Ok. Es gibt zwei Zielsetzungen:

1) Logische Hierarchisierung zwecks Code-Wiederverwendbarkeit
2) Logische Clusterung zwecks intuitiver Usability

Ich hätte vielleicht 2) gar nicht erwähnen sollen um nicht zu verwirren, denn das wird vmtl. nur "ein Modul/Klasse" sein, wo dann Instanzen rauspurzeln: "Garten", "Wohnzimmer", "Garage" und die beinhalten Dinge, die irgendwo unter 1) in einer Hierarchie leben.

[igami]

Module::Device::Bot::Lawn::BoschXYZ.pm
Module::Device::Bot::Lawn::GardenaFoo.pm
Module::Device::Bot::Lawn::HusqvarnaBar.pm

könnten ja immer noch auf Gemeinsamen Code unter  Module::Device::Bot::Lawn.pm zurückgreifen. (Vmtl. fackelt man etliches auch durch Aliase ab, wenn baugleich)

Finde ich ganz schick, dann sehe ich als Anwender direkt was gibt es denn an Geräten.
Und da sie gleiche Codeteile verwenden sollte die Ansteuerung aus FHEM heraus keinen großen Unterschied machen.