Probleme mit aktueller Blocking Implementation

[Dirk]

Hi Andre,

Anbei mal das Archiv.
Das so einfach ins FHEM-Verzeichniss entpacken.
Hier sind auch 2 Symlinks mit dabei.

in FHEM/HM485/SerialServer/HM485_SerialServer.pl ist der Server-Process.
Der Name wird noch geändert

Zum Testen musst du das Modul HM485-Serial definieren:

Code Auswählen Erweitern


# Die Definition des Seriellen Devices (auf localhost:2000 hört der HM485_SerialServer.pl, shiehe unten)
define HM485_Interface HM485_INTERFACE localhost:2000

# Dieses Attribut ist zum Starten, Stoppen und Überwachen des Serverprozesses Gedacht.
# Derzeit wird hier nur der Start mit FHEM gesteuert. Die Überwachung ist noch nicht komplett.
# Ohne bindSerialServer 1 wird erwartet das der Server bereits läuft.
attr HM485_Interface bindSerialServer 1

# Hiermit wird das externe Interface mit dem der Server sich verbindet, konfiguriert
# Alternativ /dev/ttySX oder ähnlich
attr HM485_Interface server_device 192.168.178.15:5000

# Logattribute für den Server
attr HM485_Interface server_logVerbose 4

# ggf. eigenes Logfile für den Server
#attr HM485_Interface logFile /opt/FHEM/fhem.dev/log/hm485SerialServer.log


Der Serverprozess hat ggf. noch weitere Parameter. Diese sind alle per POD verfügbar und über hm485SerialServer.log --help bzw. hm485SerialServer.log --man Abrufbar. All diese Parameter sind dann aber vom Autor des Server-Entwicklers zu implementieren. Das macht ServerTools nicht.

Zum Testen hört der Server auf allen Interfaces. Ich bin mir nicht sicher ob man das so lassen soll, oder ob man aus Sicherheitsgründen das ganze auf localhost beschränken sollte.

Damit solltest du das dann schonmal testen können.

Gruß
Dirk

Update: File gelöscht.

[Dirk]

Solange das Modul noch nicht im FHEM-SVN ist, ist die aktuelle Version hier:
https://github.com/kc-GitHub/FHEM-HM485

Gruß
Dirk

[ntruchsess]

ich habe hierzu auch mal angefangen das generisch zu implementieren: AsyncDevice.pm.
Idee: Fhem öffnet einen ServerSocket, forkt einen Kind-prozess, dieser räumt intern alles auf, was nicht zum eigenen Device gehört und verbindet (dauerhaft) zum ServerSocket. Dabei werden sowohl im Parent, als auch im Child temporäre Devices für die Socket-kommunikation angelegt, damit das eigentliche Device im Childprozess sein I/O weiterhin ungestört über die selectlist abwickeln kann und der Modulentwickler sich um solche Details nicht kümmern muss.

- Norbert