CUL funktioniert mit cygwin Perl nicht stabil bzw. momentan gar nicht

Begonnen von tomcat.x, 27 Februar 2016, 16:22:04

Vorheriges Thema - Nächstes Thema

tomcat.x

Hallo,

wegen Problemen mit der SSL Verbindung beim Modul harmony und auch weil ich Blocking Module wie FRITZBOX einsetzen wollte, habe ich vor ein paar Wochen von ActivePerl auf cygwin umgestellt. Nach anfänglichen Schwierigkeiten funktionierte der CUL, ohne dass ich weiß warum. Er lief einige Wochen, bis er seit einem Windows Neustart vor 3 Wochen nicht mehr tut und ich ihn nicht wieder zum Laufen bekomme.

Im Log stehen folgende Meldungen beim Neustart von fhem:
2016.02.25 19:05:46 1: PERL WARNING: can't getattr: Invalid argument at ./FHEM/DevIo.pm line 288.
2016.02.25 19:06:48 3: Opening CUL device /dev/ttyS3
2016.02.25 19:06:48 3: Can't open /dev/ttyS3: Invalid argument

Vor dem Neustart, seit dem der CUL nicht mehr funktioniert, gab es Windows Updates und ich habe ActivePerl deinstalliert. Andere Änderungen sind mir nicht bewusst.

Was ich schon versucht habe:
- cygwin komplett neu installiert
- fhem mit einer minimalen Konfiguration nur mit CUL gestartet
- weiteren CUL an einem anderen USB Port angeschlossen
- CUL vor Start von fhem mit "echo V >COM4" angesprochen (Tipp von ChrisD)

Infos zum aktuellen Status:
- im cygwin Fenster sehe ich das Device als /dev/ttyS3
- dort bekommen ich per tee Befehl auch eingehende Nachrichten angezeigt
- CUL ist mit "define CUL CUL /dev/ttyS3@9600 1234" definiert

Hat jemand einen Tipp zum Fehler oder wie ich da weiter analysieren kann? Muss ich außer Device::SerialPort noch ein Package installieren? Oder die Schnittstelle irgendwie initialisieren, um sie von Perl aus zu nutzen?

Vielen Dank für die Hilfe!
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

tomcat.x

Einige Aufrufe des Beitrags aber keine Ideen. Haben diese Kombination überhaupt ein paar im Einsatz?

Wenn ich mir die Umfrageergebnisse und Anzahl Einträge hier anschaue, dann war Windows wohl eh die falsche Wahl. Schade, weil der Windows Server läuft sowieso ...
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

Wernieman

Naja ... mittlerweile haben eben doch sehr viele einen Unix (Linux) Server laufen, oder einen dedizierten FHEM-Linux-Rechner .....

Hast Du mla probiert, unter welchem "Device" Dein CUL ist?
2016.02.25 19:06:48 3: Can't open /dev/ttyS3: Invalid argument
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

ChrisD

Hallo,

Ich verwende FHEM seit mehreren Jahren mit Windows und Cygwin. Bei mir ist der CUL nach einem Reboot des Rechners unter Cygwin manchmal nicht ansprechbar (Fehler im Log: can't getattr: Invalid argument at ./FHEM/DevIo.pm line 288). Was bis jetzt immer geholfen hat ist den CUL mit einem Terminalprogramm anzusprechen und V abzuschicken um die Version auszulesen. Das Problem tritt unabhängig von der der Rechner-Hardware (Dell, HP, Noname) und dem Betriebssystem (2003R2, 2008R2, 2012R2) auf. Ein Jeelink der am gleichen Rechner hängt hat keine solchen Probleme so dass ich davon ausgehe dass es vom CUL kommt.

ZitatWenn ich mir die Umfrageergebnisse und Anzahl Einträge hier anschaue, dann war Windows wohl eh die falsche Wahl. Schade, weil der Windows Server läuft sowieso ...
Es gibt einige kleine Einschränkungen unter Windows (dies es aber auch zum Teil auf anderen Systemen gibt). Allerdings wirst du schnell Probleme bekommen wenn du Support für ein Modul benötigst. Sobald bekannt ist dass du FHEM unter Windows verwendest wird Windows immer der Grund für eventuelle Fehler sein.

Zitat...auch weil ich Blocking Module...
Das Blocking-Modul enthält einen Bug durch den es regelmäßig fremde Prozesse abschießt. Unter Linux ist dies nicht bemerkbar da hier die PIDs erst nach sehr langer Zeit wiederverwendet werden, unter Windows (und AIX) dagegen schon.

Wenn der Server mit Windows eh läuft kannst du Hyper-V verwenden um darauf Linux zu installieren. Die Anbindung des CUL kannst du dann z.B. über USB auf Netzwerk-Umsetzer machen.

Grüße,

ChrisD

tomcat.x

Hallo,

Danke für die Antworten. Ich bin mittlerweile wieder auf ActivePerl zurück - zumindest vorübergehend. Da funktioniert alles und inzwischen sogar die SSL Verbindung für die Harmony, wegen der ich hauptsächlich zu cygwin gewechselt bin. Fritzbox, Presence und Viera habe ich erst mal wieder deaktiviert.

@Wernieman: Der CUL ist unter COM4 (Windows, ActivePerl) bzw.  /dev/ttyS3 (cygwin) erreichbar. Ich konnte ihn darüber ja sogar aus dem cygwin Fenster ansprechen, nur nicht über perl/fhem.

@ChrisD: Danke noch mal für die Hilfe, ich habe es trotzdem nicht hinbekommen. VM wäre vielleicht eine Möglichkeit, zumindest für Linux - für alles andere dürfte der Server zu schwach sein. Wobei ich bei Linux dann eher über einen RasPi nachdenke. Der könnte wo anders stehen und ich würde mir den CUL_RFR sparen oder hätte ihn für andere Spielereien übrig. Der 3-er hätte auch Bluetooth, womit man sicher was anfangen könnte.

Was ich vor der Rückkehr zu ActivePerl noch festgestellt hatte: Über ein kleines Perl Script konnte ich den CUL auch nicht ansprechen, sehr wohl aber die ("echte") serielle Schnittstelle auf COM1 bzw. /dev/ttyS0.
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

viertelelf

Mir schien es bisher auch eine gute Idee FHEM auf einem Windows-PC laufen zu lassen.
Nachdem ich aber jetzt feststellen muss, dass auch mein CUL ziemlich unstabil läuft, ich überhaupt fast keinen Support für Windows sehe muss ich wohl FHEM noch einmal neu auf einer Linux-Büchse aufsetzen.
Schade, den Windows-Rechner brauche ich trotzdem, ich muss einen zweiten Linuxrechner danebenstellen, eigentlich wollte ich die Anzahl der Server senken und nicht erhöhen.
Ich habe aktuell Windows 10 pro, FHEM unter ActivePerl ist auf dem neuesten Stand und der CUL hat Version 1.66, zusätzlich steckt noch ein TCM310 für Enocean im Rechner. Genau kann ich noch nicht sagen wann das Problem auftritt, aber ich habe den Eindruck wenn die Rollläden alle gleichzeitig über RTS angesprochen werden, dann bleibt der CUL hängen.
Der CUL ist Übertragungsgeschwindigkeit 38.400 eingestellt, sonst habe ich keine Idee mehr, an was ich noch drehen könnte.

Viertelelf