CUL und eTrayz

[Guest]

Originally posted by: <email address deleted>

Hallo,

ich möchte fhem auf meiner eTrayz NAS nutzen. Für die Funkanbindung
soll der CUL Adapter von Busware verwendet werden. Die Installation
des CUL Adapters bereitet mir aber noch Schwierigkeiten.

Ich habe den Adapter zunächst erfolgreich auf einem Ubuntu-Notebook
(10.04, Kernel 2.6.32-34) getestet. Mittels ls /dev/tty* wird mir
unter anderem die Einheit ttyACM0 angezeigt. dmesg zeigt nach dem
Einstecken des CUL die folgenden zusätzlichen Einträge:
[ 3026.504056] usb 4-2: new full speed USB device using uhci_hcd and
address 3
[ 3026.689313] usb 4-2: configuration #1 chosen from 1 choice
[ 3026.742812] cdc_acm 4-2:1.0: ttyACM0: USB ACM device
[ 3026.745235] usbcore: registered new interface driver cdc_acm
[ 3026.745956] cdc_acm: v0.26:USB Abstract Control Model driver for
USB modems and ISDN adapters

Der CUL Adapter scheint also korrekt zu arbeiten. Nach dem Einstecken
des CUL in mein eTrayz (Kernel 2.6.24.4) wird die Einheit /dev/ttyACM0
nicht angezeigt. dmesg zeigt auch nur die beiden folgenden Einträge:
usb 1-1: new full speed USB device using oxnas-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice

Die Pendants der drei letzten Einträge der erfolgreichen Ubuntu-
Installation meines Notebooks fehlen also. Hat jemand eine Idee, was
falsch läuft?

Hier ist noch die Ausgabe des Befehls lsusb:
Bus 001 Device 003: ID 03eb:204b Atmel Corp.
Bus 001 Device 001: ID 0000:0000

Und hier die Ausgabe des Befehls cat /proc/bus/usb/devices:
T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 3
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.24.4 ehci_hcd
S:  Product=OXNAS EHCI Host Controller
S:  SerialNumber=usb
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=03eb ProdID=204b Rev= 0.00
S:  Manufacturer=busware.de
S:  Product=CUL868
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=(none)
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

Vielen Dank
Meniskusschaden

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

[Guest]

Originally posted by: <email address deleted>

Hallo Meniskusschaden,

auf deiner eTrayz fühlt sich kein Treiber für den CUL-Adapter zuständig. Ich schätze, der cdc_acm Treiber ist nicht vorhanden. Auf meinem openwrt Router konnte ich diesen Treiber über den Paketmanager nachinstallieren, und dann wurde auch /dev/ttyACM0 erzeugt...



On Oct 11, 2011, at 13:32 , Meniskusschaden wrote:

> Hallo,
>
> ich möchte fhem auf meiner eTrayz NAS nutzen. Für die Funkanbindung
> soll der CUL Adapter von Busware verwendet werden. Die Installation
> des CUL Adapters bereitet mir aber noch Schwierigkeiten.
>
> Ich habe den Adapter zunächst erfolgreich auf einem Ubuntu-Notebook
> (10.04, Kernel 2.6.32-34) getestet. Mittels ls /dev/tty* wird mir
> unter anderem die Einheit ttyACM0 angezeigt. dmesg zeigt nach dem
> Einstecken des CUL die folgenden zusätzlichen Einträge:
> [ 3026.504056] usb 4-2: new full speed USB device using uhci_hcd and
> address 3
> [ 3026.689313] usb 4-2: configuration #1 chosen from 1 choice
> [ 3026.742812] cdc_acm 4-2:1.0: ttyACM0: USB ACM device
> [ 3026.745235] usbcore: registered new interface driver cdc_acm
> [ 3026.745956] cdc_acm: v0.26:USB Abstract Control Model driver for
> USB modems and ISDN adapters
>
> Der CUL Adapter scheint also korrekt zu arbeiten. Nach dem Einstecken
> des CUL in mein eTrayz (Kernel 2.6.24.4) wird die Einheit /dev/ttyACM0
> nicht angezeigt. dmesg zeigt auch nur die beiden folgenden Einträge:
> usb 1-1: new full speed USB device using oxnas-ehci and address 2
> usb 1-1: configuration #1 chosen from 1 choice
>
> Die Pendants der drei letzten Einträge der erfolgreichen Ubuntu-
> Installation meines Notebooks fehlen also. Hat jemand eine Idee, was
> falsch läuft?
>
> Hier ist noch die Ausgabe des Befehls lsusb:
> Bus 001 Device 003: ID 03eb:204b Atmel Corp.
> Bus 001 Device 001: ID 0000:0000
>
> Und hier die Ausgabe des Befehls cat /proc/bus/usb/devices:
> T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 3
> B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
> D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=0000 ProdID=0000 Rev= 2.06
> S:  Manufacturer=Linux 2.6.24.4 ehci_hcd
> S:  Product=OXNAS EHCI Host Controller
> S:  SerialNumber=usb
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms
>
> T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
> D:  Ver= 1.10 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=03eb ProdID=204b Rev= 0.00
> S:  Manufacturer=busware.de
> S:  Product=CUL868
> C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=(none)
> E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
> E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
>
> Vielen Dank
> Meniskusschaden
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

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

[Guest]

Originally posted by: <email address deleted>

Hallo Leute,

leider hat mein CUN die Grätsche gemacht, weshalb ich für den Moment einen Ersatz-CUL in Betrieb nehmen wollte. Leider habe ich - seit ich diesen das letzte Mal an der Synology hatte - zwischendurch mal ein Firmware-Upgrade der Synology auf die Version 3.x gemacht und jetzt will diese nicht mehr mit dem CUL reden...

Also folgendes:

- Sicherheitshalber habe ich den CUL mit der aktuellen 1.4.3 nochmals geflasht (er wird am Mac auch als /dev/cu.usbmodem4411 erkannt

- an der Synology wird er gesehen, ich bekomme aber keinen Zugriff unter /dev/ttyXXXX.

lsusb sagt:
   Bus 001 Device 004: ID 03eb:204b Atmel Corp.
   Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
   Bus 001 Device 001: ID 1d6b:0002  


kernel-module-usbcore - 2.6.24-1 -
kernel-module-usbserial - 2.6.24-1 -
libftdi - 0.7-2

sind installiert.

lsmod sagt, dass usbcore läuft die anderen nicht - müssten hier nicht alle Module laufen?

Wenn ich versuche:

insmod /opt/lib/modules/2.6.24/kernel/drivers/usb/serial/usbserial.ko  erhalte ich als Fehler:  "-1 Invalid module format" (was hat das zu bedeuten?)

Ich bin kein Linux-Könner und kann mich dummerweise auch nicht mehr erinnern, wie ich das letztes Mal zum Laufen bekommen habe... vielleicht kann mir jemand sagen, was ich vergessen hab, oder wie ich die Sau zum Fliegen bekomme?

Danke

andy

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

[Guest]

Originally posted by: <email address deleted>

Andy,
Was hat das mit dem eTrayz-NAS zu tun?
Uli

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

[Guest]

Originally posted by: <email address deleted>

On Oct 11, 2011, at 15:40 , UliM wrote:

> Andy,
> Was hat das mit dem eTrayz-NAS zu tun?

anscheinend das gleiche Problem in einer anderen Umgebung: es fehlt das Kernel-Modul cdc_acm. Dieses erkennt einen cul ohne weiteres Zutun. Mit usbserial gehts dann so:

If your distribution does not have a cdc_acm module, you can force usbserial to handle the CUL by the following command:
modprobe usbserial vendor=0x03eb product=0x204b
In this case the device is most probably /dev/ttyUSB0.

siehe:

http://fhem.de/commandref.html#CUL

ulf


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

[Guest]

Originally posted by: <email address deleted>

Zunächst einmal vielen Dank an Ulf für die Hilfe.

Leider komme ich trotzdem nicht wirklich weiter. lsmod zeigt, dass das
Modul cdc_acm bei mir tatsächlich nicht geladen ist. Weiß jemand, wie
man das Modul auf dem eTrayz installieren kann?

Der andere Vorschlag (modprobe usbserial vendor=0x03eb product=0x204b)
führt bei mir zu folgender Fehlermeldung:
FATAL: Error inserting usbserial (/lib/modules/2.6.24.4/kernel/drivers/
usb/serial/usbserial.ko): Unknown symbol in module, or unknown
parameter (see dmesg)

dmesg zeigt dazu folgende Meldung:
usbserial: Unknown parameter `vendor'

Rufe ich stattdessen folgenden modprobe-Befehl auf, so erhalte ich
keine Fehlermeldung:
modprobe ftdi_sio vendor=0x03eb product=0x204b

Allerdings wird trotzdem keine Einheit im Verzeichnis /dev erstellt.
lsmod zeigt danach folgendes Bild:
Module                  Size  Used by
ftdi_sio               33800  0
usbserial              28040  1 ftdi_sio
ehci_hcd               31724  0
ntfs                  104036  0
vfat                   10240  0
pcbc                    4096  0
michael_mic             2336  0
aes_generic            34216  0
rng_core                4228  0
ecb                     2752  0
arc4                    1664  0
gmac                   26928  0
mii                     6144  1 gmac
usbcore               121940  4 ftdi_sio,usbserial,ehci_hcd

Gibt es noch weitere Ideen?

Vielen Dank und Grüße
Meniskusschaden

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

[rudolfkoenig]

                                                   

> FATAL: Error inserting usbserial (/lib/modules/2.6.24.4/kernel/drivers/
> usb/serial/usbserial.ko): Unknown symbol in module, or unknown
> parameter (see dmesg)

"Dein" usbserial.ko ist nicht fuer die Linux Kernel Version gebaut, deswegen
kann man es auch nicht laden.


> Rufe ich stattdessen folgenden modprobe-Befehl auf, so erhalte ich
> keine Fehlermeldung:
> modprobe ftdi_sio vendor=0x03eb product=0x204b

Das ist zwar toll, aber ein CUL kann damit nicht empfangen werden, steht auch
nicht in der Beschreibung. Ueber ftdi_sio.ko koennte man mit einem FHZ "reden".


> Gibt es noch weitere Ideen?

cdc_acm.ko besorgen.  Meiner Ansicht nach ist das kein fhem Problem, und
offensichtlich gibt es hier in der Gruppe keiner der das Loesen kann oder will.

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

[Guest]

Originally posted by: <email address deleted>

On Oct 12, 2011, at 9:31 , Rudolf Koenig wrote:

>> FATAL: Error inserting usbserial (/lib/modules/2.6.24.4/kernel/drivers/
>> usb/serial/usbserial.ko): Unknown symbol in module, or unknown
>> parameter (see dmesg)
>
> "Dein" usbserial.ko ist nicht fuer die Linux Kernel Version gebaut, deswegen
> kann man es auch nicht laden.

das bezweifle ich, denn das ftdi_sio Modul benutzt auch usbserial und konnte das Laden von usbserial triggern (siehe lsmod Augabe). Ich würde eher:

> dmesg zeigt dazu folgende Meldung:
> usbserial: Unknown parameter `vendor'

trauen, und es scheint so, dass die Parameter-Übergabe an usbserial beim Laden nicht funktioniert. Da aber sogar in der Original-Kernel-Dokumentation ein solches Vorgehen vorgeschlagen wird (und in anderen Linux-Installationen auch funktioniert), wird's schwer, irgendwelche anderen Tips zu geben als nach dem cdc_acm Module zu fanden.

viele Grüsse

ulf


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

[Guest]

Originally posted by: <email address deleted>

Moin!

Bin mir nicht sicher, ob ich Dir helfen kann, aber ich hatte mir für
meine DS 209 mal ein Script geschrieben (bis ich den CUL rausgeworfen
hatte und gegen einen CUNO getauscht hatte - wegen ewigen
Disconnects):

----------------------------------------------------------

#!/bin/sh
/bin/chmod 666 /dev/usb/ttyUSB0
/bin/chmod 666 /dev/usb/ttyUSB1
/sbin/rmmod usbserial.ko
/bin/sleep 1
/sbin/insmod usbserial.ko vendor=0x03eb product=0x204b
/bin/sleep 1
/usr/syno/synoman/webman/3rdparty/fhem/fhem.pl /usr/syno/synoman/
webman/3rdparty/fhem/var/fhem.cfg
/bin/sleep 1
/usr/syno/synoman/webman/3rdparty/fhem/fhem.pl 7072 "rereadcfg"

----------------------------------------------------------

Allerdings hatte ich mir sehr umständlich das passende Kernel Modul
(für meine Version) über einen polnischen
Server besorgt. Man muss Glück haben, dass man die richtige Version
findet;-)

Gruss,
alochter

On 12 Okt., 11:39, Ulf Behrens wrote:
> On Oct 12, 2011, at 9:31 , Rudolf Koenig wrote:
>
> >> FATAL: Error inserting usbserial (/lib/modules/2.6.24.4/kernel/drivers/
> >> usb/serial/usbserial.ko): Unknown symbol in module, or unknown
> >> parameter (see dmesg)
>
> > "Dein" usbserial.ko ist nicht fuer die Linux Kernel Version gebaut, deswegen
> > kann man es auch nicht laden.
>
> das bezweifle ich, denn das ftdi_sio Modul benutzt auch usbserial und konnte das Laden von usbserial triggern (siehe lsmod Augabe). Ich würde eher:
>
> > dmesg zeigt dazu folgende Meldung:
> > usbserial: Unknown parameter `vendor'
>
> trauen, und es scheint so, dass die Parameter-Übergabe an usbserial beim Laden nicht funktioniert. Da aber sogar in der Original-Kernel-Dokumentation ein solches Vorgehen vorgeschlagen wird (und in anderen Linux-Installationen auch funktioniert), wird's schwer, irgendwelche anderen Tips zu geben als nach dem cdc_acm Module zu fanden.
>
> viele Grüsse
>
> ulf

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

[Guest]

Originally posted by: <email address deleted>

Hallo Arne,

tja - ich erinnere mich noch dran, als Du mit dem CUL angefangen hast, hatte ich Dir den CUN empfohlen, weil ich mit dem CUL  an der Syno auch keine stabile Verbindung aufbauen konnte Allerdings GING ES damals bei mir an der Syno auch mit dem CUL (das war allerdings VOR dem Firmware-Upgrade auf 3.x).

Ich hab' jetzt bei Dirk einen CUNO bestellt und hab' einen CUL an meinen MacOS X Server gesteckt und fhem installiert, so dass ich die Zeit bis zum eintreffen des CUNO auch so überbrücken kann. Alles andere ist mir einfach zu blöd :-/

Trotzdem vielen Dank für Dein Script, aber ich glaube meine Leidensfähigkeit ist nicht groß genug

Grüße

andy





Am 12.10.2011 um 11:58 schrieb fhem-fighter:

> Moin!
>
> Bin mir nicht sicher, ob ich Dir helfen kann, aber ich hatte mir für
> meine DS 209 mal ein Script geschrieben (bis ich den CUL rausgeworfen
> hatte und gegen einen CUNO getauscht hatte - wegen ewigen
> Disconnects):
>
> ----------------------------------------------------------
>
> #!/bin/sh
> /bin/chmod 666 /dev/usb/ttyUSB0
> /bin/chmod 666 /dev/usb/ttyUSB1
> /sbin/rmmod usbserial.ko
> /bin/sleep 1
> /sbin/insmod usbserial.ko vendor=0x03eb product=0x204b
> /bin/sleep 1
> /usr/syno/synoman/webman/3rdparty/fhem/fhem.pl /usr/syno/synoman/
> webman/3rdparty/fhem/var/fhem.cfg
> /bin/sleep 1
> /usr/syno/synoman/webman/3rdparty/fhem/fhem.pl 7072 "rereadcfg"
>
> ----------------------------------------------------------
>
> Allerdings hatte ich mir sehr umständlich das passende Kernel Modul
> (für meine Version) über einen polnischen
> Server besorgt. Man muss Glück haben, dass man die richtige Version
> findet;-)
>
> Gruss,
> alochter
>
> On 12 Okt., 11:39, Ulf Behrens wrote:
>> On Oct 12, 2011, at 9:31 , Rudolf Koenig wrote:
>>
>>>> FATAL: Error inserting usbserial (/lib/modules/2.6.24.4/kernel/drivers/
>>>> usb/serial/usbserial.ko): Unknown symbol in module, or unknown
>>>> parameter (see dmesg)
>>
>>> "Dein" usbserial.ko ist nicht fuer die Linux Kernel Version gebaut, deswegen
>>> kann man es auch nicht laden.
>>
>> das bezweifle ich, denn das ftdi_sio Modul benutzt auch usbserial und konnte das Laden von usbserial triggern (siehe lsmod Augabe). Ich würde eher:
>>
>>> dmesg zeigt dazu folgende Meldung:
>>> usbserial: Unknown parameter `vendor'
>>
>> trauen, und es scheint so, dass die Parameter-Übergabe an usbserial beim Laden nicht funktioniert. Da aber sogar in der Original-Kernel-Dokumentation ein solches Vorgehen vorgeschlagen wird (und in anderen Linux-Installationen auch funktioniert), wird's schwer, irgendwelche anderen Tips zu geben als nach dem cdc_acm Module zu fanden.
>>
>> viele Grüsse
>>
>> ulf
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

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

[Guest]

Originally posted by: <email address deleted>

Hallo Leute,

ich hätte eine kurze Frage, die eigentlich nichts mit fhem zu tun hat, aber ich denke, hier sind die Leute, die sich mit sowas auskennen.

Ich brauche einen programmierbaren Heizkörper-Thermostat (stand-alone), mit dem ich zeitgesteuert die Temperatur regeln kann. Im Internet hab ich massenhaft Heizkörper-Thermostaten gefunden, wie z.B. den Honeywell HR-20 Rondostat  oder den ELV ETH eco).

Kann mir jemand einen empfehlen, der einfach zu bedienen ist und funktioniert (ist für eine Frau )

Grüße & Danke

andy

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

[Guest]

Originally posted by: <email address deleted>

Hi,

ja stimmt, wir hatten damals gechatted;-)
Ich kann Dich gut verstehen. Das verschlingt einfach zu viel Zeit.
Aktuell kämpfe ich gerade mit einem FHT8V, der meint, er müsste nur
alle paar Stunden mal einen neuen Wert einstellen. Das ist echt
ätzend, denn die Technik an sich finde ich nach wie vor total
spannend.

Viele Grüsse
Arne


On 12 Okt., 13:24, Andy Fuchs wrote:
> Hallo Arne,
>
> tja - ich erinnere mich noch dran, als Du mit dem CUL angefangen hast, hatte ich Dir den CUN empfohlen, weil ich mit dem CUL  an der Syno auch keine stabile Verbindung aufbauen konnte Allerdings GING ES damals bei mir an der Syno auch mit dem CUL (das war allerdings VOR dem Firmware-Upgrade auf 3.x).
>
> Ich hab' jetzt bei Dirk einen CUNO bestellt und hab' einen CUL an meinen MacOS X Server gesteckt und fhem installiert, so dass ich die Zeit bis zum eintreffen des CUNO auch so überbrücken kann. Alles andere ist mir einfach zu blöd :-/
>
> Trotzdem vielen Dank für Dein Script, aber ich glaube meine Leidensfähigkeit ist nicht groß genug
>
> Grüße
>
> andy
>
> Am 12.10.2011 um 11:58 schrieb fhem-fighter:
>
> > Moin!
>
> > Bin mir nicht sicher, ob ich Dir helfen kann, aber ich hatte mir für
> > meine DS 209 mal ein Script geschrieben (bis ich den CUL rausgeworfen
> > hatte und gegen einen CUNO getauscht hatte - wegen ewigen
> > Disconnects):
>
> > ----------------------------------------------------------
>
> > #!/bin/sh
> > /bin/chmod 666 /dev/usb/ttyUSB0
> > /bin/chmod 666 /dev/usb/ttyUSB1
> > /sbin/rmmod usbserial.ko
> > /bin/sleep 1
> > /sbin/insmod usbserial.ko vendor=0x03eb product=0x204b
> > /bin/sleep 1
> > /usr/syno/synoman/webman/3rdparty/fhem/fhem.pl /usr/syno/synoman/
> > webman/3rdparty/fhem/var/fhem.cfg
> > /bin/sleep 1
> > /usr/syno/synoman/webman/3rdparty/fhem/fhem.pl 7072 "rereadcfg"
>
> > ----------------------------------------------------------
>
> > Allerdings hatte ich mir sehr umständlich das passende Kernel Modul
> > (für meine Version) über einen polnischen
> > Server besorgt. Man muss Glück haben, dass man die richtige Version
> > findet;-)
>
> > Gruss,
> > alochter
>
> > On 12 Okt., 11:39, Ulf Behrens wrote:
> >> On Oct 12, 2011, at 9:31 , Rudolf Koenig wrote:
>
> >>>> FATAL: Error inserting usbserial (/lib/modules/2.6.24.4/kernel/drivers/
> >>>> usb/serial/usbserial.ko): Unknown symbol in module, or unknown
> >>>> parameter (see dmesg)
>
> >>> "Dein" usbserial.ko ist nicht fuer die Linux Kernel Version gebaut, deswegen
> >>> kann man es auch nicht laden.
>
> >> das bezweifle ich, denn das ftdi_sio Modul benutzt auch usbserial und konnte das Laden von usbserial triggern (siehe lsmod Augabe). Ich würde eher:
>
> >>> dmesg zeigt dazu folgende Meldung:
> >>> usbserial: Unknown parameter `vendor'
>
> >> trauen, und es scheint so, dass die Parameter-Übergabe an usbserial beim Laden nicht funktioniert. Da aber sogar in der Original-Kernel-Dokumentation ein solches Vorgehen vorgeschlagen wird (und in anderen Linux-Installationen auch funktioniert), wird's schwer, irgendwelche anderen Tips zu geben als nach dem cdc_acm Module zu fanden.
>
> >> viele Grüsse
>
> >> ulf
>
> > --
> > To unsubscribe from this group, send email to
> > fhem-users+unsubscribe@googlegroups.com

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

[Guest]

Originally posted by: <email address deleted>

Hi Arne,

genau aus dem Grund verwende ich ein paar FTH80c - mein Vertrauen in die FHT8V allein ist noch nicht groß genug (obwohl ich hier ein paar rumliegen hätte, die mich ständig angucken )

Was sind denn sonst so Deine Erfahrungen mit den FHT8Vs? (Neuer Thread?)

Grüße

andy


Am 12.10.2011 um 14:05 schrieb fhem-fighter:

> Hi,
>
> ja stimmt, wir hatten damals gechatted;-)
> Ich kann Dich gut verstehen. Das verschlingt einfach zu viel Zeit.
> Aktuell kämpfe ich gerade mit einem FHT8V, der meint, er müsste nur
> alle paar Stunden mal einen neuen Wert einstellen. Das ist echt
> ätzend, denn die Technik an sich finde ich nach wie vor total
> spannend.
>
> Viele Grüsse
> Arne
>
>
> On 12 Okt., 13:24, Andy Fuchs wrote:
>> Hallo Arne,
>>
>> tja - ich erinnere mich noch dran, als Du mit dem CUL angefangen hast, hatte ich Dir den CUN empfohlen, weil ich mit dem CUL  an der Syno auch keine stabile Verbindung aufbauen konnte Allerdings GING ES damals bei mir an der Syno auch mit dem CUL (das war allerdings VOR dem Firmware-Upgrade auf 3.x).
>>
>> Ich hab' jetzt bei Dirk einen CUNO bestellt und hab' einen CUL an meinen MacOS X Server gesteckt und fhem installiert, so dass ich die Zeit bis zum eintreffen des CUNO auch so überbrücken kann. Alles andere ist mir einfach zu blöd :-/
>>
>> Trotzdem vielen Dank für Dein Script, aber ich glaube meine Leidensfähigkeit ist nicht groß genug
>>
>> Grüße
>>
>> andy
>>
>> Am 12.10.2011 um 11:58 schrieb fhem-fighter:
>>
>>> Moin!
>>
>>> Bin mir nicht sicher, ob ich Dir helfen kann, aber ich hatte mir für
>>> meine DS 209 mal ein Script geschrieben (bis ich den CUL rausgeworfen
>>> hatte und gegen einen CUNO getauscht hatte - wegen ewigen
>>> Disconnects):
>>
>>> ----------------------------------------------------------
>>
>>> #!/bin/sh
>>> /bin/chmod 666 /dev/usb/ttyUSB0
>>> /bin/chmod 666 /dev/usb/ttyUSB1
>>> /sbin/rmmod usbserial.ko
>>> /bin/sleep 1
>>> /sbin/insmod usbserial.ko vendor=0x03eb product=0x204b
>>> /bin/sleep 1
>>> /usr/syno/synoman/webman/3rdparty/fhem/fhem.pl /usr/syno/synoman/
>>> webman/3rdparty/fhem/var/fhem.cfg
>>> /bin/sleep 1
>>> /usr/syno/synoman/webman/3rdparty/fhem/fhem.pl 7072 "rereadcfg"
>>
>>> ----------------------------------------------------------
>>
>>> Allerdings hatte ich mir sehr umständlich das passende Kernel Modul
>>> (für meine Version) über einen polnischen
>>> Server besorgt. Man muss Glück haben, dass man die richtige Version
>>> findet;-)
>>
>>> Gruss,
>>> alochter
>>
>>> On 12 Okt., 11:39, Ulf Behrens wrote:
>>>> On Oct 12, 2011, at 9:31 , Rudolf Koenig wrote:
>>
>>>>>> FATAL: Error inserting usbserial (/lib/modules/2.6.24.4/kernel/drivers/
>>>>>> usb/serial/usbserial.ko): Unknown symbol in module, or unknown
>>>>>> parameter (see dmesg)
>>
>>>>> "Dein" usbserial.ko ist nicht fuer die Linux Kernel Version gebaut, deswegen
>>>>> kann man es auch nicht laden.
>>
>>>> das bezweifle ich, denn das ftdi_sio Modul benutzt auch usbserial und konnte das Laden von usbserial triggern (siehe lsmod Augabe). Ich würde eher:
>>
>>>>> dmesg zeigt dazu folgende Meldung:
>>>>> usbserial: Unknown parameter `vendor'
>>
>>>> trauen, und es scheint so, dass die Parameter-Übergabe an usbserial beim Laden nicht funktioniert. Da aber sogar in der Original-Kernel-Dokumentation ein solches Vorgehen vorgeschlagen wird (und in anderen Linux-Installationen auch funktioniert), wird's schwer, irgendwelche anderen Tips zu geben als nach dem cdc_acm Module zu fanden.
>>
>>>> viele Grüsse
>>
>>>> ulf
>>
>>> --
>>> To unsubscribe from this group, send email to
>>> fhem-users+unsubscribe@googlegroups.com
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

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