Originally posted by: <email address deleted>
Hi,
gestern hat sich mein CUL verabschiedet, wie man sehen kann eine
Sekunde, nach dem ein timergesteuerter FS20-Befehl noch ordnungsgemäß
gesendet wurde.
Log:
2011.02.01 23:30:00 2: FS20 set 0117_Subwoofer off
2011.02.01 23:30:01 1: /dev/ttyACM0 disconnected, waiting to reappear
...
Ein Neustart von FHEM brachte nur:
2011.02.01 23:45:50 0: Server shutdown
2011.02.01 23:45:53 2: FHEMWEB port 8083 opened
2011.02.01 23:45:53 2: FHEMWEB port 8084 opened
2011.02.01 23:45:53 3: CUL opening CUL1 device /dev/ttyACM0
2011.02.01 23:45:53 3: Can't open /dev/ttyACM0: No such file or
directory
2011.02.01 23:45:55 0: Server started (version 5.0 from 2010-08-15
($Id: fhem.pl,v 1.111 2010-09-30 13:12:27 rudolfkoenig Exp $), pid
24763)
Im Verzeichnis /dev/ ist das ttyACM0 verschwunden und dort steht nun
ein ttyACM1, womit der sich der CUL auch wieder ansprechen lässt.
Der Server ist eine Seagate Dockstar. Wie ich hier in der Gruppe lesen
konnte, scheint es unter Debian ein kleines Problem zu geben. Die
Seite http://fhem.de/linux.html habe ich mir schon durchgelesen, aber
da ich Debian habe, weiß ich nicht so genau, was ich da wie und wo
machen soll.
Ich dachte auch gleich an einen Watchdog, der FHEM neustartet, wenn so
ein Fall noch einmal auftreten sollte.
Könnt ihr mir dabei helfen?
Grüße Jörg
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Originally posted by: <email address deleted>
On 02/02/2011 10:29 AM, JörgB wrote:
> 2011.02.01 23:30:00 2: FS20 set 0117_Subwoofer off
> 2011.02.01 23:30:01 1: /dev/ttyACM0 disconnected, waiting to reappear
> ...
>
> Im Verzeichnis /dev/ ist das ttyACM0 verschwunden und dort steht nun
> ein ttyACM1, womit der sich der CUL auch wieder ansprechen lässt.
Sieht meiner Meinung nach aus wie ein Fall von instabilem USB; hast Du
vielleicht ein schlechtes oder langes Kabel, oder viele/starke
Störquellen? Wenn die USB-Kommunikation abstürzt, bleibt das alte Device
noch eine Weile da, und parallel wird das neu gefundene angelegt (dann
als ttyACM1, da die 0 noch von dem Zombie belegt ist).
An meinem Dockstar lief der CUL unter Debian immer problemlos.
Viele liebe Grüße,
Thomas
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Originally posted by: <email address deleted>
Hmm - Der CUL ist an einem der hinteren Ports mit einer Verlängerung
(der halbe Golfball) von 1,5m, die ich gleich mit dem CUL bestellt
habe.
Ca. alle drei Wochen scheint das Problem aufzutreten. Das dabei aber
der ACM umbenannt wurde, war gestern das erste Mal.
Zusätzlich habe ich noch an einem weitern Port einen aktiven USB-Hub
angeschlossen. Der wird aber von einem anderen Server gebraucht, der
nichts mit FHEM zu tun hat.
Da ich auch schon einige Male beobachten konnte, dass bei schnell
hintereinander folgenden FS20-Befehlen manchmal Einer "verschluckt"
wird, habe ich FHEM schon auf -5 reniced.
Grüße Jörg
> Sieht meiner Meinung nach aus wie ein Fall von instabilem USB; hast Du
> vielleicht ein schlechtes oder langes Kabel, oder viele/starke
> Störquellen? Wenn die USB-Kommunikation abstürzt, bleibt das alte Device
> noch eine Weile da, und parallel wird das neu gefundene angelegt (dann
> als ttyACM1, da die 0 noch von dem Zombie belegt ist).
>
> An meinem Dockstar lief der CUL unter Debian immer problemlos.
>
> Viele liebe Grüße,
> Thomas
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Originally posted by: <email address deleted>
On 02/02/2011 02:36 PM, JörgB wrote:
> Hmm - Der CUL ist an einem der hinteren Ports mit einer Verlängerung
> (der halbe Golfball) von 1,5m, die ich gleich mit dem CUL bestellt
> habe.
Keine Ahnung, was Du mit halbem Golfball meinst, aber soweit ich mich
erinnere ist das original Busware Kabel mit je einem Ferritkern am Ende,
das sollte schonmal ganz ok sein bei der Länge.
Was gibt den dmesg auf dem Dockstar aus, nachdem der Fehler aufgetreten ist?
> Ca. alle drei Wochen scheint das Problem aufzutreten. Das dabei aber
> der ACM umbenannt wurde, war gestern das erste Mal.
Tritt das Problem immer nach dem Abschalten des Subwoofers auf? Befindet
sich der in unmittelbarer Nähe oder ist er sogar (indirekt) mit dem
Dockstar verbunden?
> Zusätzlich habe ich noch an einem weitern Port einen aktiven USB-Hub
> angeschlossen. Der wird aber von einem anderen Server gebraucht, der
> nichts mit FHEM zu tun hat.
Kannst ja mal testweise den CUL an den Hub hängen, und gucken ob es
besser wird oder schlechter.
> Da ich auch schon einige Male beobachten konnte, dass bei schnell
> hintereinander folgenden FS20-Befehlen manchmal Einer "verschluckt"
> wird, habe ich FHEM schon auf -5 reniced.
Hmmm, kann ich nicht bestätigen. Wurden die Befehle verschluckt, als
FHEM sie z.B. über telnet empfangen hat (sollte eigentlich nicht
vorkommen), oder wenn die Befehle über den CUL reinkamen?
Grüße,
Thomas
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Originally posted by: <email address deleted>
> Keine Ahnung, was Du mit halbem Golfball meinst, aber soweit ich mich
> erinnere ist das original Busware Kabel mit je einem Ferritkern am Ende,
> das sollte schonmal ganz ok sein bei der Länge.
Es ist der hier, auch mit der Antenne:
http://busware.de/show_image.php?id=193
> Was gibt den dmesg auf dem Dockstar aus, nachdem der Fehler aufgetreten ist?
>
> Tritt das Problem immer nach dem Abschalten des Subwoofers auf? Befindet
> sich der in unmittelbarer Nähe oder ist er sogar (indirekt) mit dem
> Dockstar verbunden?
Der Subwoofer hat damit eigentlich nichts zu tun. Das was nur Zufall,
dass es gerade bei dem Schaltvorgang passierte. Er hat auch keine
(in)direkte Verbindung zum Server.
Hier noch sind noch einige andere Logs, die das bestätigen:
2010.12.26 13:12:17 2: FS20 set Halogen_Decke_2 off
2010.12.26 13:12:19 2: FS20 set Halogen_Decke_1 off
2010.12.26 13:12:21 2: FS20 set Tischlampen off
2010.12.26 13:19:14 2: FS20 Monitor_CAM on-for-timer 288
2010.12.26 14:40:34 1: /dev/ttyACM0 disconnected, waiting to reappear
2011.01.09 14:28:28 2: FS20 set OG_KU_Halogen_2 off
2011.01.09 14:28:30 2: FS20 set OG_KU_Halogen_1 off
2011.01.09 15:32:10 1: /dev/ttyACM0 disconnected, waiting to reappear
> Kannst ja mal testweise den CUL an den Hub hängen, und gucken ob es
> besser wird oder schlechter.
Ja, das kann ich heute mal testen.
> Hmmm, kann ich nicht bestätigen. Wurden die Befehle verschluckt, als
> FHEM sie z.B. über telnet empfangen hat (sollte eigentlich nicht
> vorkommen), oder wenn die Befehle über den CUL reinkamen?
Bei mir sieht das so aus, dass FHEM ein Triggersignal bekommt und dann
ein Makro ausführt. Mit Telnet mache ich eigentlich nichts.
Ich musste zum Beispiel um meine Steckdosenleiste ordnungsgemäß
ausschalten zu können, jeden Aktor mit einer Sekunde verzögern. Wenn
ich die Aktoren direkt mit "set" anspreche, kann(!) es sein, dass da
noch ein Aktor an bleibt. Das ist aber nicht nur bei den Aktoren so,
auch bei Dimmern in anderen Räumen.
fhem ("define ir04 at +00:00:04 set 0119_Reserve off") ;;
\
fhem ("define ir05 at +00:00:05 set 0118_Reserve off") ;;
\
fhem ("define ir06 at +00:00:06 set 0117_Subwoofer off") ;;
\
fhem ("define ir07 at +00:00:07 set 0116_MC115 off") ;;
\
fhem ("define ir08 at +00:00:08 set 0115_Internetradio off")
;; \
fhem ("define ir09 at +00:00:09 set 0114_LaserDisc off") ;;
\
fhem ("define ir10 at +00:00:10 set 0113_dBox off") ;; \
fhem ("define ir11 at +00:00:11 set 0112_Maxdome off") ;;
\
fhem ("define ir12 at +00:00:12 set 0111_DVD off") ;;
\
fhem ("define ir13 at +00:00:15 set 0110_TV off") ;; \
Grüße Jörg
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Originally posted by: <email address deleted>
Mir ist da noch eingefallen, warum kann man den CUL nicht direkt mit
bus:device, also z.B. 001:004 ansprechen?
Bei den anderen Geräten kann ich das so machen.
LG Jörg
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Am 02.02.2011 10:29, schrieb JörgB:
> Im Verzeichnis /dev/ ist das ttyACM0 verschwunden und dort steht nun
> ein ttyACM1, womit der sich der CUL auch wieder ansprechen lässt.
http://www.fhemwiki.de/index.php/LinuxDeviceNaming
könnte Dir helfen.
Grüße,
Boris
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
> Bei den anderen Geräten kann ich das so machen.
Bei welchen?
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Originally posted by: <email address deleted>
Salve,
> gestern hat sich mein CUL verabschiedet, wie man sehen kann eine
[...]
> 2011.02.01 23:30:01 1: /dev/ttyACM0 disconnected, waiting to reappear
> ...
>
> Ein Neustart von FHEM brachte nur:
[...]
> 2011.02.01 23:45:53 3: CUL opening CUL1 device /dev/ttyACM0
> 2011.02.01 23:45:53 3: Can't open /dev/ttyACM0: No such file or directory
[...]
> Im Verzeichnis /dev/ ist das ttyACM0 verschwunden und dort steht nun
> ein ttyACM1, womit der sich der CUL auch wieder ansprechen lässt.
>
> Der Server ist eine Seagate Dockstar. Wie ich hier in der Gruppe lesen
> konnte, scheint es unter Debian ein kleines Problem zu geben. Die
Kann ich so nicht bestätigen. Nachdem mein FHEM auf SheevaPlug (alles USB-
Geraffel an aktivem 7-Port-Hub) massiv instabil wurde, habe das das Rotz-
teil durch 'nen pinken PogoPlug ersetzt (meine Dockstars waren alle grade
anderweitig in Verwendung), und alle USB-Geräte nach und nach wieder hin-
zugesteckt (CUL an einen der PogoPlug-eigenen Ports, das Gros wieder an
jenen 7-Port-Hub). Und siehe: nicht der SheevaPlug war das Problem, sondern
der Plugwise-Stick bringt den USB in Schwulitäten: Reboot, FHEM wird per
cron gestartet, diverse USB-Geräte werden geöffnet, kommt die Reihe an den
Plugwise-Stick => USB-Disconnect-Orgie und ratzekahl leer ist der US-Bus :(
FTR, derzeit steckt das am PogoPlug -- und es ist stabil seit rd. 3 Wochen:
root@pogo-1:~# lsusb
Bus 001 Device 091: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 090: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter
Bus 001 Device 089: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 088: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 087: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 120: ID 04b4:fd13 Cypress Semiconductor Corp.
Bus 001 Device 118: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 005: ID 13fe:3600 Kingston Technology Company Inc.
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Ein anderes, extremeres USB-Beispiel: Dockstar plus 10-Port-HUB, insges. 5 HDD,
1 Audio-Dongle, 1 WLAN-Adapter, 1 SPF-87H als USB-Monitor:
dockstar-2:~# lsusb
Bus 001 Device 038: ID 0cf3:7015 Atheros Communications, Inc.
Bus 001 Device 036: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge
Bus 001 Device 035: ID 1058:1021 Western Digital Technologies, Inc.
Bus 001 Device 033: ID 04e8:2034 Samsung Electronics Co., Ltd
Bus 001 Device 017: ID 0c76:1607 JMTek, LLC.
Bus 001 Device 009: ID 0bc2:3101 Seagate RSS LLC
Bus 001 Device 007: ID 1058:1100 Western Digital Technologies, Inc.
Bus 001 Device 006: ID 1a40:0101 TERMINUS TECHNOLOGY INC. USB-2.0 4-Port HUB
Bus 001 Device 003: ID 0951:1624 Kingston Technology
Bus 001 Device 005: ID 1a40:0201 TERMINUS TECHNOLOGY INC.
Bus 001 Device 004: ID 0411:0105 MelCo., Inc.
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB [Hama]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Auch das rennt stabil, grade 480GB von einer auf 'ne andere Platte geschoben,
dabei laufend den Picture Frame aktualisiert und zeitweise auch noch per
squeezeslave Musik gehört ...
Kurzum: aus meiner Erfahrung sind USB-Probleme, wie hier schon genannt, fast
immer auf schlechte Kabel, äußere Störeinflüsse (geschaltete starke elektri-
sche Verbraucher) oder dergleichen zurückzuführen. So hat sich auch mein CUL
deutlich beruhigt, nachdem ich ihn nicht mehr über passives Verlängerungs-
kabel plus passiven HUB parallel zur FHZ1350 auf dem Wohnzimmerschrank ange-
schlossen habe, sondern direkt (oder fast direkt) am FHEM-Host. (Die FHZ habe
ich mittlerweile zu nutzen aufgegeben.) Der Wechsel von passivem 4-Port-Hub
auf aktiven solchen brachte auch eine Stabilitätsverbesserung für das ganze
USB-Zeuchs ...
Ein generelles USB-Problem kann ich weder Debian noch den Plug-Computer-Kisten
noch der Kombination davon attestieren. (Und ich mache recht viel, zwangweise
USB-zentriert, mit denen: 3 HD-mjpeg-streamer-basierte Webcamserver, 2 VDRs
(2x DVB-T bzw. 2x DVB-S2), 2 DSL-OpenVPN-Router, 3 NFS-Server, ...)
Ergo: aktiven HUB einsetzen, Kabel kurz halten (oder aktiven Hub plus aktive
Verlängerung probieren, könnte bei CUL noch klappen), gute Kabel (nicht die
1,95-Baumarkt-Ware) verwenden. Klingt doof -- but works for me.
HTH,
kai
P.S.: Ich spreche CUL sowie die USB2RS232-Adapter über eigene Namen unter /dev an,
einfach, um es rebootfest zu haben; ggf. kaschiert derlei aber Dein Problem
ebenfalls:
root@pogo-1:~# cat /etc/udev/rules.d/10-udev.rules
KERNEL=="ttyUSB*", ATTRS{product}=="ELV FHZ 1350 PC", SYMLINK+="elv_fhz1350pc"
KERNEL=="ttyUSB*", ATTRS{product}=="ELV FHZ 1300 PC", SYMLINK+="elv_fhz1300pc"
KERNEL=="ttyUSB*", ATTRS{product}=="ELV EM 1010 PC", SYMLINK+="elv_em1010pc"
KERNEL=="ttyACM*", ATTRS{product}=="CUL868", SYMLINK+="busware_cul"
KERNEL=="ttyACM*", ATTRS{product}=="CUL433", SYMLINK+="busware_cul433"
KERNEL=="ttyUSB*", ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="XXXXXXXX", SYMLINK+="Plugwise_Stick"
KERNEL=="ttyUSB*", ATTRS{manufacturer}=="Prolific Technology Inc.", ATTRS{product}=="USB-Serial Controller", SYMLINK+="LG_47LG700"
KERNEL=="ttyUSB*", ATTRS{manufacturer}=="Prolific Technology Inc.", ATTRS{product}=="USB-Serial Controller D", SYMLINK+="1Wire-Adapter"
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Originally posted by: <email address deleted>
Erst einmal sorry, dass ich erst jetzt antworte, aber ich hatte
gestern nach einem 16 Stunden Arbeitstag keine Lust mehr dazu.
@Thomas:
Der halbe Golfball hat keinen Ferritkern am Ende. Daraufhin habe ich
das Kabel erst einmal gegen ein 15cm Kabel ersetzt. Der erste Eindruck
ist, dass es nun besser ist, was das Verschlucken einiger Befehle
betrifft.
@Kai:
Ich benutze einen aktiven 7 Port König-Hub
Deine Lösung mit der Datei "10-udev.rules" hat funktioniert. Der CUL
lässt sich nun mit "busware_cul" ansprechen.
Das der CUL mit dem Kabel so empfindlich ist, hätte ich nicht gedacht.
Wie ich gesehen habe, hat Busware das Kabel nun auch aus dem Programm
genommen.
Jetzt am WE werde ich mir erst einmal dem Watchdog befassen, damit er
bei einem Ausfall FHEM neu startet.
Dank an Alle, die mir geholfen haben!
P.S. Werde nach einer Zeit berichten, ob es das Kabel war
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.