Frage zu einer geplanten Erweiterung nach HM-IP und Migration HomeMatic

[mähschaf]

Guten Abend!

Ich betreibe einer Raspberry Pi 4 mit u. a. HomeMatic über einer VCCU aus einem HM-MOD-RPI-PCB und einem HM-CFG-USB2.

Ich habe heute festgestellt, dass drei meiner unsmarten Wandthermostate den Geist aufgegeben haben. Das ist die Gelegenheit, zu HomeMatic-IP Thermostaten mit 230V-Ausgang (150628A0) zu wechseln.
Als Software-CCU habe ich mich nach einigem Lesen für debmatic entschieden (Container möchte ich dafür jetzt nicht nutzen, so lange nicht nötig). Wenn ich das richtig verstanden habe, wird debmatic über das Modul HMCCU angebunden.

Ich tue mich allerdings schwer mit einem Migrationsplan der vorhandenen HomeMatic-Sensoren und Aktoren und wüsste gerne, ob das irgendwie elegant(er) geht. Wahrscheinlich habe ich aber auch nicht alles richtig verstanden und würde mich freuen, wenn ich Fehler schon bei der Planung und nicht erst während oder nach der Durchführung bemerke bzw. darauf hingewiesen werden kann.

Also - Mein Ablaufplan (Version 0.1):

1. Image-Backup der SD-Karte (es geht nichts über einen Weg zurück)
2. List aller HomeMatic-Devices (will keines vergessen)
3. Alle HomeMatic-Devices löschen
4. Die VCCU und die beiden HM-IOs löschen
5. Ggf. die /boot/config.txt anpassen, falls für HM-MOD-RPI-PCB andere Voraussetzungen gelten sollten aus für debmagic
6. hmland für HM-CFG-USB2 deaktivieren (ich habe gelesen, debmatic krallt sich den USB-Stick von ganz alleine)
7. debmatic installieren
8. Über die Weboberfläche die HomeMatic-Devices nach und nach wieder einrichten/pairen, Devicenamen und Readingnamen anpassen etc.
9. HMCCU einrichten
10. ggf. DOIFs, Notifys etc. anpassen
11. Die neuen HomeMatic-IP-Wandthermostate mit der debmatic-CCU pairen
12. Fertig?

Gibt es evt. einen eleganteren Weg?

Schönen Abend,
Martin

[zap]

Du kannst HMCCU und CUL_HM auch parallel nutzen. Oder Du nimmst HMCCU und debmatic für HmIP und migrierst nach  und nach (immer wenn ein altes Gerät kaputtgeht) auf HmIp.

[mähschaf]

Interessante Idee, Danke!

Es ist aber nicht so, dass sich debmatic und CUL_HM eine gemeinsame IO-Schnittstelle teilen können, oder?
Die Idee wäre also, dass ich eine der beiden IO-Schnittstellen für HM-IP/HMCCU nutze und eine für HM/CUL_HM?

[frank]

jedes io kann nur eine zentrale haben.
für hmip geht eh nur dein hmuart.
der hmusb dann für cul_hm. theoretisch kann debmatic so konfiguriert werden, dass sie sich nicht den hmusb "krallt".

[mähschaf]

Ja, das habe ich dort https://forum.fhem.de/index.php/topic,97295.msg1053302.html#msg1053302 gelesen, wie das geht. Finde ich interessant, mache ich vermutlich auch. Kann das HM-CFG-USB2 ja später immer noch dazu holen...

Ansonsten würde mein "Migrationsplan" in Deinen Augen sonst aber so ungefähr Sinn machen?

[frank]

wie zap schon sagte: "nach und nach".
hmip geht sowieso nur über hmccu, also damit beginnen und kennenlernen.
der rest kann dann in ruhe weiterarbeiten. 

[mähschaf]

Klasse, Danke für die Tips!

[Pfriemler]

Ich würde empfehlen, die Geräte einzeln zu migrieren (auch wenn das sch...viel Arbeit ist), aber Du kannst das nach und nach umziehen und behältst bis auf die gerade umziehenden Geräte ein funktionsfähiges System.

Aufpassen noch falls eigene AES-Schlüssel vergeben wurden: In diesem Fall sollte zuerst der Originalschlüssel vergeben werden.
Wenn Du die Geräte bei FHEM einfach alle löschst, wähnen sie sich trotzdem noch mit der FHEM-Zentrale verbunden und verweigern dann unter Umständen ein Anlernen an debmatic. Man kann die Geräte daher auch FHEM "unpair"en (unbedingt: NICHT resetten!), dann behalten sie eventuelle Direktverknüpfungen bei und diese werden auch beim Anlernen an debmatic übernommen.

jm2c
von jemandem, der das schon seit zwei Jahren vor sich hin schiebt...

[mähschaf]

Zuerst die gute Nachricht: Habe die drei defekten Wandthermostate gegen HM-IP ausgetauscht. Die funktionieren auch ohne Zentrale erst einmal, so dass mir nicht mehr kalt ist

OK, die aktuelle Version 0.2 des Migrationsplanes:

1. Image-Backup der SD-Karte (es geht nichts über einen Weg zurück)
2. List aller HomeMatic-Devices (will keines vergessen). Außerdem speichere ich mir jeweils zu jedem Gerät die "Probably associated with" ab, damit ich später alle Abhängigkeiten erfasse.
3. Dump meiner configDB
4. Das Gerät in FHEM für HM-MOD-RPI-PCB löschen. (erst set <NAME> close, dann delete) Dadurch wird die VCCU um dieses Gerät ärmer.
5. debmatic installieren (https://github.com/alexreinert/debmatic/blob/master/docs/setup/raspberrypi.md)
6. Ggf. die /boot/config.txt anpassen, falls für HM-MOD-RPI-PCB andere Voraussetzungen gelten sollten aus für debmagic
7. /etc/default/debmatic: AVOID_HM_CFG_USB_2=1
8. For i in DEVICE do: Gerät in FHEM 1. unpair und 2. löschen; über die Weboberfläche einrichten/pairen, Devicenamen und Readingnamen anpassen etc. ; done
9. HMCCU einrichten
10. ggf. DOIFs, Notifys etc. anpassen
11. Die neuen HomeMatic-IP-Wandthermostate mit der debmatic-CCU pairen
12. Fertig?

Habe das auch direkt ausprobiert und bin bis Schritt 7 gekommen. Doof ist, dass mein FHEM auf Bullseye läuft, unterstützt werden nur Stretch und Buster. Habe zwar gelesen, dass es auch auf Bullseye funktioniert, aber da es das bei mir nicht so gut tut (später mehr), bin ich unsupported....

Probleme gab es bei folgenden Schritten:

3. Den dump der configDB habe ich in FHEM mit dem Befehl "configdb dump" machen wollen. Die erzeugte Datei hatte 384 Byte. Das machte mich stutzig und richtig: Außer ein paar Metainformationen waren keine Daten enthalten. Muss ich mir später noch mal angucken. Habe dann stattdessen einen Dump mit phpMyAdmin gemacht.

5. Bei der Installation hat debmatic gemeckert, dass in einem Verzeichnis /lib/.../source die Kernel-Sourcen nicht enthalten seien. Das Verzeichnis gibt es allerdings auch gar nicht, der Verzeichnisbaum endet eine Ebene darüber (vermutlich unterschiedet das Bullseye von Buster und Stretch?). Installation brach jedoch nicht ab und lief trotzdem durch.

Die Weboberfläche war dann auch verfügbar. Wenn ich das auf die Schnelle richtig verstanden habe, werden zwei lighttpd-Instanzen gestartet, von denen eine die Weboberfläche der OCCU bereitstellt und eine als Reverse-Proxy fungiert. Das war etwas tricky, da ich auf meinem System bereits apache2 laufen habe und ich da natürlich erst mal Portkonflikte beseitigen musste. debmagic-info aber lieferte eigentlich nur zurück, dass nichts gefunden wurde: keine Kernelmodule, keine Hardware.

Da ich - wie gesagt - ein unsupportetes Betriebssystem einsetze, werde ich einfach abwarten, bis debmatic bullseye unterstützt und dann weiter berichten.

So long - bleibt gesund!

[deimos]

Hi,

debmatic läuft auch auf Bullseye, aber es ist ein guter Punkt, ich muss das auf Github anpassen. Dein Problem mit den Kernel Header dürfte daran liegen, dass du neuere Kernel Header installiert hast, als den bei dir aktiv laufenden Kernel. Daher erstmal den lokalen Kernel mit apt aktualisieren, dann rebooten und dann debmatic installieren.

Bei Schritt 7 solltest du beim Pfad den Tippfehler rausnehmen: /etc/default/debmatic wäre besser, weil die komplette Software debmatic und nicht debmagic heißt.

Viele Grüße
Alex

[mähschaf]

Hallo Alex,

Danke für den Hinweis, habe die Magie durch Technik ersetzt 

Das mit der unpassenden Kernel-Version kann eigentlich nicht sein, glaube ich. Ich habe das aber sicherheitshalber nochmal überprüft:

Code Auswählen Erweitern

pi@fhem ~ $ uname -a
Linux fhem 5.10.52-v7l+ #1441 SMP Tue Aug 3 18:11:56 BST 2021 armv7l GNU/Linux
pi@fhem ~ $ ls -l /lib/modules/
insgesamt 0
drwxr-xr-x 1 root root 442 18. Aug 20:00 5.10.52+
drwxr-xr-x 1 root root 442 18. Aug 20:00 5.10.52-v7+
drwxr-xr-x 1 root root 442 18. Aug 20:00 5.10.52-v7l+
drwxr-xr-x 1 root root 442 18. Aug 20:00 5.10.52-v8+

Das angemeckerte Verzeichnis ist allerdings /lib/modules/5.10.52-v7l+/source, was es schlicht nicht gibt:

Code Auswählen Erweitern

pi@fhem ~ $ ls -l /lib/modules/5.10.52-v7l+
insgesamt 2408
drwxr-xr-x 1 root root     76 18. Aug 19:58 kernel
-rw-r--r-- 1 root root 589135 28. Jul 00:15 modules.alias
-rw-r--r-- 1 root root 612037 28. Jul 00:15 modules.alias.bin
-rw-r--r-- 1 root root  14388 28. Jul 00:15 modules.builtin
-rw-r--r-- 1 root root  26918 28. Jul 00:15 modules.builtin.alias.bin
-rw-r--r-- 1 root root  15966 28. Jul 00:15 modules.builtin.bin
-rw-r--r-- 1 root root  81212 28. Jul 00:15 modules.builtin.modinfo
-rw-r--r-- 1 root root 195585 28. Jul 00:15 modules.dep
-rw-r--r-- 1 root root 270735 28. Jul 00:15 modules.dep.bin
-rw-r--r-- 1 root root    324 28. Jul 00:15 modules.devname
-rw-r--r-- 1 root root  65075 28. Jul 00:15 modules.order
-rw-r--r-- 1 root root    380 28. Jul 00:15 modules.softdep
-rw-r--r-- 1 root root 256007 28. Jul 00:15 modules.symbols
-rw-r--r-- 1 root root 312517 28. Jul 00:15 modules.symbols.bin

Schönen Abend!

[deimos]

Hi,

zeig bitte mal die genaue Fehlermeldung. Bei Debian ist es schon seit Jahren so, dass /usr/src die Header liegen und ich wüsste nicht, dass sich da mit bullseye was geändert hätte.
/lib/modules wäre ein alternativer Pfad, welcher aber bei Debian nicht für die Header genutzt wird, sondern nur für Daten aus dem installierten Kernel. Daher ist der "Beweis", dass Header und Kernel zusammen passen auch nicht zwingend korrekt.

Viele Grüße
Alex

Viele Grüße
Alex

[mähschaf]

N'abend

Die Fehlermeldung ist hier:

Code Auswählen Erweitern

pivccu-modules-dkms (1.0.64) wird eingerichtet ...

Creating symlink /var/lib/dkms/pivccu/1.0.64/source ->
                 /usr/src/pivccu-1.0.64

DKMS: add completed.
Error! echo
Your kernel headers for kernel 5.10.52-v7l+ cannot be found at
/lib/modules/5.10.52-v7l+/build or /lib/modules/5.10.52-v7l+/source.
You can use the --kernelsourcedir option to tell DKMS where it's located.
Created symlink /etc/systemd/system/multi-user.target.wants/pivccu-dkms.service                                                                                                                                                                                                                                                                      → /lib/systemd/system/pivccu-dkms.service.
Created symlink /etc/systemd/system/debmatic.service.wants/pivccu-dkms.service →                                                                                                                                                                                                                                                                      /lib/systemd/system/pivccu-dkms.service.
Created symlink /etc/systemd/system/pivccu.service.requires/pivccu-dkms.service                                                                                                                                                                                                                                                                      → /lib/systemd/system/pivccu-dkms.service.
Trigger für man-db (2.9.4-2) werden verarbeitet ...

Ich habe mal geschaut, tatsächlich installiert Raspbian eine "unpassende" Header-Version, vermutlich einfach die aktuellste?

Code Auswählen Erweitern

pi@fhem ~ $ dpkg -L raspberrypi-kernel-headers
[...]
/lib/modules/5.10.63+/build
/lib/modules/5.10.63-v7+/build
pi@fhem ~ $

Also müsste ich entweder auch den Kernel passend updaten oder eine ältere Version der Header, verstehe.

Ich probiere das aus, sobald ich Zeit habe.

Danke & schönen Abend,
Martin