DevIo: FHEM-Modul als IO-Device

[ntruchsess]

Wenn man das aber im Client als IODev-Attribut verwenden will, muss man, anders als bei meinem Vorschlag, die bestehenden potentiellen Clients ändern.

Da hast Du natürlich recht, den namen des IODevs analog zum physikalischen Device im Define zu übergeben ist natürlich abwärtskompatibel. Wirklich funktionieren tut das aber nur, wenn das jeweilige client-device in Define nach einem Aufruf von DevIOOpenDev nichts relevantes mehr tut, da es sich ja nicht darauf verlassen kann, dass das virtuelle serielle Device überhaupt schon existiert oder tatsächlich verbunden ist. Ich nehme mal stark an, dass da die eine oder andere Nacharbeit nötig sein wird, bis alle Devices kompatibel sind (das kann ja 'ad hoc' geschehen, wenn es jemand braucht und es - noch - nicht geht).

[jensb]

Das ist einer der Punkte, die mir beim Testen aufgefallen ist. Module, die mit OS-Devices arbeiten, sind meist Gateways und werden daher meist relativ früh initialisiert. Es dauert aber einige Sekunden, bis ein Arduino sich nach einem FHEM-Neustart verbunden hat. In der Übergangszeit kann man das Device als offen an das Client-Modul melden, aber das Client-Modul könnte nicht erfolgreich senden. Puffert man das dann oder gibt mein beim Write einen IO-Fehler zurück? Da gibt es leider noch einige Abgründe. Trotzdem würde vielleicht das eine oder andere Client-Modul "spontan" funktionieren.

Wenn man statt dessen die IODev-Lösung anbietet, bleibt es im Ermessen der Modulentwickler, ob eine Unterstützung erfolgt - die dann aber auch so etwas berücksichtigen könnte.

Grüße,
Jens

[ntruchsess]

ok, ich hol das Thema mal wieder hoch.

Jens hat mir seine Änderungen über Github geschickt. Ich pick jetzt mal nur die DevIo.pm raus:

DevIo.pm
und hier der Commit selbst

@rudolfkoenig: vieleicht kannst Du da grade mal einen Blick drauf werfen, ob man das so übernehmen kann?

- Norbert

[rudolfkoenig]

Habs eingecheckt.
Verstehe es zwar immer noch nicht, will aber die Laune zum spielen nicht bremsen.
Und ich gehe davon aus, dass es keine Nebenwirkungen hat.

[jensb]

Hallo,

Ich sehe noch ungeloeste Probleme bei deinem Vorschlag:
- wer & wann ruft das ReadFn des oberen Moduls auf? Bisher wird das durch das globale select erledigt.
- wie loest man das "CUL_ReadAnswer" Problem (da wird ganz haesslich blockierend vom FD gelesen).
- nicht alle Module verwenden DevIo_SimpleWrite, z.Bsp. 00_CUL.pm und 00_ZWCUL.pm

Ich wuerde diese Probleme durch einen altmodischen pipe() loesen.

Verwendet ein Modul nur nicht sequenzielle Schreib- und Lesezugriffe, geht das vorgeschlagene Konzept auf (Beispiel serielle HEATRONIC hinter Ethernet-FRM).

Wenn ein Modul aber direktes IO verwendet oder blockierende write/read Sequenzen, funktioniert es nicht immer wie mit einem physikalischem Device. Ein Beispiel hierfür ist z.B. serielles FRM hinter Ethernet FRM, da neue Daten auf der über TCP abstrahierten seriellen Schnittstelle von extern erst verarbeitet werden, wenn FHEM den FD des TCP Socketes auf ready-for-read prüft, was aber nicht erfolgen kann, wenn ein Modul gerade blockend arbeitet. Eine Pipe würde daran leider auch nichts ändern, da auch hier erst der Read vom TCP Socket erfolgen muss, bevor man die Daten in die Pipe schreiben kann. Nur wenn der TCP Receive tatsächlich parallel erfolgen würde, könnte man das vermeiden. Hier fehlt mir noch eine Idee, wie man das ohne Multithreading/Forking erreichen kann.

Und ich gehe davon aus, dass es keine Nebenwirkungen hat.

Da die Erweiterung um "IODev" in DevIO.pm immer am Ende der vorhandenen if-Ketten erfolgt, hat sie keine Auswirkungen auf die Performance oder die Logik besehender Installationen.

Grüße,
Jens