Hallo,
es gibt in fhem.pl das IOWrite($hash,$foo), worüber das durch $hash bezeichnete Client-Device nach vorigem AssignIOPort($hash) über das Server-Device schreiben kann.
Es gibt aber kein IORead($hash,$bar), worüber das Client-Device lesen kann. Liegt das daran, daß es bisher keine Clients gab, die pollen müssen, oder übersehe ich hier einen grundsätzlichen anderen Mechanismus, der verwendet werden sollte?
Ich frage das, weil ich ansonsten meine lokal modifizierte Version von fhem.pl mit IORead einchecken werde.
Viele Grüße
Boris
ZitatEs gibt aber kein IORead($hash,$bar), worüber das Client-Device lesen kann. Liegt das daran, daß es bisher keine Clients gab, die pollen müssen, oder übersehe ich hier einen grundsätzlichen anderen Mechanismus, der verwendet werden sollte?
Es gibt im 10_ZWave.pm ein Beispiel dafuer mit dem Aufruf des ReadAnswerFn's aus 00_ZWDongle. Da ich aber sowas generell vermeiden wuerde (siehe WOL vs. HMLAN Problem), habe ich das nicht generisch eingebaut. Sinnvoll waere eine Funktion, die fuer solche Aufgaben ein fork durchfuehrt, beim Lesen der Daten blockiert, die Daten an das Vaterprozess/Modul/Instanz zurueckmeldet, z.Bsp. mit dem iowrite fhem Befehl.
Zitat von: rudolfkoenig schrieb am So, 23 Dezember 2012 13:09ZitatEs gibt aber kein IORead($hash,$bar), worüber das Client-Device lesen kann. Liegt das daran, daß es bisher keine Clients gab, die pollen müssen, oder übersehe ich hier einen grundsätzlichen anderen Mechanismus, der verwendet werden sollte?
Es gibt im 10_ZWave.pm ein Beispiel dafuer mit dem Aufruf des ReadAnswerFn's aus 00_ZWDongle. Da ich aber sowas generell vermeiden wuerde (siehe WOL vs. HMLAN Problem), habe ich das nicht generisch eingebaut. Sinnvoll waere eine Funktion, die fuer solche Aufgaben ein fork durchfuehrt, beim Lesen der Daten blockiert, die Daten an das Vaterprozess/Modul/Instanz zurueckmeldet, z.Bsp. mit dem iowrite fhem Befehl.
Danke. Dann lasse ich lieber das Äquivalent von IOWrite in meinem Modul.
Grüße
Boris