Neue Module: Designfragen

[UliM]

Hallo,
gerade bastele ich an zwei neuen Modulen und hätte gern eure Meinung zu einigen Design-Aspekten.


Ein Modul dienst zur Steuerung eines SamsungTV über Netzwerk.

1. Modulerweiterung vs neues Modul
Es gibt bereits ein Modul STV (Samsung-TV), das jedoch nur für ältere SamsungTV-Modelle funktioniert.
Im Forum ist ein script aufgetaucht, mit man auch (bzw nur?) neuere Modelle steuern kann. Daraus hab ich ein einfaches Modul gemacht.
Mit dem Autor des bisherigen Moduls hab ich Kontakt aufgenommen, er hätte nix gegen eine Kombination, man könnte die bisherige Version und die Neue über Parameter o.ä. auseinenadersteuern.
Allerdings braucht das neuere Script mehr Parameter.
Also bei Anlegen eines neuen Moduls gäbe es eins für "SamsungTV Serie C und D", eins für "SamsungTV Serie E und höher".
Pro: unterschiedliche Parameterzahl kein Problem, auch die Wartungsfrage wäre dann eindeutig geklärt.
Con: zwei Module für gleichartige Geräte
Ist es ok, ein neues Modul STV2 anzulegen?

2. define-parameter vs. attr
Das neuere Samsung-Script benötigt Angaben wie IP, lokale IP, lokale MAC, Modellbezeichnung.
Aktuell habe ich diese nicht als define-Parameter, sondern als Attribute vorgesehen. Sind die Attribute nicht vorhanden, wird eine Fehlermeldung ausgegeben.
Pro: Werte können später leicht geändert werden
Con: leicht inkonsistent mit anderen Modulen (zumindest für IP)
Auch eine Mischung wäre möglich: IP als define-Parameter, die weiteren Werte als Attribute.
Ist die Implementierung für alle Werte als Attribute ok?


Ein weiteres Modul stellt eine grafische Fernbedienung bereit, ist also quasi ein reines Frontend.
Jeder Tastendruck wird dann per notify an das eigentlich ausführende fhem-device weitergegeben.

3. Geschwindigkeit vs. Speicherverbrauch
Der user definiert über Attribute das gewünschte Tastaturlayout. Aus diesem Tastaturlayout wird dann htmlCode erzeigt, der via weblink htmlCode angezeigt wird.
Das Tastaturlayout ändert sich nur anfangs öfter. Hat der user das Layout einmal fertig, sind die Attributwerte und damit der htmlcode eigentlich statisch.
Ich ziehe nun in Betracht, den htmlcode in hash->{htmlcode} zu hinterlegen. Nicht im initialize, sondern erst beim ersten Aufruf. Ein Neuaufbau des htmlcode erfolgt dann nur nach Attribut-Änderung. . Ist keine Änderung erfolgt, wird einfach nur der Inhalt von hash->{htmlcode} zurückgegeben.
Pro: Bessere Performance, da der htmlcode nur selten erzeugt werden muss
Con: Speicherverbrauch
Ist es ok, hash->{htmlcode} zu nutzen?

4. notify vs. command
Jeder Tastendruck muss an das eigentlich ausführende fhem-device weitergegeben werden. Ich ziehe in Betracht, ein Attribut "command" zu spendieren, in dem hinterlegt wird, welcher Befehl nach einem Tastendruck ausgeführt werden soll.
Beispiele:
attr <remotecontrol> command set <ausführendesDevice> $EVENT
oder
attr <remotecontrol> command {meineRoutine("$EVENT")}
(BTW: Sowas hab ich mir für dummy schon öfter gewünscht)
Alternativ müsste man ein notify anlegen der Form
define xyz notify <remotecontrol> set <ausführendesDevice> $EVENT
bzw
define xyz notify <remotecontrol> {meineRoutine("$EVENT")}
Bei Implementierung via attr:
Pro: Übersichtlichkeit und performance: Es muss kein zusätzliches notify angelegt werden, das bei JEDEM Systemevent geprüft werden muss
Con: Inkonsistenz: Verwässert die klare Struktur, dass unterschiedliche devices ausschließlich via notify gekoppelt werden
Was haltet ihr von attr command?

5. Modulname
Der aktuelle Name ist 95_remotecontrol. 95 weil wie 95_floorplan = für mich leicht zu finden.
Soll eine niedrigere Ordnungszahl verwendet werden? Falls ja, welche?

Schon im Voraus vielen Dank für euren input,
Gruß, Uli

[rudolfkoenig]

1. Mir ist das eigentlich egal, da es deine Freizeit ist, will ich nichts wirklich vorschreiben.
Versuch aber mal das Ganze aus der Sicht eines FHEM-Neulings anzuschauen: je weniger man vorher studieren muss, desto toller findet man es und desto weniger nervt man dich im Support :). Aus diesem Grund waere ein Modul mit Autoerkennung am schoensten :)

2. Theoretisch sollte alles, was man zum "normalen" Betrieb braucht, im define spezifiziert werden, Attribute sollten das "Normalverhalten" aendern. Leider weichen einige (selbst meine) Module von dieser Theorie ab.
Modifizieren kann man beides einfach, das sollte kein Argument sein.

3. Ich vermute Speicherverbrauch ist egal (liegt bei 10+k?), im Detailansicht/list/xmllist/jsonlist/etc werden aber solche Attribute angezeigt. Evtl. $hash->{".htmlCode"} verwenden, das wird per default nicht angezeigt (erst wenn man global showInternalValues setzt).

4. ich bin sehr fuer notify, damit man nicht Sonderwege geht. Mit events kann man FileLog/dblog, sequence, longpoll etc verwenden.

5. Nummer ist mir mehr oder weniger egal, es sollten vielleicht in der Naehe aehnliche Module sich befinden.

[UliM]

Hi,
alles klar, danke.

ad 1) Bezgl kombiniertem Modul für STV bin ich mit dem Autor unterwegs, die erste lauffähige Version gibt's schon :)
Bezgl der vorgeschlagenen Auto-Erkennung sind wir auf der ratlosen Suche, wie man die ip und v.a. mac des Rechners bekommt, auf dem fhem läuft. Für ip haben wir was, für mac nicht. Kennt jemand einen Weg?

Gruß, Uli