Naming Brainstorming für Module (und Modulhierarchie)

RichardCZ · 14 April 2020, 19:37:15

Und die Probleme mit 1) - Hierarchie - sind eben:

* sinnvoll Hypernym -> Hyponym
* kurze aber prägnante Bezeichner
* Klassifizierung

Hinsichtlich Klassifizierung gibt er ja das alte Problem:

Multimedia::AVR
Multimedia::TV

So. Was macht man nun mit Fernsehern, die einen DVR eingebaut haben?

Multimedia::Combo?

oder belässt man die unter Multimedia::TV, nur haben die eben ein "Feature X" - was AVRs halt auch haben? Das ist etwas wo ich ein paar Koprozessoren gebrauchen könnte.

Beta-User · 14 April 2020, 20:14:44

Na ja, unter technischen Gesichtspunkten ist ggf. Bosch - Geschirrspüler näher an dem Mower oder dem Rauchmelder aus demselben Hause als an einem von Xiaomi mit BT- oder WLAN-Schnittstelle.

Wenn man das unter Code-Synergieeffekten ansieht, kommt vielleicht irgendeine Art Matrix-Denke raus. Was "klassische" HA-Hardware angeht (CUL_HM, HMCCU.*, ZWave, KNX, MySensors, HUE/Zigbee, EnOcean), sind jedenfalls die Geräte innerhalb einer Familie näher beieinander als verschiedene Geräte mit dem selben Zweck unterschiedlicher Basistechnik... (schon ein BT-Thermostat aus dem Hause eQ3 tickt anders als eines in HM-classic, und das ist wieder was anderes als MAX oder ein ZWave-eurotronic-spirit, der wieder anders funktioniert wie ein zigbee-eurotronic spirit)

Eventuell würde man sowas wie eine HAL-Ecke brauchen, aber die meisten zweistufigen Module sind grade eine Art HardwareAbstractionLayer, und die Unterschiede zu anderen Modulen haben mMn. meist technische Gründe.

Ansonsten: wir haben ja schon Schwierigkeiten "battery" einheitlich zu interpretieren... Unterschiedliche Funktionalitäten ergeben dann voraussichtlich genau das, was wir jetzt haben: eine große Unübersichtlichkeit. Aber immerhin: es geht, aber der user muß entsprechend viel kofigurieren/beachten, und es gibt gewisse Versuche, wenigstens ein bisschen Einheitlichkeit herzustellen (weekprofile, z.B.).

RichardCZ · 14 April 2020, 20:44:51

Könnten wir diesen Thread irgendwohin verschieben wo auch Nicht-Entwickler was sagen können?

Mich erreichen PMs von Leuten, die aus Benutzersicht was dazu sagen möchten und die können hier nicht schreiben. War von mir vmtl. zu kurz gedacht das hier zu plazieren.

CoolTux · 14 April 2020, 20:59:31

Du bist TE also einfach unten links auf Thema verschieben gehen

KernSani · 14 April 2020, 21:05:01

Zitat von: RichardCZ am 14 April 2020, 20:44:51
Könnten wir diesen Thread irgendwohin verschieben wo auch Nicht-Entwickler was sagen können?

Mich erreichen PMs von Leuten, die aus Benutzersicht was dazu sagen möchten und die können hier nicht schreiben. War von mir vmtl. zu kurz gedacht das hier zu plazieren.

Wo wir wieder beim Thema ,,Zielsetzung" wären. Geht es hier um eine technische Modularisierung, die einen hohen Grad von Wiederverwendbarkeit ermöglicht (die der Anwender aber überhaupt nicht zu sehen bekommen muss) oder um eine leichtere Auffindbarkeit für den Anwender. Das sind aus meiner Sicht zwei paar Schuhe, die auch getrennt von einander behandelt werden sollten.

Edit: Und ein dritter Punkt wäre dann Standardisierung von Geräteklassen (oder auch nur einzelnen Readings - siehe battery reading Beispiel von Betauser)

RichardCZ · 14 April 2020, 21:18:46

Zitat von: CoolTux am 14 April 2020, 20:59:31
Du bist TE also einfach unten links auf Thema verschieben gehen

Schon, aber a) frage ich mal ob EInwände sind, b) ... ich weiß nicht wohin. Wunschliste? FHEM/Sonstiges?

CoolTux · 14 April 2020, 21:57:51

FHEM Sonstiges klingt Sinnvoll.

RichardCZ · 14 April 2020, 22:37:02

Zitat von: KernSani am 14 April 2020, 21:05:01
Wo wir wieder beim Thema ,,Zielsetzung" wären. Geht es hier um eine technische Modularisierung, die einen hohen Grad von Wiederverwendbarkeit ermöglicht (die der Anwender aber überhaupt nicht zu sehen bekommen muss) oder um eine leichtere Auffindbarkeit für den Anwender. Das sind aus meiner Sicht zwei paar Schuhe, die auch getrennt von einander behandelt werden sollten.
Edit: Und ein dritter Punkt wäre dann Standardisierung von Geräteklassen (oder auch nur einzelnen Readings - siehe battery reading Beispiel von Betauser)

Aus meiner (persönlichen) Sicht, muss ich das alles erstmal auf die Reihe bekommen und ich traue mich momentan nicht zu sagen was von was getrennt gehört. Daher Brainstorming, ergebnisoffen. Denn ehrlich gesagt glaube ich, dass eine Modulhierarchie, bzw. Hierarchien (mehrere Bäume) zu der wir hier nach mehreren Iterationen kommen sollten, sich von dem was vielleicht beim Endbenutzer an Intuition vorliegt nicht komplett unterscheidet.

Ich weiß nicht wie es bei euch ist, aber ich brauche für einen guten Entwurf erstmal viele Daten und Erfahrungswerte. Oft habe ich hier bereits gehört, dass das was an Hardware bei den FHEM Nutzern vorliegt - und die Kombinatorik in der es vorliegt - einen ungeheueren Erfahrungsschatz darstellt. Meine Hoffnung wäre daher, dass während wir uns zu einer Klassifizierung, Hierarchie und Nomenklatur vortasten, ab und zu jemand aufschlägt und

"Möööp! Ne ... das ist so und so." einwirft. Naja und dann geht's halt in die nächste Iteration. Bis wir entweder am Schluss alle angeödet sind, oder sich das Gefühl breitmacht: "Jetzt ist es richtig".

Meine zweite Iteration. Devices fehlen noch komplett wie man sieht. Davor habe ich Angst.

$ lstree2
.
+- Control
+- Device
+- System
`- Topic
+- Environ
| +- Air
| +- Humidity
| +- Light
| `- Temp
+- Multimedia
+- Resource
| +- Energy
| | +- Heat
| | `- Power
| `- Water
+- Safety
+- Security
+- Service
`- UI

Eisix · 15 April 2020, 00:36:00

Hallo,

da ich wohl der Auslöser für die Verschiebung war will ich euch meinen Brainstorm nicht vorenthalten.

Aus mehr oder weniger Endnutzer-Sicht denke ich das eine Ordnung über das Protokoll mit dem das entsprechende Gerät kommuniziert am meisten Sinn macht.
zB.:
Protokollart-->Verbindungslayer-->Endgerät

FUNK-->ZWAVE-->Sensor
ENOCEAN-->Aktor

Netzwerk-->MQTT-->Tasmota
HTTPMOD-->Internetseite
AMAD-->Amad-SW
DLNA-->DLNA-client
UNIFI-->Switch
-->USG
-->AP

Ob das die besten und richtigen Namen für die einzelnen Sachen sind muss halt festgelegt werden.
Der naive Traum ist das jeweils die Schnittstellen definiert sind und wenn z.B. ein neuer Stereoreceiver kommt zumindest die Standardfunktionalität wie ein/aus, lauter/leiser, ... schon da ist und bei Bedarf nur der Verbindungslayer neu gemacht werden muss falls sich ein Hersteller mal wieder ein neues Protokoll ausdenkt.
Unifi is denke ich auch ein ganz gutes Beispiel, die Daten werden soweit ich weiß vom Modul Unifi über HTTPMOD geholt und dann an das Untermodul switch weitergeleitet/abgeholt welches dann das Endgerät darstellt. Wenn man es jetzt auf die Spitze treiben wollte würde dieses Untermodul switch auch mit einem Verbindungslayer Netgear zusammen arbeiten.

Wenn die Schnittstelle Verbindungslayer --> Endgerät hinreichend genau definiert ist wie z.B. bei DLNA (Modul DLNArenderer) --> DLNA-client oder MQTT --> Tasmota werden die Endgeräte automatisch in Fhem angelegt.

Ich denke das ist nah genug an der jetzigen Struktur und von der Wiederverwendbarkeit sollten auf jeden Fall die entsprechenden Verbindungsprotokolle abgedeckt sein.

So das war genug Storm für mein Brain

Gruß
Eisix

RichardCZ · 15 April 2020, 10:56:55

Naja - nur ein wenig.
Ich muss definitiv dieses Protokoll vs. Hersteller a.k.a. baugleiche/kompatible auf die Reihe bekommen.

Heute war das Kaninchenloch
https://www.e-sensorix.com/de/ecometer-s-ultraschall-fuellstandsanzeige-zisterne
versus
44_TEK603.pm

dran. Ohne Forum keine Chance. Das sollte besser werden.

Wuppi68 · 15 April 2020, 12:27:54

hmmm,

echt coole Idee

Mein bescheidener Vorschlag sich an dem OSI Modell https://de.wikipedia.org/wiki/OSI-Modell zu halten

also die verschiedenen Layer nutzen

damit wäre dann der Part Kommunikation erledigt - zwar "etwas" Overhead, könnte aber langfristig merklich Vorteile bieten.

Als Konsequenz wären die Endgeräte quasi von der Kommunikation befreit und würden nur noch "Funktionen" anbieten...

Da es ja mittlerweile alle Möglichen Kombinationen von Geräten gibt, wäre da ein "Tagging" von den entsprechenden Eigenschaften imho eine möglich Lösung...
z.b:
deviceName: Eierlegende Wollmichsau mit Solarantrieb für die absolute Dunkelheit
Protocols: bidcos zigbee3.0 mqtt ...
Characteristics: getEier getWolle getMilch getKoteletts setAntrieb getSpecial setSpecial
tbc (to be continued)

Shadow3561 · 15 April 2020, 20:10:20

Ich möchte auch etwas dazu beitragen, auch wenn es nur Bedenken sind.

Fronius.....

Es gibt unterschiedliche Herangehensweisen im Forum einen Fronius WR auszulesen (HTTPMOD oder MODBUS).
Daher sehe ich Fronius nicht unter Protocol, eher unter Topic -> Resource -> Energy
Dort dann eingeteilt in Inverter und Meter.
Wo aber steckt man dann aber den Speicher hin? Dieser ist von LG oder BYD, die benötigten Daten werden aber vom Fronius WR mit an FHEM übertragen?

Es gibt von Fronius zwar noch andere Geräte (Schweisstechnik), aber die bindet man wohl eher nicht in FHEM ein.

KNX.....

KNX kann man wohl als Protocol verstehen, dieser BusTyp deckt jedoch so ziemlich alles an Geräten ab die in einem halbwegs intelligenten Haus zu finden sind.
Licht, Rollos, Heizung, Klima, Lüftersteuerung, Wettersensoren/Stationen, andere Sensorien und Alarm um nur einige zu nennen.

Somit wäre KNX dann unter fast jeder Topic zu finden und wahrscheinlich auch unter Safety Security und Service.

KNX war übrigens bei mir der Grund zu FHEM zu kommen. Eine Visu ala Gira Homeserver incl. mehrere Bedientableaus sind einfach viel zu teuer.
Mittlerweile weiss ich auch, dass ich die Logikmodule zu teuer erkauft habe, denn das kann FHEM mit ein wenig Fleissarbeit auch besser.

Auch wenn ich nur Perl Laie bin und die Arbeit höchstwahrscheinlich unterschätze,
wäre es m.M.n. sinnvoll Module wie KNX oder Fronius nach folgender Logik zu trennen.

| +-Grundmodul PV
| +- Fronius
| +- Kommunikationsweg
| - Meter
| - Inverter
| - Akku
| - usw.

| +- SMA
| +- Kommunikationsweg
| - Meter
| - Inverter
| - Akku
| - usw.

- Grundmodul KNX
| +- Licht
| - Dimmer
| - Schalter
| - RGBWW
| +- Heizen/Kühlen
| - Wärme
| - Lüften
| - Klima
| +- Sensoren
| +- usw.

Gut Möglich, dass ich mit meinen Gedanken völlig auf dem Holzweg bin, so macht es aber für mich als Endanwender zumindest einen überblickbaren Eindruck und für den kleinen Modulschreiber in mir wäre es der Horror.

Sidey · 15 April 2020, 22:47:27

Ich habe mir die Idee gerade durchgelesen. Bin durchaus angetan von einer Struktur. Finde ich gut.
Allerdings würde ich das viel flacher angehen

In FHEM gibt es derzeit vier Klassen von Modulen, korrigiert mich, wenn es weitere gibt:

Hilfsmodule
Kommandos
Physische Module
Logische Module

Warum nicht erst mal nur damit anfangen. Wenns darunter dann weitere Verästelungen benötigt wachsen die schon von alleine.
Das ganze nach Hersteller, Protokoll, Empfangsgerät aufzudröseln führt unweigerlich wieder zu neuen Problemen.

Ich habe es bei dem Logischen Modulen für Sensoren, die unter anderem durch einen SIGNALduino empfangen werden können, direkt aufgeben Produktnamen in den Modulnamen zu verwursten. Da gibt es ständig sehr ähnliche Sensoren mit neuem Namen.
Da haben wir eher so Abkürzungen wie "Bell" für Klingeln oder SD für SensorDevice verwendet. Wenn sich für jemand der Bedarf ergibt, z.B. ein Modul aufzuteilen in dem 10 Funkklingeln verarbeitet werden, dann kann er das doch jederzeit unter den Logischen Modulen dann noch anlegen und einen Ast wie Beispielweise Bell::DeviceA, Bell::DeviceB anlegen. Wenn es das gibt, wird sich der Nächste vermutlich auch unter Bell sein Modul mit einchecken.

Super Beispiel ist auch das IT Modul. Das kann alle möglichen Funksteckdosen, die eine der verdächtigen Chipsätze verwenden.
Wenn jemand den Chipsatz in seine Funkklingel eingebaut hat, dann ist es auf einmal eine IT Definition und taucht nicht unter Bell auf. Die eigentliche Funktion kann sich der Anwender dann aber dennoch in FHEM einbauen.

Genauso auch die ganzen Logischen Module die CUL oder TRX in den Namen verpasst bekommen haben. Die sind doch nicht wirklich auf das physische Empfangsgerät beschränkt, das haben wir doch nur teilweise so eingebaut

Also vielleicht eher da ganze erst mal einfach und offen halten ?

Grüße Sidey

Eisix · 16 April 2020, 10:42:15

Hallo,

versuche mal meinen Vorschlag am Beispiel von Shadow3561 zu erklären, wobei ich nicht weiß wie Fronius und SMA kommunizieren (vermute da ist auch httpmod im Spiel, ich nehme hier aber an es wären proprietäre Protokolle).

Zitat
| +-Grundmodul PV
| +- Fronius
| +- Kommunikationsweg
| - Meter
| - Inverter
| - Akku
| - usw.

| +- SMA
| +- Kommunikationsweg
| - Meter
| - Inverter
| - Akku
| - usw.

Zitat
Ich habe es bei dem Logischen Modulen für Sensoren, die unter anderem durch einen SIGNALduino empfangen werden können, direkt aufgeben Produktnamen in den Modulnamen zu verwursten. Da gibt es ständig sehr ähnliche Sensoren mit neuem Namen.
Da haben wir eher so Abkürzungen wie "Bell" für Klingeln oder SD für SensorDevice verwendet. Wenn sich für jemand der Bedarf ergibt, z.B. ein Modul aufzuteilen in dem 10 Funkklingeln verarbeitet werden, dann kann er das doch jederzeit unter den Logischen Modulen dann noch anlegen und einen Ast wie Beispielweise Bell::DeviceA, Bell::DeviceB anlegen. Wenn es das gibt, wird sich der Nächste vermutlich auch unter Bell sein Modul mit einchecken.

Konstruiere mal ein Beispiel:
Wenn jetzt Fronius beschließt eine Klingel in Ihren Inverter einzubauen dann müßte das Fronius Modul zusätzlich auch noch die Klingeldaten für das schon vorhandene Endgerät (Bell) bereitstellen.

Frage mich ob man da überhaupt noch nach Protokollart sortieren sollte, da es eigentlich nur eine logische Sortierung ist. Der Hauptunterschied zu den jetzigen Modulen ist das Verbindung und Funktion getrennt wird, so wie es jetzt eigentlich bei MQTT schon ist, nur das da keine Standart-Endgeräte da sind (wobei die templates schon sehr nah dran sind).

Gruß
Eisix

Christoph Morrison · 16 April 2020, 11:13:30

Ich lasse mal meinen Gedanken freien Lauf:

- Meine FHEM-Devices sind - in den meisten Fällen - reale Geräte, z.B. eine Alexa, ein Fensterkontakt oder ein Schaltaktor. Ein (oder mehrere) FHEM-Device(s) referenziert ein reales Device, z.B. WZ_Fenster_Rechts_Kontakt einen Fensterkontakt.
- Die andere Kategorie sind Datenquellen, z.B. Buienradar, Tankerkönig oder die ODL-Daten
- Ich fände es charmant, wenn ich z.B. ein Fenster definieren würde, dem ich Eigenschaften geben könnte, z.B. hat das Fenster einen Rollladen, einen Fensterkontakt, einen Griffsensor und eine Beleuchtung. Ich würde dem Fenster gerne sagen (lassen): Verblende dich. Und dann macht das Fenster, was auch immer es dafür tun muss. Ich glaube ich hätte gerne mehr "Smart" im "Home".
- Diese Items/Objekte können Unterobjekte sein, die wiederum Unterobjekte von einem Objekt sein können, usw. Sinngemäß: Haus, verblende dich → alle Rollläden fahren runter. Das haben wir aktuell mit Structures.
- Das wäre der eine Baum.

Den anderen Baum, den Gerätebereich, würde ich glaube ich so gestalten (alles Beispiele):

Code Auswählen

lib/Hardware/eq3/Homematic/BidCos/RF/$Device
lib/Hardware/eq3/Homematic/BidCos/Wired/$Device
lib/Hardware/eq3/Homematic/IP/RF/$Device
...
lib/Hardware/Amazon/Echo/$Device
...
lib/Services/Weather/Buienradar
lib/Services/Environment/ODL
...

Also allgemein lib/$TYPE/$VENDOR/$FAMILY/([$SUBBFAMILY/ ...])$DEVICE
So ungefähr hab ich auch aktuell meine Geräte taxonomiert (anhand der Räume).