CUL EM Verbindungsabbrüche

[Guest]

Originally posted by: <email address deleted>

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 ) 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

Am Donnerstag, 9. August 2012 12:41:32 UTC+2 schrieb 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.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Donnerstag, 9. August 2012 09:25:48 UTC+2 schrieb 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 ) 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.
>

Am Donnerstag, 9. August 2012 09:25:48 UTC+2 schrieb 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 ) 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.
>

Am Donnerstag, 9. August 2012 09:25:48 UTC+2 schrieb 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 ) 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.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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.....

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> */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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi,

On 09-08-2012 14:43, Rudolf Koenig wrote:
>> */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.

and a dmesg - output will be helpful.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On 09-08-2012 14:50, hgw wrote:

> 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?

Could it be a defective contact?

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com