Umzug RP2 auf RP3 mittels Backup

Begonnen von bastih., 06 August 2018, 19:45:35

Vorheriges Thema - Nächstes Thema

UweUwe

Hallo Beta_User,
du lagst sehr richtig:
Nachtrag: Vermutlich ist auch avrdude etc. noch nicht installiert, oder?
war nicht installiert. Jetzt installiert. Ich hab nochmals in den Anleitungen nachgeschaut, avrdude hatte ich nicht gesehen. Sicherlich mein Fehler.

Aktuell benutze ich FileZilla, um die directory Struktur zu "ergründen".

Der Pfad lautet  bei mir
ls -la/home/pi/culfw-1.67/Devices/CUL
dort liegt drwxrwxr-x  2 501 staff  4096 Feb 14 09:29 .
drwxrwxr-x 25 501 staff  4096 Feb 14 09:29 ..
-rwxrwxr-x  1 501 staff  4574 Sep  7  2017 CUL.c
-rw-rw-r--  1 501 staff 34406 Sep  7  2017 CUL_V2.hex
-rw-rw-r--  1 501 staff 34545 Sep  7  2017 CUL_V2_HM.hex
-rw-rw-r--  1 501 staff 35527 Sep  7  2017 CUL_V2_MAX.hex
-rw-rw-r--  1 501 staff 80044 Sep  7  2017 CUL_V3.hex
-rw-rw-r--  1 501 staff 71903 Sep  7  2017 CUL_V3_ZWAVE.hex
-rw-rw-r--  1 501 staff 65750 Sep  7  2017 CUL_V4.hex
-rw-rw-r--  1 501 staff  6960 Sep  7  2017 board.h
-rwxrwxr-x  1 501 staff  6706 Sep  7  2017 makefile
-rwxrwxr-x  1 501 staff  9460 Sep  7  2017 makefile.myusb

Von dort aus habe ich den dfu-programmer erfolgreich installiert mit
sudo apt-get install dfu-programmer sh
sudo shutdown -h 0
Raspberry wieder hochgefahren und mit gedrückter Taste USB Stick eingesteckt.
Dann geflasht
pi@mymachine:~/culfw-1.67/Devices/CUL $ sudo make usbprogram_v3
dfu-programmer atmega32u4 erase || true
dfu-programmer atmega32u4 flash CUL_V3.hex
Validating...
28452 bytes used (99.23%)
dfu-programmer atmega32u4 start
pi@mymachine:~/culfw-1.67/Devices/CUL $ D
Das sollte doch ok sein? An welchem Punkt hatte ich es nicht in "home" ausgeführt, oder war es einfach das fehlende avrdude.
Eine Verständisfrage hinsichtlich der Zuordnung der CULs zu den FHEM devices:
FHEM sieht ja jetzt 2 CULs (hoffentlich bald). Das Backup von mir benutzt auch 2 CULS, allerdings mit älterem Flash Stand. Eines wird für Homematic verwendet, eines für FHT etc.
Muss ich da noch eine Zuordnung machen?










Beta-User

Schön, dass du einen Schritt weiter bist.
Du hast jetzt 2 868-er CUL, richtig? Beide mit einer 32U4-mcu, also "by-id" nicht unterscheidbar, oder? Dann würde ich empfehlen, die firmware nochmal neu zu backen und dann (nur) den "alten" auch neu zu flashen, dabei aber die Kennung zu ändern. Das war eine Angabe in boards.h, wenn ich das richtig im Kopf habe, die du vor dem make ändern müßtest.

Kurz gesagt, würde ich immer versuchen, eine eindeutige Ansprache von USB-Geräten zu verwenden, "by-id" geht nur nicht, wenn die Kennung dieselbe ist (ohne Eingriff in die firmware). Neben der Änderung der Kennung ginge noch "by-path", steht auch im Wiki bei "mehrere USB-Geräte...".

Der firmware-Stand ist dagegen ziemlich egal, v.a. bei Geräten, die sich als Modem melden (ACM...), weil da sogar die Baudrate vom Host aus vorgegeben werden kann.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

UweUwe

Hallo,

ich hab weder alten noch neuen CUL. Ich hab 2 neue CULs. 8) 8)
Ich hab bisher nur einen geflaht. 8). Hier das Ergebnis  pi@mymachine:~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Feb 14 11:54 usb-busware.de_CUL868-if00 -> ../../ttyACM0
sieht gut aus.
Ich kann aber beide Culs mit derselben firmware flashen, auch wenn einer für fht und einer für homematicgeäte sind soll. Korrekt. 1.67

Zitatdabei aber die Kennung zu ändern. Das war eine Angabe in boards.h, wenn ich das richtig im Kopf habe, die du vor dem make ändern müßtest.

Ich hab die boards.h gefunden und auch angeschaut. In dem Artikel im wiki https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden wird auch über Kennung gesprochen. Meint ihr da die board ID?

Meint ihr da die #define BOARD_ID_STR            "CUL868"
#define BOARD_ID_USTR           L"CUL868"


Und da ändern auf "CUL868H" z.B. beide Werte? Ich verspreche, wenn es läuft, schreibe ich alles nochmals zusammen.. und stelle es zur Verfügung. Merci

Beta-User

Zitat von: UweUwe am 14 Februar 2019, 12:16:25
Ich kann aber beide Culs mit derselben firmware flashen, auch wenn einer für fht und einer für homematicgeäte sind soll. Korrekt. 1.67
Ja, die firmware kann identisch sein. Wenn einer der beiden Transceiver (CC1101) für 433MHz optimiert ist, ist auch die USB-Kennung unterschiedlich, aber FHT war auch 868, oder?

Welche der Angaben in boards.h das richtige ist, weiß ich auch nicht (ich habe meinen CUL schon ewig nicht mehr geflasht und auf meinen anderen ATMega32U-Boards werkelt eine andere firmware...). Ich selbst weiß viele Dinge auch erst dann, wenn ich sie ausprobiert habe (z.B. das mit dem Umprogrammieren der CP2102 und (fake?) FTDI's im Wiki), kann also nur dazu raten, das einfach auszuprobieren und dann hier oder gleich im Wiki zu posten ;) .

Zu HM und CUL hast du wahrgenommen, dass das nicht die optimale Wahl ist? Ggf. mal die timing-optimierte firmware-Variante testen oder gleich ein "richtiges" HM-IO nehmen (PI-PCB). (Bitte suche selbst zu den Stichworten, sollte eigentlich alles im Wiki zu finden sein)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Mein Beitrag #29 ist eventuell durchgeflogen, wegen Homematic.
Zitat von: Otto123 am 14 Februar 2019, 11:27:19
Hi,

obwohl ich von CUL wenig Ahnung habe, habe ich mal einen geflashed und habs aufgeschrieben :)
https://heinz-otto.blogspot.com/2016/02/cul-stick-flashen.html

Für den Homematic CUL solltest Du allerdings sowieso eine andere Firmware nehmen. Die weiteren Infos befinden sich hier:
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

UweUwe

Hallo Beta-User,
ich hab auch noch etwas gelesen und einen Hinweis gefunden:
Zitat
Antw:2 CUL 868 an Raspberry Pi, wie unterscheiden?
« Antwort #8 am: 30 Dezember 2016, 11:47:51 »

    Zitat

Zitat von: kingmathers am 30 Dezember 2016, 11:25:39

    Was genau bedeutet dass dann für mich? In der Datei board.h die entsprechende Zeile abändern, dann neu kompilieren (?) und dann diese culfw auf einen der Sticks flashen zur Unterscheidung?


Ja. Wobei für den USB Descriptor folgende Zeile in der board.h relevant ist:
Code: [Auswählen]

#define BOARD_ID_USTR           L"CUL868"

Also diesen Wert BOARD_ID_USTR           L"CUL868" ändern.  Ich werde mal auf derselben Anzahl von Zeichen gehen und "CXH868" verwenden.
Ich weiss, dass der CUL nicht ideal für Homematic ist. Davon möchte ich auch weg.
Ich habe aber ein altes System, auf einem RPI 1 , mit 2 CULs, das ich altuell umschichte auf einen RPI3 mit HM-Funkmodul. Deshalb die jetztige Aktion  8). Ich starte mit 2 CULs und einem Funkmodul auf dem RPI3 und werde jetzt Schritt für Schritt die Homematic module vom CUL auf das Funkmodul umschichten. Das hatte ich Otto  8) schon angedroht. So der Plan.

Beta-User

Zum HM-Umzug:

M.E. ziemlich umständlich, jedenfalls, wenn du nicht gleichzeitig auch noch auf HMCCUx-Module umstellen willst. Einfach eine VCCU (in alt und neu) definieren, die mit derselben HmID versehen und "auf einen Rutsch" alle CUL_HM-Geräte mit der passenden IOGrp versehen.

Dann kannst du die darunterliegenden IO's hin- und hertauschen, wie du lustig bist...

Von sequenziellen Umzügen halte ich persönlich wenig. Richtig vorbereiten, die notwendigen Dienste drumrum installieren, die noch auf derselben Maschine laufen sollen/müssen, Komplettumzug. Fehlerbereinigung. Basta! (Wenn es irgend geht...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

UweUwe

Hallo ihr beiden,
muss bezüglich der Firmware für den Flash nochmals fragen:
Otto, ich werde an dem Link zu dem speziellen Homematic CUL Firmware wohl scheitern. :'( :'(
Ich vermute auch, dass ich 2015, als ich für beide CULs meinen aktuell in Funktion befindlichen Raspberry, damals Version CUL culfw-161, verwendet habe. So meine Aufzeichungen.
Aber wenn du sagst, dass da kein Weg vorbeiführt, so mache ich es.
Hab ich es richtig verstanden?

Beta-User: das mit der VCCU ist der richtige Weg ich weiss. Lebensumstände geben manchmal einen Rahmen vor, leider, manchmal auch die Angst vor dem, was man in der Vergangenheit konfiguriert hat. Sind die Homematic Geräte wirklich sauber gepeert? Ich hab keinen einfachen Zugriff auf die Geräte (Rücksetzen etc?) Und ich weiss, dass ich nicht "erfahren" gearbeitet habe.  :'( :'(

Beta-User

Zitat von: UweUwe am 14 Februar 2019, 13:27:54
Hallo ihr beiden,
muss bezüglich der Firmware für den Flash nochmals fragen:
Otto, ich werde an dem Link zu dem speziellen Homematic CUL Firmware wohl scheitern. :'( :'(
Ich vermute auch, dass ich 2015, als ich für beide CULs meinen aktuell in Funktion befindlichen Raspberry, damals Version CUL culfw-161, verwendet habe. So meine Aufzeichungen.
Aber wenn du sagst, dass da kein Weg vorbeiführt, so mache ich es.
Hab ich es richtig verstanden?
Wenn du mittelfristig sowieso ein anderes IO nehmen willst: laß' alles, wie es ist, auch die "alten" CUL kannst du weiternutzen (meiner läuft auch noch auf der vir dir genannten firmware-Version, geht ja, warum ändern?)

ZitatBeta-User: das mit der VCCU ist der richtige Weg ich weiss. Lebensumstände geben manchmal einen Rahmen vor, leider, manchmal auch die Angst vor dem, was man in der Vergangenheit konfiguriert hat. Sind die Homematic Geräte wirklich sauber gepeert? Ich hab keinen einfachen Zugriff auf die Geräte (Rücksetzen etc?) Und ich weiss, dass ich nicht "erfahren" gearbeitet habe.  :'( :'(
Ähm, ich verstehe das Problem nicht....
Du sicherst in deinem alten System die cfg.
Dann definierst du eine VCCU (mit nur dem vorhandenen CUL als IO), übernimmst dabei die vorhandene HmID und ergänzt bei allen CUL_HM-Geräten die IOGrp. Dabei geht nichts verloren, du führst nur eine Abstraktionsschicht ein, um zukünftig bei den darunterliegneden IO's flexibel zu sein. Wenn's nicht funktioniert, nimmst du einfach die weggesicherte cfg...

Dann solltest du dich mal mit hminfo auseinandersetzen (immer noch im alten System!). Damit läßt sich einigermaßen komfortabel feststellen, ob es irgendwelche Probleme in der HM-Installation gibt. Muß man sich einlesen, ja, aber es geht dadurch nichts kaputt. Du merkst höchstens, was schon immer nicht ganz 100% war...

Davor braucht man keine Angs zu haben :) . Nur Mut!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Uwe: Ich hätte mir den Stress mit der CUL Firmware auch nicht gemacht, ich hätte das EQ3 Pi Modul genommen.

Es gibt hier viele, die sagen die original CUL Firmware geht und viele scheitern daran mit bestimmten Homematic Produkten und Situationen. Es ist nur eine Empfehlung.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

UweUwe

Hallo Otto,
ich bin nicht beratungsresistent. Einer von euch neben mir hier am Schreibtisch für 1/2 Tag. Sofort, alles. Hier mein Gedankenansatz:
Habe heute einen RPI1 mit 2 CULS, FHT und Homematic. Seit 3 Jahres stabil, ohne Änderungen.  Am Homematic CUL des RPI 1 hängen devices, an die ich physikalisch nicht gut rankommen, In Rollädenkästen, die hinter Tapeten sitzen. Meine Frau lüncht mich, wenn ich da ran muss. (vielleicht auch nicht sauber gepairt).  Die FHEM Installation ist in einem Ferienhaus, in dem ich noch ca. 1 Woche bin (max). Dann zwingen mich Lebensumstände leider dazu, dass ich mehrere Monate hier nicht sein kann (darf). Es ist dann niemand hier. Das System muss gut und sicher laufen, wie in der Vergangenheit. Es ist niemand vorort. 
Da ich zusätzlich noch Alarmanlage und Kamera installiere tuts der RPI1 nicht länger ==> Meine Vorstellung. Ich hab ihn aber noch als Fallback (Software und Hardware komplett)
Mein Plan war nun: Neuer RPI 3 mit 2 CUL und einem EQ PI Modul (Homematic Funkmodul) .
Nach "Ottos Rezept"  RPI3 hochziehen (wobei ich ganz ursprünglich geplant hatte, nur die kopiere Flashkarte vom RPI1 auf den RPI3 Umzustecken), 2 x CUL einstecken, 1 x Homematic Funkmodul aufstecken, Sicherung FHEM einspielen. ==> neue gute Basis.
Ab hier dann das System Schritt für Schritt (und jederzeit abbrechbar, da meine Zeit hier vorüber ist) säubern, umsetzen, ..(völlig entspannt).
Realität hat mich eines besseren belehrt. Und nun, Planänderung?


Beta-User

Zitat von: UweUwe am 14 Februar 2019, 18:18:59
Und nun, Planänderung?
Kommt drauf an: Wenn viele notify etc. sind, die auf CUL_HM-Events reagieren, würde ich dazu tendieren, in so einem Fall nur minimalistisch vorzugehen, also auf eine VCCU zu verzichten (das kann die Zahl der Events ändern).
Daher am besten nur das PI-PCB verwenden (übergangsweise den CUL), da kann man "in einem Rutsch" auch das IO für alle CUL_HM-Geräte ändern.

Ansonsten nur: Neue Hardware, alles aktualisieren, backup drauf, nochmal testen, ob alles aktuell ist und läuft (ggf. nach Anpassung der IO-Angaben => lassen, wie es ist...

Unbedingt eine gute und haltbare Karte verwenden!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

UweUwe

Hi, möchte mich über den Support ganz ausdrücklich  8) 8) 8) 8) bedanken. Super, ohne dies, keine Chance.
Hab mir folgenden Weg überlegt:
1. Die beiden CULs für der RPI 3 vorbereiten und versuchen, ob ich den RPI 3 mit den CULs zum Laufen bringe. Die FHT Module brauchen ja in jedem Fall einen CUL auf dem RPI3
Sobald der RPI3 auf einem ersten sicheren Podest steht (Homematic ausgenommen), zurück auf den RPI 1 , Homematic devices auf VCCU packen, HM anschauen, alles mit dem Ziel, den CUL auf dem RPI 3 für Homematic nicht verwenden zu müssen. Anschliessend FHEM nochmals von RPI 1 nach RPI 3 transferieren. So der Plan.
Ich berichte und dokumentiere. Euere Beratung ist mir sehr wichtig  :) 8) 8)

UweUwe

Hallo,
Zwischenstand:

1. Änderung der Kennung des CUL Devices gelang mir leider nicht, obwohl ich in board.h beide Werte geändert habe:#define BOARD_ID_STR            "CHX868"
#define BOARD_ID_USTR           L"CHX868"


Habe mehrmals geflasht mit unterschiedlichen Daten im board.h immer der gleiche Output (ohne Schreibschutz 8))
pi@mymachine:~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Feb 14 11:54 usb-busware.de_CUL868-if00 -> ../../ttyAC                             M0
Der Ablauf war immer fehlerfrei:pi@mymachine:~/culfw-1.67/Devices/CUL $ sudo make usbprogram_v3
dfu-programmer atmega32u4 erase || true
dfu-programmer atmega32u4 flash CUL_V3.hex
Validating...
28452 bytes used (99.23%)
dfu-programmer atmega32u4 start



2. Mein FHEM Backup spielte ich (mit identischen CUL) gemäss der Anweisung von OTTO "Backup und Restore von FHEM" nochmals ein und hatte dann auf den ersten Blick ein Kopie des RPI1 Systemes auf dem RPI3 (+++  8) 8) ) funktionsfähig.

Ohne die Mithilfe von Beta_User und Otto wäre ich nicht da. Danke nochmals. Zurück nach RPI 1 muss ich wohl nicht.
Nächster Schritt ist das Homematic-Funkmodul und die vielen Punkte aus HM (hab schon mal gesichtet :'().

das einfach auszuprobieren und dann hier oder gleich im Wiki zu posten ;) .
Ich hatte zugesagt, dass ich die Erkenntnisse aufschreibe und verschicke. Notizen sind da, welche Abläufe soll ich beschreiben und wohin schicken? Mach ich gerne.  8).

Otto123

Klingt doch gut? Das mit dem Homematic eq3 RPI Modul sollte leicht gehen. Steht alles im Wiki :)
Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz