Naming Brainstorming für Module (und Modulhierarchie)

[justme1968]

vielleicht wäre es sinnvoll die code organisation (widerverwendbarkeit hinsichtlich protokollen und logischen funktionen) auf der einen seite und die präsentation und auffindbarkeit zum endanwender auf der anderen seite nicht als identisch anzusehen.

zumindest letzteres wird mit einer mehr oder weniger starren hierarchie nicht funktionieren da es zu viele n:m beziehungen gibt. hier wäre ein tagging besser geeignet weil ein device so sehr einfach in mehrer auch orthogonale kategorien gehören kann. der fernseher von oben wäre also einfach beides: TV und DVR.

ein beispiel wie das mit dem tagging aus sicht eines anwenders aussehen könne habe ich hier: https://forum.fhem.de/index.php/topic,106528.msg1006445.html#msg1006445 am beispiel der commandref überarbeitung an der ich noch bin gezeigt.




@Eisix: meine netzwerk kategorie von oben schmeisst netzwerk basierte protokolle und die geräte der netzwerk infrastruktur in die gleiche überkategorie. das ist falsch.

[Eisix]

Ein Fernseher wäre für mich z.B.

  Verbindungslayer      -->         Endgerät
--------------------------------------------------
+- HTTPMOD                            |   - TV
+- DLNA                                  |   - DVD
                                               |   - DLNA-Client

Endgerät sollte vielleicht Funktion heißen. Also wäre der Fernseher die Summe der zur verfügung gestellten Funktionalitäten was im Grunde bedeutet Funktionalität ist eigentlich auch eine Art tagging.

Jetzt bin aber erst mal ruhig bevor die Programmierer hier die Hände über meinem Wolkenschloss zusammenschlagen.

Gruß
Eisix
                 

[Sidey]

ein beispiel wie das mit dem tagging aus sicht eines anwenders aussehen könne habe ich hier: https://forum.fhem.de/index.php/topic,106528.msg1006445.html#msg1006445 am beispiel der commandref überarbeitung an der ich noch bin gezeigt.

Das ist vermutlich für die Anwender Sicht die besser Idee.


Was das Aufteilen der Module auf Strukturen angeht, so bin ich noch mal in mich gegangen.
Mein Beispiel mit dem IT Modul und der Funkklingel, gibts in Echt sogar mit Motorleinwänden.
Das ist dann ein bisschen blöde, dass das IT Modul die Motorleinwand implementiert, weil die Befehle der Leinwand doch leicht abweichend sind.

Worauf ich damit hinaus will ist, die Zuordnung zu einer Strukur nach Funktion oder Gerätetyp passt aktuell nicht, weil der Code für beides in einem Modul steckt. Und wenn es darum geht doppelten Code zu reduzieren, dann könnte es vermutlich für die Struktur helfen, wenn der Code aufgeteilt wird.
Am Beispiel IT, Schaltsteckdose und Motorleinwand, wäre dann vielleicht ein Teil in einem "PT2262etc" Modul, was die Daten "versteht" und Module wie Schaltsteckdose und Motorleinwand würden dann die Darstellung aus dem "PT2262etc" Modul übernehmen.

Bei den Ganzen Modulen mit Wettersensoren würde das doch auch ganz gut klappen

Was dafür alles an Änderungen notwendig ist, darüber habe ich jetzt noch nicht mal Ansatzweise nachgedacht. Bestimmt eine ganze Menge
Ob wir dann davon was haben, naja vermutlich schon, weil die Präsentationsschicht entkoppelt wird. Heute wird das halt über die readinggroups oder auch dummys mit notifys realisiert. Geht so natürlich auch irgendwie

[Wuppi68]

das schöne an der Sache ist aber, das man es parallel dazu einfach machen kann

Eine "Basis§ wird erstellt und dann kommen die "Neuen" Devices dann in den Baum, also Alte und Neue Welt gleichzeitig. Wenn es perfekt läuft werden dann die alten Module auf die neue Struktur gebracht

[RichardCZ]

https://metacpan.org/pod/Moo#IMPORTED-SUBROUTINES

Moo - eine Perl-only Implementierung des Großteils von Moose. (Welches wiederum ein postmodernes OO System für Perl ist)

extends  - kann auf einer Basisklasse aufbauen
with - kann eine oder mehrere Rollen einer Klasse zuweisen
has - definiert Attribute

und noch ein paar mehr auf die ich jetzt nicht im Detail eingehen muss, aber im Grunde genommen hat das alles was man braucht um den bunten Zoo abzubilden mit dem wir es zu tun haben.

Perl-only bedeutet in diesem Fall ich kann das mit zum source packen, der User bekommt das mitgeliefert und muss weder CPAN, noch Distripaket (obwohl es das wohl bei den großen Distris gibt) machen, es wird kein Compiler etc. benötigt.

Damit kann man m.E. "next generation" Module machen, das sind IMHO die Bauteile für den Veyron, verglichen mit dem Golf I derzeit.
Aber der größte Witz an der Sache ist, dass man künftig Modulautoren nicht mehr Perl Können abverlangt, sondern weniger! De facto wird das auf 90% Parametrierung, 10% Programmierung hinauslaufen, wobei die Parametrierung ein einer deklarativen Syntax erfolgt:

package Multimedia::TV::Glotz9000;

extends 'Multimedia::TV';

has Nippel => (
  is => 'rw',
);

has Lasche => (
  is => 'rw',
);

etc.

Und wie Wuppi schon sagte, der Arm kann parallel wachsen (also was sowohl Struktur, wie auch Technologie betrifft) und muss das bestehende nicht stören. Man muss FHEM nicht von Grund auf neu implementieren. Man kommt auch inkrementell in die 30er des 21Jh.

[Beta-User]

Vielleicht hier etwas OT, aber thematisch paßt es aus Usersicht evtl. ganz gut rein:

Wir hatten grade das Thema "sinnvolle Namensgebung" bei Readings usw. rund um eine bestimmte Ladestation für E-Autos (go-echarger, diese Threads: MQTT-Weg  und spezielles Modul).

Was z.B. Multimedia-Geräte angeht, habe ich gestern erst wahrgenommen, dass es sowas für Multimedia schon gibt (https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV) und eben das hier gefunden: (https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings).

Das ist alles irgendwie noch nicht so richtig miteinander verknüpft und sehr bruchstückhaft...
Vielleicht mag sich jemand (oder eine Gruppe von Leuten) mal die Mühe machen, einen deutlich umfassenderen Vorschlag dazu zu erarbeiten bzw. das nach und nach erweitern? Das würde jedenfalls aus usersicht (und teils auch aus Ansteuerungssicht untereinander) m.E. einiges an verbessertem "Look and feel" bringen und wir würden nicht nachlaufend dann jeweils Reparaturen machen oder historische Zufälle zum Maß der Dinge machen...

[RichardCZ]

Das ist alles irgendwie noch nicht so richtig miteinander verknüpft und sehr bruchstückhaft...
Vielleicht mag sich jemand (oder eine Gruppe von Leuten) mal die Mühe machen, einen deutlich umfassenderen Vorschlag dazu zu erarbeiten bzw. das nach und nach erweitern?

Seit heute ist besagtes Moo Bestandteil des HoBo repository (einschliesslich ~7000 Tests) und während ich mich auf der stupiden Sisyphos Odyssee des Unit-Tests- Schreibens befinde, muss ich doch ab und an mal was anderes - anspruchsvolleres - machen.

Also habe ich mir überlegt wie man bestimmte Geräte, die FHEM heute schon unterstützt "zerstückeln" kann. Also woraus so ein "Samsung Fernseher" bzw. "Ethernet Sensorarray", bzw... "Fronius Symo" etc. besteht. Was sind deren "Komponenten", "Funktionen/Rollen", bzw. "(abstrakte) Basisklassen" (für die das gleiche gilt).

Wenn da jemand mitphilosophieren will, gerne.

[Sidey]

Hi,

Wie wäre es mit Aktoren und Sensoren?


Grüße Sidey

[Christoph Morrison]

Wie wäre es mit Aktoren und Sensoren?

Wo würdest du da eine Schaltsteckdose einsortieren, die auch Temperaturen / Leistung misst?

[Sidey]

Sowohl als Aktor und auch als Sensor?

Gesendet von meinem Moto Z (2) mit Tapatalk

[RichardCZ]

Wie wäre es mit Aktoren und Sensoren?

Meinst Du abstrakte, logische oder reale?

Auf der abstrakten Ebene sind beides die gleiche Komponente: Input->Output Transformation
Eingangsgröße -> Ausgangsgröße

Eingangsgröße: Wertebereich & Einheit
Ausgangsgröße: Wertebereich & EInheit
->: Mapping Funktion

nun kann man einen anstrakten Sensor zu einem logischen parametrieren
z.B. Eingangsgröße: (-50 bis +100  °C), Ausgangsgröße: (0 bis 5 V), -> ("Kennlinie")
Kennlinie laut Datenblatt oder Erfahrungswert oder Kalibrierung.

abstrakter Aktor, gleiches Spiel. parametriert dann (sagen wir Schrittmotor):
Eingangsgröße: (1 "Puls"), Ausgangsgröße: (0.1 ° Winkeländerung), -> (1:1)

Thema "Puls" ist nochmal ein Kapitel für sich.
Nun ist natürlich ein Aktor wie man ihn kennt "Rolladenmotor/steuerung" ein
Sammelsurium solcher Komponenten. Vermutlich:

* Motor
* Sensor(en) (Endbegrenzer, Pulszähler)
* Zustand (a.k.a. interner Speicher. Flip-Flops etc.) - andere Klasse.

Und der "Jalousienator Rollladen-Rolli 9000" hat dann noch andere Komponenten. Irgendwo muss ja ein Interfac sein über das man mit ihm (oder er mit einem) kommuniziert.



Ich habe doch dieses "Ethernet Thermometer". Aber eigentlich ist das ein Gerät welches über die folgenden Dinge verfügt:

2 x 1-Wire Ports (ich bin noch zu unbedarft was 1-Wire anbelangt, vermute das ist aber das was hier in "1-Wire" diskutiert wird)
1 x (logischen) Ethernet Port

"Ethernet Port" ist ein "IP-Netzwerkinterface"
Ebenso ist ein "WiFi Port" ein solches.

Die in Anführungszeichen genannten Dinge sind abstrakte Basisklassen. wobei "IP-netwerkinterface" basisklasse von "Ethernet Port" bzw. von "WiFi port" ist.
Und Ethernet Port wird dann zu einem "Fast-Ethernet port" (= 100MBit, FD, ...) parametriert. und als Instanz besagten Gerätes ... naja instantiiert.
Den ganzen Schlunz mit IP Adresse, Netzmaske, Gateway, ... hat es von der "IP Netzwerkinterface" Basisklasse geerbt.

Das Gerät hat als Rollen/Features einen eingebauten "Webserver" (Basisklasse) und "SNMP" (Basisklasse). Das kann ich dem Gerät nur deswegen zuordnen, weil es ein besagtes Netzwerkinterface hat.

Das Ziel wäre für mich, dass ein "Modulautor" künftig hergeht und so ein neues zu unterstützendes Gerät quasi aus dem vorhandenen Baukasten zusammensetzt und zu 90% fertig ist. Mit besserem/vollständigerem Support als das heute der Fall ist beim "copy&paste des nächstähnlichen". Naja ganz 100% wird das in den wenigsten Fällen gehen. Ich bin Pragmatiker genug um zu wissen, dass die Welt nicht so orthogonal ist.



Aber wenn ich dann meinen beschi* neuen Samsung TV derart konstruktiv zusammensetze, dann wird der einige dieser komponenten haben (u.a. ein WiFi Interface, s.o.), aber auch sowas wie ein Video-Display (welches dann Attribute der Auflösung etc. hat)

Mal schauen wie weit man das treiben kann. Aber wenn das gelingen sollte, wären wir - glaube ich - in einer anderen Liga. In unserer eigenen. 

[RichardCZ]

Wo würdest du da eine Schaltsteckdose einsortieren, die auch Temperaturen / Leistung misst?

s.o.

Wenn sie Leistung und Temperaturen misst, hat sie zwei logische Sensoren.
Wenn sie schaltet, mindestens einen Aktor (Wertebereich: an/aus)
Sie wird ja vermutlich noch irgendwo ein interface haben, sonst wäre sie für uns ja irrelevant.

Dann kommt es darauf an wann/warum sie schaltet. autark? von aussen?

Vermutlich wird man aber mit so ganz einfachen Komponenten anfangen müssen, bei denen die Dekonstruktion in logische Einheiten noch übersichtlich ist.

Ziel für den Endnutzer ist es aber diese ganze Komplexität überhaupt nicht zu sehen. Der weiß nur "Ich habe eine Schalti 2000" Steckdose, die gibt er ein (oder läst einen auto-discovery wizard laufen) und wenn die supported wird, wird die ziemlich gut supported - weil da ja eine tonne wiederverwendbarer Code mitwirkt. 

Ich weiß, das klingt alles noch wie Sci-Fi und da ist es auch noch eine Weile hin. Aber wenigstens wisst ihr was mich so antreibt.

[pejonp]

Hallo,

könnte man sich nicht an den Z-Wave Geräten orientieren. So was ich bis jetzt mitbekommen habe, unterstützen die Geräte, auch von verschiedenen Herstellen, bestimmte Funktionen:

Vision Security ZG8101 Garage Door Detector (http://devel.pepper1.net/zwavedb/device/340)

Code Auswählen Erweitern


classes BASIC ALARM ASSOCIATION BATTERY MANUFACTURER_SPECIFIC SENSOR_BINARY VERSION WAKE_UP

vclasses ALARM:2 ASSOCIATION:1 BATTERY:1 MANUFACTURER_SPECIFIC:1 SENSOR_BINARY:1 VERSION:1 WAKE_UP:2



Steckdose (http://devel.pepper1.net/zwavedb/device/361)

Code Auswählen Erweitern


classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION PROTECTION SWITCH_BINARY SWITCH_ALL METER ALARM ASSOCIATION INDICATOR

vclasses ALARM:3 ASSOCIATION:1 CONFIGURATION:1 INDICATOR:1 MANUFACTURER_SPECIFIC:2 METER:2 PROTECTION:2 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:1


pejonp