Abstraktion von I/O-Devices

[Dr. Boris Neubert]

Hallo,

ich laufe jetzt Gefahr, eine Idee in die Welt zu setzen, die ich aus Zeitgründen (habe noch innerhalb und außerhalb der FHEM-Welt eine Reihe von Hausaufgaben zu erledigen) nicht realisieren kann und vielleicht auch gar keiner haben will. Aber ich tut es dennoch: vielleicht findet jemand die Anregung gut und macht sich daran:

Devices in FHEM beziehen Daten von I/O-Geräten (serielle Schnittstellen, TCP-Sockets). Die Kommunikation mit diesen Geräten ist in DevIO.pm gekapselt. Gut.

Schwierig wird es zur Zeit, die Kommunikationsparameter mitzugeben. Bzgl. der seriellen Schnittstellen gibt es die Behelfslösung, die Baudrate mit @ an den Device-Namen anzuhängen. Sollen Bitzahl, Parity und Stoppbits mitgegeben werden, wie öfters im Forum gewünscht, wird es schwierig.

DevIO könnte ein echtes Device werden. Man definiert dann beispielsweise:

Code Auswählen Erweitern


define myTty /dev/ttyS0
attr myTty baudrate 19200
attr myTty bps 7n1

define myFHZ myTty


Vielleicht erleichtert das auch Andres Sandbox-Modularisierung. Das I/O-Gerät wird dann als Proxy oder Tunnel zu in einem eigenen Prozeß laufenden realen Device konstruiert.

Migration alter defines: wird das I/O-Gerät nicht als vorher definiertes Device erkannt, wird das Device on-the-fly erzeugt.

Viele Grüße
Boris

[Markus Bloch]

Ich würde eher vorschlagen von einem DeviceString in DevIo wegzugehen und DevIo ähnlich wie bei den neuen HttpUtils.pm Funktionen mit einem Parameter-Hash zu füttern, welcher dann eben auch Bitzahl, Parity, ... usw. enthalten könnte. Das erspart auch die ganze DeviceString-Zusammensetzerei, so wie sie momentan in vielen Define-Funktionen zu finden ist.

Ist aber schon eine massive Änderung.

Gruß
Markus

[justme1968]

die idee mit dem hash betriff aber eher das interne api, der vorschlag über device und attribute eher das interface das dem endanwender zum anlegen/konfigurieren zur verfügung steht.

beides könnte man eventuell kombinieren in dem man beim define <param>=<wert> paare erlaubt aus denen man dann recht einfach den hash zur internen verwendung erzeugen könnte. oder auch gleich einen hash als {...} ausdruck im define erlaubt. letzteres ist aber vielleicht nicht so gut enduser geignet.

vielleicht ist das parsen der define parater und das es in jedem modul immer wieder aufs neue gemacht wird aber auch schon ein teil des problems.

wenn man das parsen der <param>=<wert> paare in einen hash zentral einbaut würde das vermutlich in einigen modulen das parsen der define parameter erleichtern. man könnte sogar so weit gehen und analog zur AttrList eine modul spezifische ParamList einführen und der DefFn gleich den fertig aufbereiteten hash mit übergeben. das würde vermutlich für 95% aller module das selber parsen erübrigen.

was die sandbox angeht seht ich das iodev eigentlich fast immer mit in der sandbox. gerade wenn es ums timing geht ist es da am besten aufgehoben.

gruss
  andre