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
> 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
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
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
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
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
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
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
> */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
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
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
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
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
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
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
Originally posted by: <email address deleted>
On 09-08-2012 15:04, hgw wrote:
> 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.
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com