piVCCU - Virtualisierte CCU für Raspberry und Tinkerboard

[deimos]

Hi,

ich war lange auf der Suche nach einer Lösung, wie ich auf einem einzelnen Raspberry Pi mit Funkmodul sowohl Homematic, wie auch Openhab 2 laufen lassen kann.

Erster Versuch war Raspberrymatic - Super Sache, wenn man nur Homematic laufen lassen will. Ein CCU Addon für Openhab habe ich testweise erstellt, aber es lief leider nicht wirklich rund.

Zweiter Versuch war YAHM - Guter Ansatz, aber einiges hat mich da ziemlich gestört:
- Kernel auf Rasbperry kompilieren --> heißt Buildsystem muss auf Produktivsystem installiert werden
- Kernel kann nicht ohne weiteres aktualisiert werden
- Anpassungen an der Firmware um das Funkmodul und HmIP erst abzuschalten um es dann später wieder anzuschalten
- Backups nicht kompatibel mit der CCU
- Es werden komische Pakete wie z.B. sendmail automatisch installiert
(Vieles davon ist sicherlich der Tatsache geschuldet, das YAHM den Ansatz hat, auch ohne Funkmodul und auch auf anderen Platformen zu laufen, aber für meinen Zweck stört das eher)

Darum habe ich jetzt selbst ein Projekt gestartet, welches die Original CCU Firmware in einem LXC Container unter Raspbian zum Laufen bringt, diese aber über einen Cross-Compiler auf Ubuntu erstellt und als deb Packages bereitstellt, so dass sich die eigentliche Installation auf dem Raspberry auf die Anpassung von ein paar Config Files und der Installation von Paketen über apt beschränkt und somit auch gut von Linux Einsteigern durchführbar.

Eine Anleitung, die Skripte, so wie fertige deb Packages habe ich unter https://github.com/alexreinert/piVCCU veröffentlicht, vielleicht hilft das ja dem einen oder anderen.

Viele Grüße
Alex

[eiGelbGeek]

Idee ist gut..... aber der PI ist zu schwach für beides *wie ich finde*

Cooler wäre es die CCU zu dockern ..... und dann beides z.b. auf ein APU Board laufen lassen.
https://shop.tronico.net/Embedded-Compu ... board.html

oder einen Intel NUC wenn man noch mehr Dinge laufen lassen will


Gesendet von iPhone mit Tapatalk

[eiGelbGeek]

Wobei das eigentlich auch nicht geht [emoji23]
Das Funkmodul versteht sich vermutlich nicht ohne weiteres mit einen APU Board


Gesendet von iPhone mit Tapatalk

[deimos]

Idee ist gut..... aber der PI ist zu schwach für beides *wie ich finde*

Das kommt sicher auf die Größe der Installation an. Bei langweilt sich der Pi, obwohl schon beides drauf läuft. Aber mit insgesamt nur grob 50 Geräten ist das auch noch recht überschaubar.

[ptweety]

Hi deimos,

cooles Projekt. Das Kernel backen runter vom Raspi zu nehmen ist doch schon mal der richtige Weg. Toll wäre, wenn du es noch schaffen könntest, nur die drei Module zu bauen und für die originalen Kernel bereitzustellen. Hast du da schon mal reingeschaut?

https://github.com/eq-3/occu/issues/33
https://github.com/jens-maus/RaspberryMatic/issues/38
https://www.raspberrypi.org/forums/view ... 7&t=169800

[deimos]

Toll wäre, wenn du es noch schaffen könntest, nur die drei Module zu bauen und für die originalen Kernel bereitzustellen.

Ja, das wäre schön, geht aber leider nicht, da im originalen Kernel ein Treiber fest (nicht als Modul) einkompiliert ist und der sich mit dem Uart Modul beißt.
Daher der Ansatz, die Originalsourcen zu holen und komplett zu bauen.

[jmaus]

Erster Versuch war Raspberrymatic - Super Sache, wenn man nur Homematic laufen lassen will. Ein CCU Addon für Openhab habe ich testweise erstellt, aber es lief leider nicht wirklich rund.

Wo ist dein Versuch ein OpenHab CCU Addon für RaspberryMatic zu bauen. Her damit!

[jmaus]

Toll wäre, wenn du es noch schaffen könntest, nur die drei Module zu bauen und für die originalen Kernel bereitzustellen.

Ja, das wäre schön, geht aber leider nicht, da im originalen Kernel ein Treiber fest (nicht als Modul) einkompiliert ist und der sich mit dem Uart Modul beißt.
Daher der Ansatz, die Originalsourcen zu holen und komplett zu bauen.

Das sollte totzdem gehen. Mit einem entsprechend entwickeltem Device Tree Overlay wie in den URLs von pwtweety beschrieben sollte sich automatisch das bcm2835_raw_uart kernel Modul laden lassen mit gleichzeitiger abschalten des amba_pl011 kernel Treibers der den UART normalerweise blockiert. Wenn man solch ein device tree overlay bauen sollte dann müsste man in der Tat nicht mehr jeden kernel neu kompilieren müssen sondern müsste nur das device tree overlay file (*.dtb) in das /boot directory legen und fertig.

Der einfach Grund wieso ich solch ein Device Tree Overlay bisher nicht gebaut habe ist, das es für RaspberryMatic selbst nicht notwendig ist weil ich da ohnehin über alles direkte Kontrolle haben inkl. Kernel Modulen, etc.

[deimos]

Wo ist dein Versuch ein OpenHab CCU Addon für RaspberryMatic zu bauen. Her damit!

Wie geschrieben, lief nicht wirklich rund und ich habe es irgendwann aufgegeben. Grundsystem bekommt man zum Laufen, wenn man in allen Startscripten die bash durch sh ersetzt, aber bei den Addons die ich brauche lief es nicht. Und Verwaltung ist dann echt Käse, weil Samba nicht vorhanden ist. Fertig verpackt in Pakete ist dann doch schöner.

[deimos]

Toll wäre, wenn du es noch schaffen könntest, nur die drei Module zu bauen und für die originalen Kernel bereitzustellen.

Ja, das wäre schön, geht aber leider nicht, da im originalen Kernel ein Treiber fest (nicht als Modul) einkompiliert ist und der sich mit dem Uart Modul beißt.
Daher der Ansatz, die Originalsourcen zu holen und komplett zu bauen.

Das sollte totzdem gehen. Mit einem entsprechend entwickeltem Device Tree Overlay wie in den URLs von pwtweety beschrieben sollte sich automatisch das bcm2835_raw_uart kernel Modul laden lassen mit gleichzeitiger abschalten des amba_pl011 kernel Treibers der den UART normalerweise blockiert. Wenn man solch ein device tree overlay bauen sollte dann müsste man in der Tat nicht mehr jeden kernel neu kompilieren müssen sondern müsste nur das device tree overlay file (*.dtb) in das /boot directory legen und fertig.

Der einfach Grund wieso ich solch ein Device Tree Overlay bisher nicht gebaut habe ist, das es für RaspberryMatic selbst nicht notwendig ist weil ich da ohnehin über alles direkte Kontrolle haben inkl. Kernel Modulen, etc.

Interessanter Ansatz. Werde ich mir bei Gelegenheit mal anschauen.