sorry, bin gerade etwas enthusiasmiert, nachdem ich zuerst einen FS20/CUL zum Laufen gebracht habe und heute dann den TPUART für EIB/KNX, bekomme ich nicht beide gleichzeitig zum Laufen.
Wie bin ich vorgegangen: Erst den FS20/CUL eingebunden - läuft. Ausgestöpselt, TPUART rein, läuft (als CUL_0). Jetzt hab ich einen normalen USB-Hub genommen und beide angeschlossen, es wird weiterhin nur der TPUART als CUL_0 erkannt.
Brauchts da einen speziellen USB-Hub oder muss ich den FS20/CUL jetzt manuell erkennen lassen / einbinden?
VG, Dieter
Hallo Dieter,
probier mal, die Geräte mit Hilfe der
vendor und product ID einzubinden, siehe auch in diesem Thread (//groups.google.com/forum/#!msg/fhem-users/-k66JW0fAVE/75QSAWytMPsJ):
Infos über die IDs bekommst Du auf der Konsole mit
lsusb. Im Thread wird ein CUL und ein seriell Wandler mit FFTDI Chip verwendet. Ich vermute, CUL und TPUART brauchen dieselben Treiber, daher musst Du vermutlich
ftdi_sio durch ein zweites
usbserial ersetzen.
Zitatmodprobe usbserial vendor=0x03eb product=0x204b
modprobe ftdi_sio vendor=0x0403 product=0x6001
Bitte berichte dann, ob es funktioniert. Welche Fritz Box hast Du?
Gruß Peter
Danke Peter, werd ich heut Nachmittag testen. Ich hab die Fritz!Box 7390 mit der aktuellen AVM Labor und dem SVN FHEM
VG, Dieter
Zitat von: PeMue schrieb am Do, 06 Juni 2013 08:37Welche Fritz Box hast Du?
steht auch in meiner Sig ;-))
Hallo,
das
ZitatIch hab die Fritz!Box 7390 mit der aktuellen AVM Labor und dem SVN FHEM
glaube ich weniger.
Entweder die AVM-Labor ODER fhem.de
Beides zugleich schliesst sich aus da das SVN FHEM (soweit ich weiß) die Labor überschreibt und umgekehrt.
Um einen ordentlichen Zustand herzustellen (und auch die Pfade korrekt zu erhalten) würde ich dir vorschlagen die Box neu
aufzusetzen und ausschliesslich die Version 5.4 von fhem.de zu verwenden.
Grüße
Ein paar Berichtigungen:
Da das AVM-Labor in einem chroot laeuft, muss man hier alle /dev/* Dateien selbst anlegen. Das akutelle AVM startscript erstellt fuer 2 von dem cdc-acm.ko Modul betreuten Geraete /dev/ttyACMx Dateien, und 2 fuer die ftdi_sio/usbserial (/dev/ttyUSBx) in dieser chroot Umgebung. Bei der fhem.de Version entfaellt chroot, und hier legen die ueblichen Linux-Mechanismen die neu eingesteckten Geraete automatisch als /dev/xxx an.
Ein CUL benoetigt das cdc-acm.ko Modul, notfalls(!) scheint es auch mit usbserial.ko zu funktionieren. ftdi_sio.ko wird von anderen Geraeten (FHZ1300, EM1010PC) benoetigt.
Man kann eine AVM Version (unter anderem per update) auf den aktuellen SVN-Stand bringen, die per chroot "geerbten" Vorteile bzw. Probleme bleiben dadurch aber bestehen.
Da im urpruenglichen Fall die Geraete jeweils einzeln funktionieren, vermute ich ich hier ein Problem mit der Stromversorgung.
Zitat von: Puschel74 schrieb am Do, 06 Juni 2013 09:15ZitatIch hab die Fritz!Box 7390 mit der aktuellen AVM Labor und dem SVN FHEM
glaube ich weniger.
Entweder die AVM-Labor ODER fhem.de
sorry, ich hab mich undeutlich ausgedrückt. Mit "Labor" meinte ich die Firmware für die Fritz!Box selbst. Was FHEM betrifft hatte ich zunächst das AVM-FHEM und jetzt das SVN-FHEM drauf, mag sein, dass ich ein paar Einschränkungen geerbt habe ...
Zitat von: rudolfkoenig schrieb am Do, 06 Juni 2013 10:01Da im urpruenglichen Fall die Geraete jeweils einzeln funktionieren, vermute ich ich hier ein Problem mit der Stromversorgung.
Ich denke eher, mein Problem liegt daran, dass ich mein System für den FS20 CUL konfiguriert hatte, dann den CUL abgezogen und den TUL (erfolgreich) eingebunden hatte. Selbst wenn ich den ursprünglich konfigurierten FS20/CUL jetzt
alleine anstecke, läuft er nicht mehr. Ich muss iwie meine fhem.conf wieder in die Reihe bringen.
Neu aufsetzen wäre zwar eine Möglichkeit, aber da jetzt EIB so schön läuft, würde ich dies nur ungern machen.
Dieter
Hallo,
Zitat von: grappa24 schrieb am Do, 06 Juni 2013 10:16Zitat von: Puschel74 schrieb am Do, 06 Juni 2013 09:15ZitatIch hab die Fritz!Box 7390 mit der aktuellen AVM Labor und dem SVN FHEM
glaube ich weniger.
Entweder die AVM-Labor ODER fhem.de
sorry, ich hab mich undeutlich ausgedrückt. Mit "Labor" meinte ich die Firmware für die Fritz!Box selbst. Was FHEM betrifft hatte ich zunächst das AVM-FHEM und jetzt das SVN-FHEM drauf, mag sein, dass ich ein paar Einschränkungen geerbt habe ...
Das AVM-FHEM
ist die Labor-Firmwareversion von AVM.
Oder bietet AVM die FHEM-Version schon in der regulären Firmware an?
Wie Rudi schon geschrieben hat:
ZitatMan kann eine AVM Version (unter anderem per update) auf den aktuellen SVN-Stand bringen, die per chroot "geerbten" Vorteile bzw. Probleme bleiben dadurch aber bestehen.
Das hat aber jetzt mit deinem Problem nichts zu tun.
Um die chroot-"Vorteile" (welche wären das?) -Probleme zu eliminieren würde ich dir dennoch raten die Box jungfräulich zu machen und nur
die Version von
fhem.de (bzw. aus dem SVN) zu verwenden und diese per update auf den letzten Stand zu bringen (SVN ist schon der letzte aktuelle Stand).
Die fhem.cfg (inkl. aller darin enthaltenen includes) sichern und danach einfach wieder einspielen.
Aber jeder so wie er mag ;-)
Grüße
Zitat von: Puschel74 schrieb am Do, 06 Juni 2013 10:25Das AVM-FHEM ist die Labor-Firmwareversion von AVM.
Oder bietet AVM die FHEM-Version schon in der regulären Firmware an?
Die FBF hat doch eine eigene Firmware, die gibts als offizielles Release oder alternativ als Labor-Version. Weder in der einen noch in der anderen Variante ist das AVM-FHEM enthalten. Dieses kommt in Form einer Pseudo-Laborversion von AVM dazu, oder halt das SVN-FHEM
Zitat... würde ich dir dennoch raten die Box jungfräulich zu machen und nur
die Version von fhem.de (bzw. aus dem SVN) zu verwenden und diese per update auf den letzten Stand zu bringen (SVN ist schon der letzte aktuelle Stand).
gut, ich wär dazu bereit. fhem.cfg sicher/einspielen ist soweit klar, aber wie bekomme ich die Reste vom alten AVM-FHEM weg, was heißt "jungfräulich machen" konkret?
Dieter
Hallo,
klar hat die FB eine Firmware drauf - sonst würde ja Internet/Telefon und das drum herum nicht funktionieren.
Das ist die "Release-Firmware", wie du sie nennst.
In dieser ist FHEM natürlich nicht enthalten.
ZitatWeder in der einen noch in der anderen Variante ist das AVM-FHEM enthalten
In der Laborfirmware allerdings sehr wohl - da es FHEM (als Hausautomation wie es AVM nennt) nicht in der Release gibt.
siehe hier:
(siehe Anhang / see attachement)
Wobei die Labor-Firmware, wie schon gesagt, AVM-FHEM ist.
ZitatDieses kommt in Form einer Pseudo-Laborversion von AVM dazu
Das ist keine Pseudo-Laborversion, siehe oben, sondern das ist
die Laborversion Hausautomation.
Zitataber wie bekomme ich die Reste vom alten AVM-FHEM weg, was heißt "jungfräulich machen" konkret?
Für deine FritzBox gibt es ein Recovery-Image.
Entweder auf der zugehörigen CD oder auf dem AVM-ftp-Server.
Dieses Recovery-Image einspielen und deine FB ist "jungfräulich".
Bitte unbedingt an die Hinweise auf dem Bildschirm halten!!
Jungfräulich heisst hier - so wie kurz nach dem Auspacken vor dem ersten Anstöpseln (bzw. der ersten Konfiguration).
Wenn du dir vorher noch ein Backup der FB anlegst (Achtung! Passwort für das Backup vergeben sonst kann es Probleme beim wieder einspielen des Backup geben) solltest du deine Telefonie/Interneteinstellungen damit wieder herstellen können.
Welche Einstellungen damit genau wieder hergestellt werden können weiß ich leider nicht da ich das Recovery nur benötigt habe
um meine Fritz!Box(en) wieder in den Urspungszustand zu bekommen.
Die Konfiguration habe ich dann jeweils wieder "von Hand" durchgeführt.
Eine vorhandene Labor-Firmware wird durch dieses Backup nicht wieder hergestellt.
Grüße
Zitat von: Puschel74 schrieb am Do, 06 Juni 2013 11:26klar hat die FB eine Firmware drauf - sonst würde ja Internet/Telefon und das drum herum nicht funktionieren. Das ist die "Release-Firmware", wie du sie nennst.
ja, ich hab aber
nicht die aktuelle offizielle Firmware 84.05.50 drauf, sondern die Laborversion 84.05.55-25409. Dazu - und nicht statt dessen - hatte ich dann die FHEM Laborfirmware installiert und dann diese mittlerweile durch SVN-FHEM ersetzt.
Ich hatte das auch erst nicht verstanden, die AVM-FHEM Laborfirmware ersetzt nicht die normale Firmware (plus FHEM), sondern wird zu der bestehenden Original- oder Laborfirmware
dazugeladen. AVM ist hier inkonsistent bzgl. der Definition "Laborfirmware" ...
Ich bin der Meinung, wenn ich jetzt ein Revorery-Image von AVM (84.05.50) drüberbügle, dass die gesamte FHEM Welt incl. der Reste der alten AVM-FHEM Installation bestehen bleibt und nur meine AVM Laborfirmware 84.05.55-25409 weg ist.
Hallo,
Zitatja, ich hab aber nicht die aktuelle offizielle Firmware 84.05.50 drauf, sondern die Laborversion 84.05.55-25409. Dazu - und nicht statt dessen - hatte ich dann die FHEM Laborfirmware installiert
Hier scheint AVM nachgebessert/umgebaut zu haben.
Mein Wissensstand war noch das sich Laborversionen gegenseitig ausschliessen.
Zitatdie AVM-FHEM Laborfirmware ersetzt nicht die normale Firmware (plus FHEM), sondern wird zu der bestehenden Original- oder Laborfirmware dazugeladen
Eine normale Firmware plus FHEM gibt es nicht.
Es gibt nur die normale Firmware plus die Laborversion Hausautomation.
Hier hast du aber recht. Die Laborfirmware wird
zusätzlich zur normalen Firmware installiert und nicht stattdessen.
ZitatAVM ist hier inkonsistent bzgl. der Definition "Laborfirmware" ...
Inwiefern?
Es gibt die normale Firmware mit den Grundfunktionen der Box und eine bzw. mehrere Laborfirmware (welche übrigens nicht von AVM supportet werden).
ZitatIch bin der Meinung, wenn ich jetzt ein Revorery-Image von AVM (84.05.50) drüberbügle, dass die gesamte FHEM Welt incl. der Reste der alten AVM-FHEM Installation bestehen bleibt und nur meine AVM Laborfirmware 84.05.55-25409 weg ist.
Und da liegst du (verzeih mir bitte) falsch da durch das Recovery die Speicherbereiche mtd(0-3 wenn mich nicht alles täuscht) überschrieben werden und deine FB dadurch wieder in den Auslieferungszustand versetzt wird.
Auch wenn es schon länger her ist hatte ich auf meinen Boxen auch diverse Laborversionen und auch Freetz installiert.
Sollte AVM das Recovery nicht umgebaut haben bleibt es so wie oben beschrieben.
Nach dem Recovery ist deine FB wieder wie kurz nach dem auspacken.
Wenn du willst kannst du ja auf http://www.ip-phone-forum.de/forumdisplay.php?f=361&s=180ba588df84f8499177c8a1dd05ee7b (//www.ip-phone-forum.de/forumdisplay.php?f=361&s=180ba588df84f8499177c8a1dd05ee7b) das ganze nochmal nachlesen.
Die Beiträge habe ich nicht extra rausgesucht - evtl. kannst du ja auch dort über die SuFu die Beiträge ausfindig machen.
Grüße
P.S.: Das Recovery trägt übrigens den Namen fritz.box_wlan_7390_84.02.05.recover-image.exe (evtl. gibt es schon eine neuere - ich habe jetzt nicht auf dem ftp-Server von AVM nachgeschaut) und wird NICHT wie ein Image auf die Box geladen.
Diese .exe musst du ausführen und die Box und deinen Rechner in ein eigenes Netz bringen resp. am Rechner die passende IP einstellen (aus dem Range der Box).
Das wird dir aber alles während der Ausführung des Recovery erklärt
Hallo Dieter,
sorry, habe Deine Signatur übersehen. Die Fritz Box 7390 kann schon modprobe, d.h. aus meinem obigen Post insmod durch modprobe ersetzen. Das Anlagen der /dev/tty<x> müsste auf dieser Box auch automatisch erfolgen. Bei der alten Fritz Box 7170 muss dies noch durch mknod, etc. erfolgen.
Gruß Peter
Zitat von: PeMue schrieb am Do, 06 Juni 2013 08:37Hallo Dieter,
probier mal, die Geräte mit Hilfe der vendor und product ID einzubinden, siehe auch in diesem Thread:
Infos über die IDs bekommst Du auf der Konsole mit lsusb. Im Thread wird ein CUL und ein seriell Wandler mit FFTDI Chip verwendet. Ich vermute, CUL und TPUART brauchen dieselben Treiber, daher musst Du vermutlich ftdi_sio durch ein zweites usbserial ersetzen.
Zitatmodprobe usbserial vendor=0x03eb product=0x204b
modprobe ftdi_sio vendor=0x0403 product=0x6001
Bitte berichte dann, ob es funktioniert. Welche Fritz Box hast Du?
Mein CUL und mein TPUART werden beide am USB-Port/HUB erkannt, sind beide von
busware.de und haben beide die VID 03eb und beide die PID 204b. Der einzige Unterschied ist DEV 003 bzw. DEV 004.
Da der TPUART ja als dev/ttyACM0 gelaufen ist, heißt das, dass ich jetzt mit modprobe usbserial vendor=03eb product=204b nur noch ein serielles Device anlegen muss und der CUL wird erkannt? VID und PID mit 0x prefix verwenden?
VG, Dieter
Hallo Dieter,
klar, die Device ID und die Vendor ID sind direkt in die Module einkompiliert und müssen gleich sein, da beide von busware (Denkfehler von mir).
Ich würde es mal mit
modprobe usbserial vendor=0x03eb product=0x204b device=0x0003
modprobe usbserial vendor=0x03eb product=0x204b device=0x0004
probieren, aber das ist eher geraten. Dann müsste der erste unter /dev/ttyUSB0 und der zweite unter /dev/ttyUSB1 angemeldet werden. Ggf. erst einmal auf der Konsole probieren und schauen, welche Fehlermeldungen kommen und dann in startfhem.sh eintragen.
Das Problem ist, der Fritz Box mitzuteilen, welches Gerät auf welcher Schnittstelle hängen soll bzw. dass da zwei Geräte hängen. Wenn die beiden IDs gleich sind, braucht es andere Unterscheidungsmerkmale ...
Gruß PeMue
cool, jetzt gibts
CUL_0 opened ACM0 und EIB zugeordnet, EIB Geräte lassen sich schalten
CUL_1 initialized ACM1 aber iwie fehlt die FS20 Zuordnung und die Sensoren lassen sich nicht schalten
... war das dann mit obigem Code? Wäre gut zu wissen, ob meine Raterei gepasst hat. Wenn der CUL von FS20 initialisiert wurde, liegt der Rest am Pairing bzw. den Hauscodes ...
Gruß PeMue
ja, genau mit Deinen Codes! Im Event-Monitor sind meine FS20 Signale des Handsenders zu sehen, nur mit FHEM schalten lassen sich die FS20 Geräte (noch) nicht.
Hallo,
post doch mal bitte das define des CUL_1 inkl. aller attr dazu.
Grüße
bittesehr:
Hallo,
ok - das wär als Auszug aus der fhem.cfg in Code-Tags auch gegangen ;-)
Aber das Attr welches ich vermutet habe ist nicht gesetzt.
Sorry aber da kann ich dir dann leider nicht weiter helfen.
Grüße
Hallo Dieter,
es ist schon lange her, dass ich mein FS20 "angelernt" habe. Aber muss man da nicht den Empfänger in den "Anlernmodus" versetzen und mit dem Sender schalten? Und der CUL hört zu und baut per "autocreate" die entsprechenden Definitionen in die fhem.cfg?
Probier doch einfach noch einmal, die FS20 anzulernen ...
Gruß PeMue
Hallo,
kann man, muss man aber nicht.
Es reicht das Device in FHEM zu definieren, dann den Empfänger in den Anlernmodus zu bringen und in FHEM am vorher definierten Device on oder off zu klicken.
Die "Codierung" wird dann, so wie bei einer normalen Fernbedienung, an den Empfänger übertragen.
Grüße
Alles klar. Ich habe eine Fernbedienung für meine Kamera und der Sender hat auf Anhieb nicht funktioniert. Daher mit fhem versucht, aber gescheitert. Sender habe ich zu ELV zurückgeschickt, einen neuen bekommen, die beiden angelernt und fhem hat - so nebenbei - den rest für mich gemacht. Daher hat mich das korrekte Vorgehen nicht wirklich interessiert ...
Gruß PeMue
ich werd jetzt mal ein FS20 device löschen und neu anlernen, vlt. gehts dann ...
Hallo,
das
ZitatDaher mit fhem versucht, aber gescheitert.
hätte aber nicht passieren dürfen.
Ich benutze mittlerweile nur noch das absolut nötigste an Fernbedienungen - und die auch nur als WAF, sonst streikt meine Frau.
Das meiste läuft über Bewegungsmelder und/oder Zeit- und/oder Temperaturabhängig.
Wenn ich einen neuen Empfänger einbaue wird in FHEM erst das Device definiert - das Gerät dann in den Anlernmodus gebracht und in FHEM dann on oder off geklickt.
Zur Kontrolle nochmal klicken - der Empfänger schaltet. Nun wird er erst verbaut.
Die FB kommt erst später wenn meine Frau meint "sie will das auch so schalten können".
Dann wird an der FB nur Hauscode und Geräteadresse eingegeben und das Device schaltet brav.
Meist geh ich aber her und die FB bekommt eine eigene Adresse und in FHEM reagier ich nur per notify drauf.
Aber das ist ja zum Glück Geschmackssache ;-)
Grüße
Zitat von: grappa24 schrieb am Do, 06 Juni 2013 22:44ich werd jetzt mal ein FS20 device löschen und neu anlernen, vlt. gehts dann ...
es werden zwar FS20 Telegramme erkannt, aber keine devices angelegt ....
CUL CUL_1 UNKNOWNCODE 810b04xx0101a0011b1b100011
gelöst !!!!
Die FS20 Geräte liefen seit der ersten Anbindung auf IODev CUL_0, auf CUL_0 läuft aber jetzt der EIB, musste also "nur" die FS20 Geräte alle auf IODev CUL_1 umstellen
mann mann mann ....
Dieter
Hallo Dieter,
da Rudolf meinte, usbserial wäre nur für den Notfall (http://forum.fhem.de/index.php?topic=13197.msg81058#msg81058), wäre meine Bitte an Dich, es noch einmal mit
modprobe kernel/cdc-acm.ko vendor=0x03eb product=0x204b device=0x0003
modprobe kernel/cdc-acm.ko vendor=0x03eb product=0x204b device=0x0004
statt den bisher verwendeten. Ich nehme an, Du hast die ZIP Datei v5.4 (//fhem.de/fhem-5.4-fb7270.zip) verwendet. Wenn es dann auch noch funktioniert, würde ich diese Infos ins Wiki stellen. Wenn nicht, geht bei mehreren CULs wohl nur usbserial (ich kann es selber leider nicht testen, weil ich nur einen CUNO habe).
Danke + Gruß
PeMue
werd ich am WE testen, soviel vorab ...
Ich verwende http://fhem.de/fhem-5.4-fb7390.image (//fhem.de/fhem-5.4-fb7390.image)
es geht mit
modprobe usbserial vendor=0x03eb product=0x204b device=0x0003 #CUL_0 für EIB
modprobe usbserial vendor=0x03eb product=0x204b device=0x0004 #CUL_1 für FS20
aber auch mit
modprobe usbserial vendor=0x03eb product=0x204b device=0x0003
modprobe ftdi_sio vendor=0x03eb product=0x204b device=0x0004
Bitte noch mal kurz die Unterschiede zwischen usberial, ftdi_sio und cdc_acm ?
Ich freue mich, wenn ich dem Forum etwas zurückgeben kann ;-)
Hallo Dieter,
ich kann in diesem Fall auch nur raten bzw. Infos von verschiedenen Usern zusammentragen.
a. cdc-acm.ko macht eigentlich den USB Modem Support (//cateee.net/lkddb/web-lkddb/USB_ACM.html)
b. usbserial unterstützt USB -> seriell Wandler (//www.kernel.org/doc/Documentation/usb/usb-serial.txt), wobei ich nicht weiß, ob die Treiber für FTDI Chips schon mit drin sind
c. ftdi_sio ist der Treiber für erwähnte FTDI Chips (USB -> seriell Wandler)
c. Solltest Du nicht brauchen, da die CULs eine USB Schnittstelle "einkompiliert" haben, aus diesem Grund könnte vermutlich einmal usbserial entfallen ...
Gruß PeMue
Zitat von: grappa24 schrieb am Fr, 07 Juni 2013 09:17es geht mit
modprobe usbserial vendor=0x03eb product=0x204b device=0x0003 #CUL_0 für EIB
modprobe usbserial vendor=0x03eb product=0x204b device=0x0004 #CUL_1 für FS20
aber auch mit
modprobe usbserial vendor=0x03eb product=0x204b device=0x0003
modprobe ftdi_sio vendor=0x03eb product=0x204b device=0x0004
Muss das teilweise revidieren. Nachdem ich jetzt einen anderen USB-Hub installiert hatte, war meine Zuordnung CUL_0<->EIB und CUL_1<->FS20 vertauscht. Durch Tauschen des CUL und des TUL am Hub passt es jetzt wieder (war mir zu blöd, die config wieder anzupassen ;-).
Aber zum Thema:
In meiner startfhem werden standarmäßig schon cdc-acm.ko und ftdi_sio eingebunden, allein damit werden meine beiden "CULs" erkannt (DEV003 und DEV004), so dass ich die beiden o.a. usbserial Einträge mit VID,PID und DEV wieder komplett entfernt habe.
In der Doku zu cdc-acm hab ich übrigens gesehen, dass ATMEL Chips unterstützt werden, wie sie in meinen beiden CULs verbaut sind ...
Für mich ist jetzt alles "fein", EIB und FS20 sind angebunden, der Server läuft seit zwei Tagen stabil und ich kann mich aufs Programmieren konzentrieren, ich sag nur "Rollosteuerung" mit allen Schikanen ... ;-)
Hallo Dieter,
dann müsste eigentlich eine Zeile mit
modprobe cdc-acm.ko
eigentlich für CUL und TUL reichen, oder?
Gruß PeMue