CUL EM Verbindungsabbrüche

[hgw]

Hallo Leute,

Ich habe das Problem das im FHEM das logging der EM1000 Funksteckdosen mit installierten CUL (V3.3) nicht richtig geht. Die Steckdosen werden erkannt und automatisch eingerichtet aber nach 5-10 polls ist plötzlich Funkstille, sprich keine neue Einträge schlagen im Log auf :-/ Nachdem ich ein Restart des FHEM (/etc/init.d/fhem <stop/start>) durchgeführt habe kommen die Polls wieder an aber dann wieder genau dasselbe, nach 5-10 polls ist wieder schluss. Kann mir hier jemand helfen?

Ich betreibe das FHEM in einer VM (Virtualbox, das USB für CUL wird explizit an die VM durchgereicht) mit Debian6 und das FHEM ist auf dem aktuellen Stand (habe fhemupdate asugeführt).

Viele Grüße HG.

[Rudolf Koenig]

> nach 5-10 polls ist pl�tzlich Funkstille,

Hilft statt Neustart ein "set CUL raw X21" (Funk-Chip initialisieren) ?

Wenn ja, dann muesste man schauen, was hier schiefgeht, details dazu in beiden
commandref.html (in fhem: CUL Get Abschnitt bzw. in culfw command_C Abschnitt)

Wenn nein, dann hat das was mit der USB-Strecke zu tun.

[hgw]

OK "set CUL raw X21" (in meinem Fall set CUL_0 raw X21) hat leider nicht geholfen :-( Aber das es am USB liegt kann ich mir auch nicht so richtig vorstellen da das schalten meiner Funkschalter einwandfrei geht.

by the way ich hatte die Konfiguration nochmal komplett zurückgesetzt und alles neu erkennen lassen aber das hat auch nicht geholfen (das CUL device läuft mit der Konfiguration "define CUL_0 CUL /dev/ttyACM0@9600 1034")

Viele Grüße HG.

[hgw]

So, ich habe jetzt ein bisschen rumexperimentiert und es sieht wohl so aus als ob der CUL irgendwann nicht mehr über USB erreichbar ist. Ich bekomme so ca. 4-5 polls hin dann ist Ruhe. Wenn ich dann "get CUL_0 version" aufrufe bekomme ich beim ersten Aufruf (der so ca. 5 Sekunden geht) einen Fehler. Beim nochmaligen Aufruf (der geht deutlich schneller als der erste) bekomme ich dann die Versionsnummer und Oh Wunder die Polls kommen wieder durch. Das geht dann wieder 4-5 Polls gut und dann ist wieder Funkstille. Ich habe das jetzt mehrfach durchgespielt und vermute das sich der USB irgendwie schlafen legt. Oder kann es was anderes sein?

Grüße HG.

[JoWiemann]

Hallo,

 

prüf doch mal die Energiespareinstellungen an Deinem Rechner. Hier kann festgelegt werden, ob der USB sich schlafen legen darf.

 

Grüße

 

Jörg

[hgw]

Hallo Jörg,

das habe ich gerade gemacht, da ist alles im grünen Bereich, sprich der USB sollte sich nicht abschalten. Weder auf dem VM-Host (ist ein Ubuntu) noch in der FHEM-VM (Debian 6) selber. Kann es sein das da vielleicht Mainboardeinstellungen vom Bios her reinfunken?

Grüße HG.

PS: gibt es eine Möglichkeit im FHEM periodisch ein Kommando zu triggern? bzw. vom Cron aus FHEM interne Kommandos anzustoßen? so könnte ich als Workarround regelmäßig "get CUL_0 version" abfeuern

[hgw]

Wegen dem regelmäßigen Triggern ich habe jetzt einfach in den cron folgendes eingtragen:

*/5 * * * * hgw wget http://192.168.22.21:8083/fhem?cmd=get+CUL_0+version >/dev/null 2>&1

so sollte aller 5 minuten der status abgefragt werden, mal sehen wie das wirkt.....

[Rudolf Koenig]

> */5 * * * * hgw wget http://192.168.22.21:8083/fhem?cmd=get+CUL_0+version
> >/dev/null 2>&1

Was vergleichbares in FHEM:
define cGet at +00:05 get CUL_0 version
Ist aber genauso ein Workaround, und nicht die Loesung.
Woran das Problem liegt, kann ich auch nicht sagen, evtl. hilft ein
attr global verbose 5
beim lokalisieren.

[hgw]

das habe ich im log gefunden,

2012.08.09 14:40:04 1: /dev/ttyACM0 disconnected, waiting to reappear
2012.08.09 14:40:09 3: Setting CUL_0 baudrate to 38400
2012.08.09 14:40:09 1: /dev/ttyACM0 reappeared (CUL_0)

aber wieso geschieht das disconnect?

[Aleksandar Lazic]

Hi,

and a dmesg - output will be helpful.

[hgw]

Hi,

I found that part multiple times in the dmesg....


[363815.223238] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[363845.851993] usb 2-1: USB disconnect, address 17
[364029.665128] usb 2-1: new full speed USB device using ohci_hcd and address 18
[364029.943840] usb 2-1: New USB device found, idVendor=03eb, idProduct=204b
[364029.943862] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[364029.943878] usb 2-1: Product: CUL868
[364029.943891] usb 2-1: Manufacturer: busware.de
[364029.946847] usb 2-1: configuration #1 chosen from 1 choice
[364029.947973] cdc_acm 2-1:1.0: ttyACM0: USB ACM device

any idea?

[Aleksandar Lazic]

Could it be a defective contact?

How is the stick connected, does it hang over or lay it anywhere, ...?

[hgw]

As I can see in FHEM log the USB will be disconnected every 20minutes,

2012.08.09 14:00:36 1: /dev/ttyACM0 disconnected, waiting to reappear
2012.08.09 14:00:42 3: Setting CUL_0 baudrate to 38400
2012.08.09 14:00:42 1: /dev/ttyACM0 reappeared (CUL_0)
2012.08.09 14:20:04 1: /dev/ttyACM0 disconnected, waiting to reappear
2012.08.09 14:20:09 3: Setting CUL_0 baudrate to 38400
2012.08.09 14:20:09 1: /dev/ttyACM0 reappeared (CUL_0)

2012.08.09 14:40:04 1: /dev/ttyACM0 disconnected, waiting to reappear
2012.08.09 14:40:09 3: Setting CUL_0 baudrate to 38400
2012.08.09 14:40:09 1: /dev/ttyACM0 reappeared (CUL_0)

 I think, that cant't be a hardware problem :-/ To answer your question, the problem comes up in any case, it doesnt mater if the CUL is directly connected to the USB or with a cable.

[hgw]

OK here the long version of the disconnect logging message in FHEM with verbose 5

2012.08.09 14:55:01 4: /fhem?cmd=get+CUL_0+version / RL: 1807 / text/html; charset=UTF-8 /  /
2012.08.09 14:55:01 4: Connection closed for FHEMWEB:192.168.22.21:33896
2012.08.09 15:00:01 4: Connection accepted from FHEMWEB:192.168.22.21:33897
2012.08.09 15:00:01 4: HTTP FHEMWEB:192.168.22.21:33897 GET /fhem?cmd=get+CUL_0+version
2012.08.09 15:00:01 5: Cmd: >get CUL_0 version<
2012.08.09 15:00:01 5: SW: V
2012.08.09 15:00:04 1: /dev/ttyACM0 disconnected, waiting to reappear
2012.08.09 15:00:09 5: Triggering CUL_0 (1 changes)
2012.08.09 15:00:09 5: CUL_0 trigger: Checking FileLog_CUL_EM_5 for notify
2012.08.09 15:00:09 5: CUL_0 trigger: Checking FileLog_CUL_EM_6 for notify
2012.08.09 15:00:09 5: CUL_0 trigger: Checking FileLog_CUL_EM_7 for notify
2012.08.09 15:00:09 5: CUL_0 trigger: Checking Logfile for notify
2012.08.09 15:00:09 5: CUL_0 trigger: Checking WEB for notify
2012.08.09 15:00:09 5: CUL_0 trigger: Checking WEBphone for notify
2012.08.09 15:00:09 5: CUL_0 trigger: Checking WEBtablet for notify
2012.08.09 15:00:09 5: CUL_0 trigger: Checking autocreate for notify
2012.08.09 15:00:09 5: CUL_0 trigger: Checking initialUsbCheck for notify
2012.08.09 15:00:09 5: CUL_0 trigger: Checking telnetPort for notify
2012.08.09 15:00:09 4: /fhem?cmd=get+CUL_0+version / RL: 1803 / text/html; charset=UTF-8 /  /
2012.08.09 15:00:09 3: Setting CUL_0 baudrate to 38400
2012.08.09 15:00:09 1: /dev/ttyACM0 reappeared (CUL_0)
2012.08.09 15:00:09 5: SW: V
2012.08.09 15:00:09 5: CUL/RAW (ReadAnswer): V 1.46 CUL868

[Aleksandar Lazic]

Ok thanks.

maybe this can help you.

http://www.mjmwired.net/kernel/Documentation/usb/power-management.txt

###
148 power/autosuspend_delay_ms
149
150 This file contains an integer value, which is the
151 number of milliseconds the device should remain idle
152 before the kernel will autosuspend it (the idle-delay
153 time). The default is 2000. 0 means to autosuspend
154 as soon as the device becomes idle, and negative
155 values mean never to autosuspend. You can write a
156 number to the file to change the autosuspend
157 idle-delay time.
...
172 Changing the default idle-delay time
173 ------------------------------------
174
175 The default autosuspend idle-delay time (in seconds) is controlled
by
176 a module parameter in usbcore. You can specify the value when
usbcore
177 is loaded. For example, to set it to 5 seconds instead of 2 you
would
178 do:
179
180 modprobe usbcore autosuspend=5
181
182 Equivalently, you could add to a configuration file in
/etc/modprobe.d
183 a line saying:
184
185 options usbcore autosuspend=5
186
187 Some distributions load the usbcore module very early during the
boot
188 process, by means of a program or script running from an initramfs
189 image. To alter the parameter value you would have to rebuild that
190 image.
191
192 If usbcore is compiled into the kernel rather than built as a
loadable
193 module, you can add
194
195 usbcore.autosuspend=5
196
197 to the kernel's boot command line.
...
###

Cheers
Aleks

[Rudolf Koenig]

> OK here the long version of the disconnect logging message in FHEM with
> verbose 5

This won't help me. The read timed out, the DevIo layer reopened the device.
Now I'd like to know the cause of the timeout.

[hgw]

Hallo Leute,

Ich glaube ich habe die Lösung gefunden. Es war eine Einstellung im BIOS. Ich konnte mich erinnern das ich Probleme mit den USB Ports hatte als ich diese Option  eingeschaltet hatte. Die Option ist unter den Northbridge Einstellungen und heißt "Memory Power Down" Standardmäßig war das Deaktivieren aber ich hatte es aktiviert um ein paar Watt zu sparen. Jetzt nachdem ich die Option wieder Deaktiviert habe kommen die Funksignale der EM anscheinend wieder durch und der CUL USB schaltet sich nicht mehr aus. Ich hoffe das bleibt auch so :-)

Grüße HG   

[hgw]

Ich muss mich nochmal korrigieren, es sieht so aus als ob der Übeltäter doch nicht die BIOS-Einstellungen waren sondern meine einzige WindowsVM (WindowsXP). Nachdem ich diese gestartet hatte kamen die Probleme wieder hoch. Jetzt habe ich für diese VM das USB deaktiviert und jetzt gehts :-) Keine Ahnung was Windows mit den durchgereichten USB Ports macht aber es scheint das es diese nach 20min Inaktivität abschaltet was sich auf alle anderen VMs die auf USB zugreifen auswirkt :-/

so wäre das Problem gelöst :-)

Grüße HG.