[solved] Probleme beim Umzug von Pi 2B auf Pi 3B+/Z-Wave funktioniert nur teilw.

Begonnen von tux75at, 16 Februar 2019, 22:25:23

Vorheriges Thema - Nächstes Thema

tux75at

Hallo, ich hab versucht etwas zu finden, dieses spezielle Problem hab ich aber nicht im Forum entdecken können.

Also auf einem Raspberry 2B (genaue Version weiss ich jetzt nicht, ist aber eher nicht relevant) läuft mein Z-Wave Testbetrieb.
Die Installation vom Rest wird erst später gemacht und dann gibt es ein neues Gerät (einen NUC im Passivgehäuse).

Da der Raspi etwas ungünstig steht und die Klaren Gehäuse zu viel leuchten (Problem mit WAF) habe ich mich entschieden einen neuen Raspi mit Gehäuse zu verwenden. Die LED Öffnungen kann man hierbei dann verdecken. Soweit der Plan, jetzt sitze ich schon das zweite Wochenende und suche nebenbei auch für dieses Problem eine Lösung.

Raspi 3B+ neu aufgesetzt, upgedated (sudo apt-get update; sudo apt-get upgrade) und FHEM installiert und upgedated (vielleicht ist das der Fehler?)
den Raspi 2B ebenfalls upgedated (sudo apt-get udpate; sudo apt-get upgrade) und FHEM update durchgeführt.

Nach einem Funktionstest auch vom ZME UZB 1 ein Firmware update durchgeführt und meinen Erstatz Stick die Firmware raufgespielt (Beide wurden von mir lange vorher auf die gleiche Firmware version aktualisiert). Beide Sticks laufen auf dem alten Raspi, also das Firmware Backup hat funktioniert und das zurückspielen auch. D.h. ich empfange alle Schaltvorgänge und ich kann auch aus der Web Oberfläche Schalten.

Jetzt ging es darum, das Bestehende System zur Seite zu schieben und den neuen Raspi 3B+ in Betrieb zu nehmen.
FHEM beendet, backup eingespielt und FHEM gestartet. Alle Devices konnte ich sehen. Leider kann ich nicht schalten.
Ich empfange vom Fibaro Dimmer nur Stromverbrauchswerte. Dass eingeschalten wurde empfange ich nicht. Auch vom Funkwandschalter empfane ich keine Schaltvorgänge, sie Schalten aber den Fibaro Dimmer und ich empfange bei Schaltvorgängen die Änderungen des Stromverbrauches.

Etwas ist schief gegangen und ich komm nicht drauf. Ich habe schon ein weiteres Backup gemacht und nochmal versucht. Leider geht nichts :(

Kann es ein Problem sein, dass ich FHEM installiert habe und eventuell irgendwelche Dateien nicht überschrieben werden?
Gibt es noch etwas zu beachten beim Einspielen eines Backups?
Mein Kommando dafür:
sudo tar -xvzf /opt/fhem/backup/FHEM-YYMMDD_hhmmss.tar.gz -C /opt/fhem
Vielleicht ist das Kommando nicht korrekt?

Gruß
   Tux

edit: Kommando korrigiert, fehlendes Leerzeichen

Otto123

Hi Tux

klares ja, wenn es kein Typo ist tar-xvzf -> tar -xvzf

Ansonsten passt es.

Stimmen denn die USB Schnittstellen in der Bezeichnung /Anbindung mit dem alten System überein?

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

tux75at

Hallo Otto!

Das hast du richtig Erkannt, es war ein Typo ... Das Entpacken hat immer geklappt :)

Das mit den USB Schnittstellen verstehe ich nicht. Was könnte hier ein Problem sein?
Wenn ich den Dimmer versuche einzuschalten, sehe ich direkt die LED des ZME UZB aufleuchten. Damit kommuniziert er mit dem Stick ... oder doch nicht?

Die gleiche USB Schnittstelle / Den gleichen Anschluss habe ich vermutlich nicht verwendet.
Ich vermute aber auch, dass ich beim funktionierenden System mindestens einmal eine andere Buchse verwendet habe und es klappt alles.
Inzwischen verwende ich immer die gleiche Buchse.

Ich empfange Nachrichten, wenn auch nicht alle ... senden klappt scheinbar nicht.

Log vom neuen Raspi 3B+
2019-02-16 22:55:39 ZWave Office_Light_Dimmer dim 33
2019-02-16 22:55:45 ZWave Office_Light_Dimmer dim 59
2019-02-16 23:01:01 ZWave Office_Light_Dimmer power: 4.6 W
2019-02-16 23:01:08 ZWave Office_Light_Dimmer power: 13.2 W
2019-02-16 23:01:16 ZWave Office_Light_Dimmer power: 0.0 W
2019-02-16 23:01:26 ZWave Office_Light_Dimmer power: 26.0 W
2019-02-16 23:01:36 ZWave Office_Light_Dimmer power: 0.0 W


Log vom alten System Raspi 2B:
2019-02-16 23:07:10 dummy Office_Light on
2019-02-16 23:07:10 DOIF di_Office_Light cmd_nr: 1
2019-02-16 23:07:10 DOIF di_Office_Light cmd: 1
2019-02-16 23:07:10 DOIF di_Office_Light cmd_event: Office_Light_Dimmer
2019-02-16 23:07:10 DOIF di_Office_Light cmd_1
2019-02-16 23:07:10 ZWave Office_Light_Dimmer dim 20
2019-02-16 23:07:10 ZWave Office_Light_Dimmer reportedState: dim 20
2019-02-16 23:07:10 ZWave Office_Light_Dimmer power: 16.9 W
2019-02-16 23:07:15 ZWave Office_Light_Dimmer power: 26.1 W
2019-02-16 23:08:00 dummy Office_Light off
2019-02-16 23:08:00 DOIF di_Office_Light cmd_nr: 2
2019-02-16 23:08:00 DOIF di_Office_Light cmd: 2
2019-02-16 23:08:00 DOIF di_Office_Light cmd_event: Office_Light_Dimmer
2019-02-16 23:08:00 DOIF di_Office_Light cmd_2
2019-02-16 23:08:00 ZWave Office_Light_Dimmer off
2019-02-16 23:08:00 ZWave Office_Light_Dimmer reportedState: off
2019-02-16 23:08:02 ZWave Office_Light_Dimmer power: 14.0 W
2019-02-16 23:08:10 ZWave Office_Light_Dimmer power: 0.0 W


Im ersten Fall habe ich den Funkwandschalter Ein und Aus bedient und danach den Schalter am Fibaro Dimmer Ein und Aus.
Im zweiten Fall habe ich Funkschalter Ein und danach Schalter am Fibaro Aus (jetzt spinnt der Funkschalter, eventuell schwache Battery, da hat er zuvor gemeckert)
Man Sieht aber dass es weit mehr Meldungen gibt.

ZME UZB hängt inzwischen an einer USB Verlängerung, da es scheinbar Funkprobleme geben kann, wenn man ihn direkt am Raspi bzw. einem Rechner anschliest.
Positionierung kann auch etwas optimaler gewählt werden.

tux75at

Ich habe noch ein paar dinge probiert. Unter anderen den neuen Raspi nochmal aufzustzen.
Ergebnis ist das gleiche wie zuvor. Ich erhalte nu Stromverbrauchswerte von Fibaro Geräten, sonst nichts.

In den Device Parametern für de ZWDongle_0 habe ich jetzt einmal verglichen, was bei beiden drinnen steht.
(ich habe immer nur einen Raspi aktiv, zwei gleiche Konfigurationen würden Probleme verursachen)

CallbackNr -> Identisch
Clients -> Identisch
DEF -> Identisch
DeviceName -> Identisch
FD -> Unterschiedlich! Was ist das?
FUUID ->Unterschiedlich! Was ist das?
MaxSendRetries -> Indentisch
NAME -> Identisch
NR -> Identisch
PARTIAL -> Identisch (leer)
RAWMSG -> Identisch
ReadTime -> Unterschiedlich (Timestamp eines Zugriffs? sollte egal sein)
STATE -> Identisch
SendRetries -> Identisch
SendTime -> Unterschiedlich (wie ReadTime, sollte egal sein?)
TYPE -> Identisch
WaitForAck -> Identisch
ZWDongle_0_MSGCNT -> Unterschiedlich (klar, Nachrichtenzähler von FHEM)
ZWDongle_0_TIME -> Unterschiedlich (auch klar, war kein Zeitgleiches Auslesen)
homeID -> Identisch
nodeIDHex -> Identisch
nrNAck -> Identisch


Bei den Attributes ist die homeID und der networkKey identisch
Wenn hier ein Unterschied wäre, dürfte ich garnichts empfangen (auch die Stromverbrauchswerte nicht, ausser ich habe etwas falsch verstanden, Security ist enabled)

Ich bin inzwischen schon am verzweifeln.

Edit:
Ich hab das selbe auf einem NUC mit Proxmox probiert, FHEM läuft, ZME UZB1 ist durchgereicht, aber ich erhalte nur die Stromverbrauchsmessungen der Fibaro devices und ich kann nichts schalten.

Otto123

Moin Tux,

sorry ich habe keine Ahnung von Zwave. Ich dachte nur, die meisten USB Sticks werden ja am Ende über ihre Device Adresse im System angesprochen, dort kommt es aber je nach Stick zu "Eigenheiten" in der Bezeichnung je nach dem wo und wann gesteckt usw.
Scheint bei Zwave aber nicht so zu sein, insofern war mein Gedanke nicht hilfreich.

Und scheinbar arbeitet er ja, sonst hättest Du gar nichts.

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

r00t2

Meine Erfahrungen beim Umzug von einem defekten RPi2 auf einen neuen RPi2 haben gezeigt, dass ich den USB Stick komplett und problemlos weiter nutzen konnte, nachdem ich ihn an den gleichen USB-Port am neuen RPi angeschlossen hatte.

Dabei habe ich die alten Devices aus der fhem.cfg per "Code Schnipsel Upload" in die neue FHEM Installation übernommen.
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

tux75at

Danke Otto!

ich habe am Anfang nicht verstanden was du meinst, aber das scheint zu passen. Der ZWave Dongle erscheint als ttyAMC0 oder so ähnlich.
Kommunikation geht "ein wenig" die Fibaro devices senden Stromverbrauchswerte, aber das sind die einzigen Nachrichten die empfangen werden.
Der Dongle hat den state initialized und sollte damit passen.

Einen Umzug von RPi2 auf RPi2 versuche ich gerade, ich glaub ich hab einen blödsinn gemacht, der Browser verliert ständig die Verbindung.
Ich habe etwas anders gemacht und jetzt geht garnichts mehr.

Ich weiss nicht wann ich wieder dazu kommen, aber wenn von RPi2 auf RPi2 auch nichts geht, dann muss etwas faul sein.
Alles neu anlernen möchte ich verhindern.

r00t2

Zitat von: tux75at am 18 Februar 2019, 21:57:13...
Alles neu anlernen möchte ich verhindern.
Das ist im Normalfall auch nicht notwendig, da die Z-Wave Nodes und deren Topologie im Controller (USB Stick) gespeichert sind.
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

tux75at

Könntest du erklären welche "Code Schnippsel" du meinst?

Ich probiere gerade nochmal au einen RPi2 umzuziehen, also auf die gleiche HW, ich hab zum Glück einen zweiten.
Wenn es das gleiche Ergebnis bringt, dann schient die Methode nicht zu passen. Wenn hingegen alles geht, dann hat meine Methode ein Problem mit einem Hardwarewechsel.

r00t2

Klar, gerne.

Ich meine damit das hier: https://wiki.fhem.de/wiki/Import_von_Code_Snippets

Damit kann man z. B. die ganzen alten Device-Definitionen Stück für Stück aus der noch vorhandenen fhem.cfg in die neue Übertragen.

Bei mir hat es aber auch funktioniert, dass ich ein gesamtes "altes" Backup (von FHEM Version 5.7) über eine neue FHEM Version (5.9) geschrieben habe, dann "update" ausgeführt und nach einem "shutdown restart" die komplette Device-Struktur (inklusive Z-Wave Komponenten) wieder wie zuvor funktioniert hat.

Allerdings war da "nur" ein Wechsel von FHEM 5.7 => 5.9 und von Debian Jessie => Stretch auf dem gleichen Typ RPi zu tun. Die Hardwareplattform habe ich nicht auch noch gewechselt :)

Siehe auch hier, wenn es hilft: https://forum.fhem.de/index.php/topic,95681.0.html

Die Codeschnipsel Variante habe ich sehr gut nutzen können, als ich mein Testsystem auf einem RPi Zero W aufgesetzt habe. Das hat praktisch den gleichen "Unterbau", wie mein Produktivsystem, aber ich habe - per Schnipselübertrag - nur die Definitionen in die fhem.cfg übernommen, die ich auch benötige. Das klappt echt gut :)

Viel Erfolg!
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

tux75at

Ich hab viel herumprobiert ...

Nachdem ich vermutet habe, dass es der stick ist und ich mit ttyAMA0 und ttyACM0 versucht habe, hab ich festgestellt, dass es wie vorher ttyACM0 ist.
Eine neue FHEM installation upgedated und dann mit Codeschnippsel versucht.
Um den Dongle zu erhalten habe ich USB Scan gemacht. Es hat ausgeschaut, als ob die richtige HomeID schon drinnen steht.
Dann hab ich das Codeschnippsel importiert und sah den richtigen Networkkey.
Ein erstes Device habe ich mit der ersten Zeile des Codeschnippsels erstellt wobei ich defmod auf define geändert hatte.
Danach dem Device das Codeschnippsel importiert.

Leider hab ich nicht mehr gesehen wie vorher, nur den Stromverbrauch. Ich glaub schön langsam, dass der Stromverbrauch anders gesehendet wird und eventuell nicht im secure mode. Ist das mit den Codeschnippsel so korrekt?

Sobald ich den stick zurück an den alten Raspberry stecke, funktioniert wieder alles (ausser der Wall Switch, der zickt wiedermal herum, das ist aber eine andere Geschichte).

Ich hatte HTTPS aktiv und die falschen keys vom Backup machten Probleme, aber bei den Codeschnippsel ist nichts mehr dabei von diesen HTTPS Einstellungen.

Gibt es sonst noch etwas das notwendig ist, bzw. man benötigt? Ich verzweifle schon.

tux75at

Ich habe jetzt schon versucht mit einem Jessie das zu probieren (vom Pi2 auf Pi2) geht auch nicht.

Inzwischen habe ich wiederlegen können dass ein Jessie im Spiel ist
Ausgabe von: cat /etc/os-release (am funktionierenden Image)

PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"


Die SD Karte habe ich nicht erfolgreich klonen können. Win32diskimager, dd unter Linux. Jedesmal bekomme ich Kernel Panik bzw es bleibt einfach stehen ohne ersichtlichen Grund. Bootloader ist drauf. Die Karten sind identische Karten die ich gleichzeitig gekauft habe und es war nur eine in Betrieb (im FHEM Raspberry).

Schön langsam glaub ich, dass etwas mit meiner FHEM Installation nicht passt.

Ich wollte die funktionierende FHEM installation nicht viel anfassen, jetzt probier ich gerade diese upzudaten.
Mir fällt auch noch auf, dass ich folgende Antwort bei mehrfachen "update" erhalten:

2019.02.24 18:57:47 4 : Connection accepted from telnetForBlockingFn_1551030026_127.0.0.1_50986
2019.02.24 18:57:47 5 : Cmd: >{Log('1','Got remote controls_fhem.txt with 2184 entries.')}<
2019.02.24 18:57:47 1 : Got remote controls_fhem.txt with 2184 entries.
2019.02.24 18:57:47 5 : Cmd: >{Log('1','Got local controls_fhem.txt with 2184 entries.')}<
2019.02.24 18:57:47 1 : Got local controls_fhem.txt with 2184 entries.
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/fhemweb_multiple.js ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/fhemweb_multiple.js ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/fhemweb_noArg.js ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/fhemweb_noArg.js ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/fhemweb_slider.js ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/fhemweb_slider.js ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/fhemweb_svg.js ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/fhemweb_svg.js ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/fhemweb_textField.js ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/fhemweb_textField.js ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/fhemweb_time.js ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/fhemweb_time.js ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/darktouchpadsvg_defs.svg ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/darktouchpadsvg_defs.svg ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/darktouchpadsvg_style.css ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/darktouchpadsvg_style.css ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/ios6touchpadsvg_defs.svg ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/ios6touchpadsvg_defs.svg ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/ios6touchpadsvg_style.css ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/ios6touchpadsvg_style.css ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/ios7touchpadsvg_defs.svg ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/ios7touchpadsvg_defs.svg ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/ios7touchpadsvg_style.css ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/ios7touchpadsvg_style.css ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/iostouchpadsvg_defs.svg ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/iostouchpadsvg_defs.svg ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/iostouchpadsvg_style.css ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/iostouchpadsvg_style.css ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/darksmallscreensvg_defs.svg ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/darksmallscreensvg_defs.svg ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/darksmallscreensvg_style.css ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/darksmallscreensvg_style.css ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/ios7smallscreensvg_defs.svg ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/ios7smallscreensvg_defs.svg ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/ios7smallscreensvg_style.css ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/ios7smallscreensvg_style.css ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/iossmallscreensvg_defs.svg ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/iossmallscreensvg_defs.svg ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./www/pgm2/iossmallscreensvg_style.css ./unused')}<
2019.02.24 18:57:48 1 : mv ./www/pgm2/iossmallscreensvg_style.css ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','mv ./FHEM/firmware/LaCrosseGateway.bin ./unused')}<
2019.02.24 18:57:48 1 : mv ./FHEM/firmware/LaCrosseGateway.bin ./unused
2019.02.24 18:57:48 5 : Cmd: >{Log('1','nothing to do...')}<
2019.02.24 18:57:48 1 : nothing to do...
2019.02.24 18:57:48 5 : Cmd: >{BlockingStart('4')}<
2019.02.24 18:57:48 5 : Cmd: >{updDone('0')}<



Mehr updaten geht nicht. Den oberen Ausgabeblock bekomm ich nach update und backupeinspielen auch nachdem ich nochmal update eingebe.
Kann es daran liegen?

tux75at

Leider hatte ich zuvor von der alten Installation die Einstellung Verbose 5 übernommen, wodurch ich vor lauter Bäumen den Wald nicht mehr sehen konnte.
Folgende Zeilen sind mir heute aufgefallen:

2019.03.09 15:50:41 3: ZWave set Office_Light_Dimmer dim 29
2019.03.09 15:50:48 3: Office_Light_Dimmer: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2019.03.09 15:50:48 3: ZWave set Office_Light_Dimmer dim 56
2019.03.09 15:50:56 3: Office_Light_Dimmer: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd


Diese brachte mich dann auch zu der Logzeile:

ZWave: cannot load Crypt::Rijndael, SECURITY class disabled


und zur Lösung:

apt-get install libcrypt-rijndael-perl


Jetzt scheint es zu klappen!

Dieses Modul habe ich jetzt in meine Dokumentation aufgenommen und der Fehler wird mir so schnell nicht wieder passieren.