Zusätzlichen Cul für HomeMatic installieren

[UweUwe]

Hallo,

hab mal das Forum und How To etc. durchforstet zum Thema: Wie installiere ich einen zweiten CUL für meinen Rasperry für HomeMatic.

Ich habe eine funktionsfähiges, auf dem neuesten Softwarestand befindliches FHEM System, das über einen Cul V3 mit FS20 und FHT Geräten zuverlässig spricht.

Jetzt will ich das System um weitere HomeMatic Geräte erweitern.

1. ich habe einen weiteren Cul 3 neu, noch nie angeschlossen.
2. ich stelle FHEM auf autocreate....
3. ich schalte den Raspberry aus
4. ich stecke den zweiten Cul in den Rapberry direkt ein
5. ich schlalte den Rapberry wieder ein und warte, bis FHEM hochgelaufen ist.
6. Ich schaue in der .cfg Datei nach ob sich der CUL automatisch generiert hat. Die entsprechenden Zeile müssen heißen ? === das weiß ich noch nicht?

Könnt Ihr mir hier einen Hinweis geben, wie das aussehen muss?
Oder muss ich die entsprechnden Zeilen in der Commandozeile eingeben?
Define Cul_1 Cul /dev/ttyACM1@9600 yyyy
Attr Cul_1 rfmode HomeMatic

merci

[Zrrronggg!]

Ich glaube, dass Autocreate CULs nicht anlegt. Das wird man wohl manuell machen müssen.

Define Cul_1 Cul /dev/ttyACM1@9600 yyyy
Attr Cul_1 rfmode HomeMatic

Grob ja, wie das GENAU aussieht hängt auch vom Host und dessen OS und dessen USB Treibern ab, da ich keinen Rasperry habe weiss ich nicht wie die Schnittstelle da genau heisst. Eben Analog zu deinem bisherigen CUL und rfmode HomeMatic.. Letzlich bleibt mir nur hier commandref zu zitierien:

Define
define <name> CUL <device> <FHTID>

Geräte, die an USB angeschlossen sind (CUL/CUN):
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden:
modprobe usbserial vendor=0x03eb product=0x204b
In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.

Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.: /dev/ttyACM0@38400.

Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder OSX.

Ich gehöre zu der Fraktion, die die fhem.cfg direkt editieren. Ich würde die also einfach aufmachen, die Zeilen reinschreiben und sichern. Wenn man das mit dem Editor der Weboberfläche macht, wird die anschliessend neu geladen und die Änderungen sofort wirksam.

Speziell wenn man sich über die genaue Syntax nicht im klaren ist und rumprobieren muss, ist das meiner Auffassung nach der schnellste Weg und der Eingabe über die Kommandozeile vorzuziehen, weil man bei einem Fehler die fhem.cfg einfach noch mal öffnet, korrigiert , sichert, fertig.

Es gibt hier eine Menge Leute die andere Vorgehen vorziehen würden.

[stenny73]

CUL sollte eigentlich automatisch erkannt werden wenn der CUL geflasht ist und autocreate an ist.

Man kann auch ohne Neustart mit "USB scan" und "USB create" neue Komponenten erkennen lassen.

[chris1284]

mal davon ab das ich keinen überteuerten cul v3 für homematic nehmen würde.....
wenn du in deriner cf folgende 2 zeilen (relativ weit am anfang) hast

define autocreate autocreate
define initialUsbCheck notify global:INITIALIZED usb create

sollte er autom. erkannt werden wenn du ihn vor dem fhemstart angesteckt hast (also am besten pi aus, sticks dran, hochfahren)

alternativ machst du in der ssh shell ein dmesg nach dem anstecken und sieht wie der pi in anlegt und bindest ihn dan ein

Define Cul_1 Cul /dev/ttyACM1@9600 yyyy
Attr Cul_1 rfmode HomeMatic

ob nun ttyACM0 /ttyACM1 /ttyACM2 siehst du in der dmesg ausgabe nach dem einstecken des 2. oder beim vergleich der ausgabe

ls /dev/

in der shell (da müsste bein einem cul nur ein ttyACMxxxx sein und nach anstecken des 2. ein weiterers ttyACMxxxxx)
in der cfg würde ich aber nicht rum wurschteln und ggf über einen hm-usb-cfg (ca 30€) nachdenen statt dem cul

[UweUwe]

Hallo,

habe schon erwartet, dass mir dies nicht so leicht fällt. Es tuts leider nicht.

Was habe ich gemacht.

1. Habe autocreate activiert. ==>


              define autocreate autocreate
              attr autocreate filelog ./log/%NAME-%Y.log
              attr autocreate room CUL_WS[/i][/i][/i]

2. Habe den CUL_1 definiert ==>

              define CUL_1 CUL /dev/ttyACM1@9600 1111
              attr CUL_1 rfmode HomeMatic

Mein CUL, der funktioniert lautet:

                define CUL_0 CUL /dev/ttyACM0@9600 1034

USB Check wird gemacht:

               define initialUsbCheck notify global:INITIALIZED usb create.


Mein CUL 3 ist fabrikneu, habe ihn noch nicht geflasht (hoffe, dies macht FHEM).

Wenn ich dann shotdown restart mache finde ich:

CUL_0 Initialized
CUL_1 disconnected

(Am CUL_1) leuchtet keine LED, komplett dunkel, CUL_= funktipniert weiterhin

Habe dann versucht, den CUL_1 zu flashen mit : ==>

     Culflash CUL_1 CUL_3 in der Kommandozeile.

Ich bekomme dann als respond: ==> dfu-programmer: no device present.
Ich habe auch noch den Hinweis zu dem Taster gelesen, den man drücken muss:

Also habe ich den Taster gedrückt, bevor ich den Befehl Culflash Cul_1 Cul_3 abgesetzt habe:
Gleiches Ergebnis. : dfu-programmer: no device present.

Was mache ich falsch?

[Ellert]

2 gleiche CUL an einem Rechner sind ein Problem, weil beim Neustart die Ports unterschiedlic enumeriert werden können. Vor dem Neustart CUL 1 auf ttyACM0, CUL 2 auf ttyACM1, nach dem Neustart CUL1 auf ttyACM1 und CUL2 auf ttyACM0. Wenn jetzt der CUL 1 auf ttyACM1 liegt kann sich CUL 2 nicht mehr auf ttyACM1 anmelden und bleibt disconnected.

Lösung zum Flashen: die Definitionen der CULs deaktivieren, nur den zu flashenden CUL anstecken und auf ttyACM0 definieren, dann flashen.

Die Problematik kannst Du hier nachlesen http://www.fhemwiki.de/wiki/Selbstbau_CUL unter Hinweise zum Betrieb mit Fhem.

[UweUwe]

Hallo vielen Dank für den Hinweis,

verstehe ich es richtig:

1. Ich muss den bereits geflashten CUL abziehen und weglegen, also meinen CUL_0.
2. den nagelneuenCUL dann anstecken und Flashen.

Jetzt noch zum flashen selbst.

Den nagelneuen Flash an den Raspberry ansecken und dann

"Culflash CUL_1 CUL_3" in der Kommandozeile eingeben.

==> Wie sage ich dem CUL aber, dass er auf ttyACM1 liegen soll?
==> muss man hier die Taste am CUL dgedrückt halten und wie lange?

Vielen Dank

[rudolfkoenig]

Im ausgelieferten config wird ein "usb create" beim FHEM-Start ausgefuehrt.

Bei jedem usb Befehl wird _ein_ CULflash ausgefuehrt (d.h. ein CUL geflasht), falls lsusb einen ungeflashten CUL findet. CULflash benoetigt einen installierten dfu-programmer, der passende(!) Rechte hat, wenn man es von FHEM ausfuehrt. Diese Rechte waren auf dem FB7390/7490 vorhanden (root s-bit fuer dfu-programmer), auf anderen Systemen muss man das selbst zuweisen.

Wenn diese Voraussetzungen (lsusb und dfu-programmer mit passenden Rechten vorhanden) erfuellt sind, dann reicht es das ungeflashte CUL einzustecken, und FHEM neu zu starten, es wird geflasht und eingebunden. Bei ungeflashten CULs muss man die Taste nicht druecken, der Aufruf in diesem Fall ist "CULflash none CUL_V3" (erledigt durch das "usb create"). Bei einem eingebundenen CUL muss man die Taste fuer CULflash auch nicht druecken, da CULflash das CUL via culfw Befehl (set CUL_0 raw B01) in flashmode versetzt. Der Aufruf in diesem Fall ist "culflash CUL_0 CUL_V3"

Das Problem der Verwechslung von ttyACM0 mit ttyACM1 nach einem Boot ist zwar vorhanden, aber es tritt nicht ueberall auf, bei mir z.Bsp. gar nicht. Die in der wiki beschriebene Loesung mit /dev/serial/by-id/... sollte bei CULs nicht funktionieren, da die CULs keine eindeutige IDs haben. Ich wuerde stattdessen /dev/serial/by-path/... nehmen.

[Ellert]

@rudolfkoenig: Danke für den Tip, /dev/serial/by-path kannte ich noch nicht. Dann kann man für den Selbstbau CUL also auch Arduino Nano Nachbauten nehmen, die den CH340 Chip verwenden, der auch keine Seriennummer haben soll.

@UweUwe: Ich habe meine CULs nicht mit FHEM geflasht, zu der Prozedur kann ich nichts sagen. Ich hatte aber schon das Problem mit einem nichtverbundenen 2. CUL (der war allerdings schon geflasht) nach einem Neustart meines RasPi B+.

Meine CULs habe ich über die Linux-Konsole geflasht, wie beim Selbstbau CUL beschrieben oder hier: http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen

zu 1. Ja
zu 2. ja

[UweUwe]

@rudolfkoenig: Danke für den Tip. Ich will zuerst mal sehen, ob ich den Cul über FHEM geflasht bekomme. Falls nicht, so versuche ich den von Elert beschriebenen Weg.

Noch ne Frage zum dem flashen mit FHEM:

Kann ich den bereits geflashten CUL eingesteckt lassen, wenn ich den Neuen Cul flashen will?
Wie ist die mit den Rechten für den dfuprogrammer. Installiert ist er mir mir anscheinend, da ich ja die Fehlermeldung: dfu programmer: no device present bekomme.
Aber die Rechte, wie stelle ich die Rechte ein und was sind passende Rechte?
Isusb sagt mir leider nichts.
Vielleicht ist dieser Weg für mich doch zu kompliziert und ich muss den Cul vorher flashen.

Was meint Ihr?
Vielen Dank

[Puschel74]

Unter Windows flashen (wird auch im Wiki beschrieben) - alles andere sind Linux-Grundlagen.
Und der Rest ist ebenso im Wiki beschrieben oder im Forum oder sollte sich per "liebster Suchmaschine" auffinden lassen und muss nicht zwangsweise zum x-ten Mal hier beschrieben werden.
Suchen und finden (und lesen) sollte machbar sein.

[Ellert]

Hier noch ein Tip vom hexenmeister zu /dev/serial/by-path/ http://forum.fhem.de/index.php/topic,24651.msg325186.html#msg325186

[UweUwe]

Hallo,

da ich vermute, dass viele User das Thema haben:

Flashen eines weiteren CUL für den Raspberry zur Verwendung unter FHEM

Ich möchte hier meine Vorgehensweise beschreiben:

Zugriff über Putty mit dem Rapberry herstellen, dann:

   1. Zuerst nachschauen, was die aktuellste Version  der CUL flash Software ist:Aktuell ist es die Version 1.61 
           (sieht man unter http://culfw.de/culfw.html)
   2. Dann mit dem Befehl (in putty) sudo wget http://culfw.de/culfw-161.tar.gz die Datei herunterladen
   3. Dann mit dem Befehl sudo tar -zxvf culfw-1.61.tar.gz die Datei entpacken
   4. Dann in das Verzeichnis wechseln: cd /home/pi/CUL_VER_161/culfw/Devices/CUL (eventuell einzeln dahin wechseln,
        von einer Hierarchie zur nächsten). 
   5. Das Paket dfu-programmer installieren mit dem Befahl:sudo apt-get install dfu-programmer 
   6. Dann das laufende FHEM beenden auf dem Raspberry mit "shutdown".
   7. Den bereits geflashten Stick vom Raspberry entfernen (und markieren) 
   8. Dann den CUL mit gedrücktem Taster in den USB Buchse stecken (am Besten CUL an einer USB Verängerung). 
   9. CUL Stick flashen mit "sudo make usbprogram_v3"  (V3 bei der Verwendung eines CUL V3) 

[rudolfkoenig]

Alternative:
1. wget http://fhem.de/fhemupdate/FHEM/CUL_V3.hex
2. sudo apt-get install dfu-programmer
3. in FHEM "set CUL_0 raw B01" eingeben (nur noetig, falls CUL_0 in FHEM bereits erkannt ist)
4. sudo 'dfu-programmer atmega32u4 erase && dfu-programmer atmega32u4 flash CUL_V3.hex && dfu-programmer atmega32u4 start'

[Tom111]

   1. Zuerst nachschauen, was die aktuellste Version  der CUL flash Software ist: Aktuell ist es die Version 1.61 
           (sieht man unter http://culfw.de/culfw.html)

1.61 ?? Also ich habe 1.65 !

http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUL/