Hallo liebe FHEM Freunde,
nachdem ich mich jetzt einige Zeit mit FHEM beschäftigt habe ist mir aufgefallen, dass bei den drei Modulen die ich verwenden wollte die Bedienung, die Anzeige und die Art wie ein und die selbe Funktionalität (ein, aus, toggle und Anzeige aktueller Wert) im Modul aufgerufen werden unterschiedlich sind. (Digital OUT, schaltbare Steckdose USB/LAN)
Hinweis an Modulentwickler: Dies bitte nicht als Kritik sondern als Hinweis auffassen. Ich erwarte auch keine Änderung an den Modulen. Ich sehe mich selbst als Freund von FHEM und finde es beeindruckend wieviele unterschiedliche Systeme eingebunden sind.
Das führt bei mir zu einiger Verwirrung und erschwert mir das Verständnis für FHEM.
Gut, das kann natürlich auch mehr über mich als über FHEM aussagen.
Deshalb folgende Idee:
ZitatLogische Devices durch verschiedene physikalische Devices nutzen
Warum komme ich darauf?
Als "Endnutzer (TBD)" erwarte ich, dass Funktionen einheitlich mittels FHEM angezeigt und bedient werden können auch wenn es Schaltsteckdosen von unterschiedlichen Herstellern sind. (Ja, bei den Geräten kann auch der aktuelle Status abgefragt werden)
Aktuell vermisse ich diese Einheitlichkeit bei FHEM. Ihr dürft gerne mit mir darüber diskutieren falls Euch danach ist.
Als "Modul Entwickler (TBD)" möchte ich mich nicht um die Visualisierung meiner Devices kümmern müssen. Zumindest nicht solange diese in eine bereits bestehend Klasse passen. Dies ist bei Schaltsteckdosen, behaupte ich mal, der Fall.
Ich möchte mich um die benötigten Daten und die Übergabe von und zu FHEM kümmern. Ich möchte zudem auch möglichst einfach finden, was FHEM benötigt. Da, wie so oft bereits im Forum betont, die Zeit für Dokumentation sehr knapp ist.
Für die "Core Entwickler (TBD)" hätte es evtl. den Vorteil, dass die Strukturierung etwas übersichtlicher werden könnte, da es die Wiederverwendung fördert.
Soweit ich FHEM bis jetzt verstanden habe sollte noch nichts gegen die Wiederverwendung logischer Devices durch verschiedene physikalische Devices sprechen.
Gibt es vielleicht bereits Beispiele bei den das bereits implementiert ist?
Ich denke dabei an eine Wohnung mit mehreren CUL, CUN, COZ.
Bei den von mir untersuchten Modulen war das allerdings noch nicht der Fall.
Noch bin ich nicht soweit, dass ich dies implementieren könnte aber mich würde schon Eure Meinung dazu interessieren wie diese Vereinheitlichung umgesetzt werden kann. Vielleicht gibt's ja auch eine viel einfachere Lösung, die ich nur noch nicht gesehen habe.
Ich weiss nicht genau, was Du moechtest, deswegen rate ich:
- "Wiederverwendung logischer Devices durch unterschiedliche phys. Devices": das geht, und wird praktiziert, siehe FHZ/CUL/RFR/FHEM2FHEM -> FS20/CUL_EM/CUL_WS oder HMLAN/CUL->CUL_HM. Hier gibt es zwar auch Sachen zu verbessern (z.Bsp ist das HomeMatic Modul nicht FHEM2FHEM:RAW faehig), dies sind aber nicht prinzipieller Natur.
- Einheitliche Befehle fuer bestimmte Geraeteklassen. Das hat aber mit dem Titel mAn nichts zu tun, und laeuft bei mir unter dem "Interface-Spezifikation" Stichwort. Darueber hatten wir auch laengere Diskussionen vor paar Jahren, die in einem auf dem Wiki dokumentierten Entwurf muendeten, leider fehlt es vielen Modulentwicklern (mir auch) an dem Umsetzungswillen, z.Zt. ist das nur teilweise implementiert. Es gab damals unterschiedliche Meinungen, ob diese Schnittstellen von den Modulen explizit mit einem Interface-Mechanismus zugesichert werden soll, oder nur implizit, indem man bestimmte (die im wiki dokumentierten) Befehle/Readings/Attribute anbietet.
Das was ich implementiere, arbeitet nach dem letzten Prinzip: wenn z.Bsp. ein Modul on und off anbietet, dann bewirkt im FHEMWEB ein click auf dem Status-Icon automatisch ein toggle, wenn es ein "desired-temp" anbietet, dann wird ein dropdown zum Einstellen der Temperatur angeboten, usw.
Zitat von: rudolfkoenig am 31 Oktober 2013, 09:05:10
Ich weiss nicht genau, was Du moechtest, deswegen rate ich:
Du darfst auch gerne fragen!
Vereinfacht gesagt MeinNeuesPhysDevice verwendet LogischesDeviceSchalter. EinAnderesNeuesPhysDevices verwendet auch LogischesDeviceSchalter obwohl beide auf unterschiedlichen Protokollen aufsetzen.
Weiter gesponnen könnte dann auch, bei entsprechender Umprogrammierung des CUL Moduls, auch CUL das LogischesDeviceSchalter verwenden. (Ich weiss, das wird nie passieren.)
Irgendwie habe ich immer noch die Vorteile von Kapselung und Wiederverwendung im Hinterkopf und gebe die Hoffnung nicht auf, dass dadurch die Modulentwicklung etwas vereinfachen werden könnte.
Ergänzung:
Ich lese mir nochmals die
http://fhemwiki.de/wiki/DevelopmentInterfaces
durch.
Ich versuche es nochmal anders, da ich auch nach lesen des wikis noch nicht schlau bin (liegt natürlich an mir).
Es geht vereinfacht gesagt darum zwei unterschiedliche Systeme in FHEM einzubinden.
Um es einfach zu halten soll es erstmal nur um Schaltsteckdosen gehen.
Beide Protokolle liefern den aktuellen Schaltstatus der Steckdosen, sonst soll erstmal nur ein-/ausschalten gehen.
Beispiel:
10_CBR_EINS.pm (Zugriff über externes Programm) und 10_CBR_ZWEI.pm (Zugriff über TTY) sollen den Zugriff für die zwei System enthalten.
1. Frage:
Wäre es möglich, im Sinne der Wiederverwendung, dass beide Module auf das Schaltdosenmodul 70_CBR_SCHALTER.pm zugreifen?
$hash->{Clients} = ":CBR_SCHALTER:"; wäre bei den 10_CBR_*.pm Modulen identisch.
2. Frage:
Wäre es möglich das Schaltdosenmodul so zu schreiben, dass ohne Änderung an 70_CBR_SCHALTER.pm ein drittes Protokoll über 12_CBR_DREI implementiert werden kann und dieses auch das $hash->{Clients} = ":CBR_SCHALTER:"; verwendet?
3. Frage:
Funktioniert das bereits jetzt mit dem FHEM switch interface?
4. Frage:
Darf ich weitere Fragen stellen?
Hinweis:
Ja, ich weiss das steht alles im Code aber ich bin nicht wenig eigennützig und möchte kein Reverseengineering von FHEM betreiben müssen nur um ein Modul zu erstellen.