Docker-OCI / HomeAssistant und HmIP-HAP/HmIPW-DRAP Unterstützung

[jmaus]

Hallo Zusammen,

die letzten Tage habe ich mich erneut dem Thema/Problem gewidmet, das innerhalb eines RaspberryMatic Docker Container oder RaspberryMatic Add-on innerhalb von HomeAssistant kein HmIP-HAP bzw. HmIPW-DRAP nicht angelernt oder genutzt werden kann. Dies geht zurück auf https://github.com/jens-maus/RaspberryMatic/issues/1373 und begründet sich darin, das standardmäßig innerhalb eines Docker Containers kein UDP Multicasting Traffic über das virtualisierte Docker Netzwerk transferiert werden kann, diese beiden Geräte jedoch darauf angewiesen sind via UDP Multicasting erreichbar zu sein.

Nachdem ein Nutzer in dem besagten Issue-Ticket schon erste Hinweise darauf gegeben hatte, das es wohl unter Zuhilfenahme eines docker-basierten "macvlan" Netzwerkes funktionieren soll (cf. https://github.com/jens-maus/RaspberryM ... -922508274) habe ich mir das ganze etwas tiefer angeschaut und in der Tat konnte ich dafür eine Lösung erarbeiten die in einer überarbeiteten Dokumentation der Installation der Docker-Variante von RaspberryMatic gemündet ist:

https://github.com/jens-maus/RaspberryM ... Docker-OCI

Des Weiteren habe ich den bisher unter "deploy.sh" bekannten Skript zum vereinfachten installieren aller Abhängigkeiten und dem automatischen Download+Installation des RaspberryMatic Containers entsprechend überarbeitet und angepasst, sodass auch damit es nun möglich seins sollte einen HmIP-HAP/HmIPW-DRAP an ein docker-basiertes RaspberryMatic anzulernen bzw. zu nutzen.

Der neue "install-docker.sh" Skript kann nun ähnlich wie der proxmox installationsskript durch einfachen Aufruf des folgenden Kommandos unter dem jeweiligen Docker Host (z.B. Ubuntu Linux) ausgeführt werden:

Code: Alles auswählen

wget -qO - https://raspberrymatic.de/install-docker.sh | bash -

Nachdem man dann diesen Installationsskript auf seinem Docker Host durchlaufen lassen hat und er erfolgreich alle Abhängigkeiten und den Docker Container anlegen konnte fehlt dann nur noch das entsprechende "docker start ccu" Kommando um den Container starten zu lassen.

Nun interessiert mich natürlich brennend inwieweit andere Interessierte sich vor allem dem Testen der neuen Docker Anleitung bzw. Installationsprozedur annehmen könnten und vor allem mit solch einer "macvlan" Variante es dann auch reproduziert bekommen das damit man nun ein HmIP-HAP bzw. HmIPW-DRAP angelernt und auch konkret genutzt bekommt.

Und auch für die HomeAssistant Add-on Nutzer die ggf. daran interessiert sind auch einen HmIP-HAP/HmIPW-DRAP lauffähig integriert zu bekommen und die in der Vergangenheit in das selbe Problem gerannt sind wie reine Docker/OCI Nutzer, habe ich nun zumindest eine händische Lösung erarbeiten können. Da die HomeAssistant Addons ja im Grunde auch nur Docker Container sind die auf dem HomeAssistant host laufen, bedarf es auch da lediglich einer solchen "macvlan" bridge. Nun kann man diese ja leider nicht von HomeAssistant selbst (und auch nicht als Add-on) anlegen und durch ein Add-on nutzen lassen. Ich konnte jedoch eine manuelle Patch Prozedur erarbeiten die man auf seinem HA Host ausführen lassen kann und die dann auf der Kommandozeile von HomeAssistant diese bridge manuell anlegt und dem RaspberryMatic Add-on dann zur Nutzung zuweist. Dokumentiert ist das ganze entsprechend hier:

https://github.com/jens-maus/RaspberryM ... port-patch

Wenn sich also ein paar Interessierte Tester der neuen Docker Installationsanleitung/Prozedur oder des HomeAssistant Support Patches finden würden, dann wäre ich sehr dankbar, denn dann könnte ich im Falle von HomeAssistant sicherlich die Entwickler noch mehr davon überzeugen doch direkten Support in HomeAssistant einzubauen, sodass in Zukunft Add-ons wie RaspberryMatic direkt solche "macvlan" bridges nutzen können um das Addon im lokalen Netzwerk direkt verfügbar zu machen.

[jmaus]

Kurze Nachinfo meinerseits zu diesem Thema: Ich habe den Beitrag hier noch einmal überarbeitet da ich auch für den HomeAssistant Fall nun eine zumindest vorübergehende manuelle Lösung erarbeiten konnte und es nun auch für HomeAssistant möglich sein sollte nach Anwendung eines manuellen Patches das RaspberryMatic Add-on mit einem HmIP-HAP oder HmIPW-DRAP kommunizieren zu lassen. Wenn sich dafür Tester finden lassen könnten wäre das natürlich in der Tat super.

[Auweia]

Hallo Jens,
habe das script in meiner Rpi4-Docker Test-Umgebung laufen lassen, dabei habe ich festgestellt:
- das script muss als root/sudo laufen, sudo wget -q0 ..... reicht nicht
- mit der Umstellung auf MACVlan hat der Rpi4 eine neue IP-Adresse (bei DHCP) bekommen und es muss ein reboot durchgeführt werden.
- alle Programme, die auf RMatic zugreifen ( z.B.: NodeRed ccu connection) müssen auf die neue Adresse gestellt werden, außer man stellt auf DNS um.
- R-Matic läuft: RPI-RF-MOD wird erkannt und ist aktiv , DC=1 , CS=0
- alle 2 HM-Geräte laufen, das ganze ist sehr performant.
Schaut alles normal aus.

[jmaus]

habe das script in meiner Rpi4-Docker Test-Umgebung laufen lassen, dabei habe ich festgestellt:

Danke schon einmal fürs testen. Ich bin da wirklich noch auf Erfahrungsberichte anderer angewiesen um zu beurteilen ob das ganze so läuft wie ich mir das ausgedacht habe.

- das script muss als root/sudo laufen, sudo wget -q0 ..... reicht nicht

Das ist normal, wenn du das script als sudo/root aufrufen willst musst du natürlich das so machen:

Code: Alles auswählen

wget -qO - https://raspberrymatic.de/install-docker.sh | sudo bash -

d.h. das sudo muss natürlich vor dem bash aufruf stehen und nicht vor dem wget. Steht auch so übrigens in der angepassten Doku (siehe https://github.com/jens-maus/RaspberryM ... iner-setup).

- mit der Umstellung auf MACVlan hat der Rpi4 eine neue IP-Adresse (bei DHCP) bekommen und es muss ein reboot durchgeführt werden.

Das verstehe ich nicht ganz? In der Anleitung und in meinen Kommentaren oben steht doch recht klar das man mit dem macvlan beim Skriptaufruf zwei statische IP adressen **ausserhalb** des normalen DHCP Bereiches spezifieren muss (gängigerweise < 20 im hinteren Teil der IP-Adresse). Das normale Interface des Docker Hosts sollte davon unbetroffen sein. Also wo genau hat dein RaspberryPi4 bitte eine neue IP Adresse erhalten? Er sollte lediglich 1x die neue IP-Adresse des Docker Containers zugewiesen bekommen und dann noch eine (diese AUX-Adresse) beides aber statisch.

- alle Programme, die auf RMatic zugreifen ( z.B.: NodeRed ccu connection) müssen auf die neue Adresse gestellt werden, außer man stellt auf DNS um.

Das ist natürlich vollkommen normal. Du musst die externen Connections dann natürlich auf die neue IP-Adresse des Containers lenken die du diesem beim Aufruf des install-docker.sh Skriptes ja zugewiesen hast.

- R-Matic läuft: RPI-RF-MOD wird erkannt und ist aktiv , DC=1 , CS=0
- alle 2 HM-Geräte laufen, das ganze ist sehr performant.

Ein HmIP-HAP oder HmIPW-DRAP hast du nicht zufällig den du da mit testen könntest? Mich interessiert ja vor allem ob diese in der Tat auch bei anderen mit der neuen macvlan Bridge dann endlich anlernbar und auch dauerhaft gut funktionieren in einer Docker / HomeAssistant Umgebung (was ja bis dato nicht der Fall war).

[Baxxy]

Ich hätte mich ja mehr über die RaspberryMatic als .ova für mein (auf Eis gelegtes ) Pimox-Projekt gefreut, aber gut.
HA-AddOn Test (mit und ohne aktivem AddOn Watchdog gleiches Ergebnis):
Terminal:

Code: Alles auswählen

wget -qO - https://raw.githubusercontent.com/jens-maus/RaspberryMatic/master/scripts/patch-ha-addon-macvlan.sh | bash -
RaspberryMatic HA-Addon macvlan patch script
Copyright (c) 2023 Jens Maus <mail@jens-maus.de>

RaspberryMatic Add-on Hostname (e.g. 5422eb72-raspberrymatic): de838cd8-raspberrymatic-dev
RaspberryMatic Add-on IP (e.g. 192.168.178.4): 192.168.113.97
Connecting add-on to macvlan network
Restarting add-on
Error response from daemon: cannot stop container: addon_de838cd8_raspberrymatic-dev: tried to kill container, but did not receive an exit event
addon_de838cd8_raspberrymatic-dev

Das AddOn scheint nicht sauber zu rebooten, mehr ist nach ~3Minuten nicht zu sehen:

Code: Alles auswählen

Setup onboard LEDs: shutdown, OK
Stopping crond: OK
Stopping Third-Party Addons:

docker logs hassio_supervisor (wenn AddOn Watchdog aktiv):

Code: Alles auswählen

23-05-24 19:16:17 WARNING (MainThread) [supervisor.misc.tasks] Watchdog missing application response from de838cd8_raspberrymatic-dev
23-05-24 19:16:32 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon RaspberryMatic CCU (snapshot) is unhealthy, restarting...
23-05-24 19:16:32 INFO (SyncWorker_1) [supervisor.docker.interface] Stopping addon_de838cd8_raspberrymatic-dev application
23-05-24 19:16:52 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE hardware /dev/mmd_hmip - None
23-05-24 19:16:53 INFO (SyncWorker_1) [supervisor.docker.interface] Cleaning addon_de838cd8_raspberrymatic-dev application
23-05-24 19:16:54 INFO (SyncWorker_5) [supervisor.docker.addon] Starting Docker add-on ghcr.io/jens-maus/raspberrymatic with version 3.69.7.20230518-c08585a

[jmaus]

Ich hätte mich ja mehr über die RaspberryMatic als .ova für mein (auf Eis gelegtes ) Pimox-Projekt gefreut, aber gut.

Das kann ich mir vorstellen, auch wenn ich aber nicht so wirklich von Pimox überzeugt bin da das schon ein ganz schönes rumgepatches System ist nur um Proxmox auf einen Pi zu bringen der IMHO dafür aber nicht die richtige Hardwareplatform ist auf lange Sicht hin. Aber ich hab das prinzipiell weiter auf dem Schirm, wenn auch mit geringer Priorität. Erstmal will ich auch sowas LXC Container Support soweit lauffähig hinbekommen, denn das nutzen auch einige sicherlich...

HA-AddOn Test (mit und ohne aktivem AddOn Watchdog gleiches Ergebnis):

[...]

Code: Alles auswählen

[...]
Restarting add-on
Error response from daemon: cannot stop container: addon_de838cd8_raspberrymatic-dev: tried to kill container, but did not receive an exit event
[...]

Das AddOn scheint nicht sauber zu rebooten, mehr ist nach ~3Minuten nicht zu sehen:

Code: Alles auswählen

Setup onboard LEDs: shutdown, OK
Stopping crond: OK
Stopping Third-Party Addons:

Hmm, die Fehlermeldung ist komisch. Hatte ich so bei meinen Tests noch nicht. Da scheint der Container nicht korrekt gekillt zu werden bzw. braucht wohl zu lange zum runterfahren oder so und das "docker stop" kommando rennt dann in ein timeout. Und hast du das ganze mal mehrmals hintereinander probiert? Kommt da immer die gleiche Fehlermeldung beim "Restarting add-on"? kannst ja selbst mal in der kommandozeile probieren mit "docker stop addon_de838cd8_raspberrymatic" den container anzuhalten von der kommandozeile aus.

[Baxxy]

Code: Alles auswählen

docker stop addon_de838cd8_raspberrymatic-dev
addon_de838cd8_raspberrymatic-dev

Funktioniert problemlos.

[jmaus]

Code: Alles auswählen

docker stop addon_de838cd8_raspberrymatic-dev
addon_de838cd8_raspberrymatic-dev

Funktioniert problemlos.

Komisch, aber wenn du den script aufrufst reproduzierbar immer nicht? Wenn du da mal reinschaust mach ich da ja auch nichts anderes eigentlich. Vielleicht mal irgendwo ein sleep oder so einbauen damit das script länger wartet oder etwas zeit hat das letzte kommando zu verdauen?

[Baxxy]

Hatte ich schon mal erwähnt das ich kein Docker-Freund bin...

Auf jeden Fall ist die Lösung an sich funktional.
Der HAP ist am RM-HA-AddOn (mit HmIP-RFUSB) angelernt und strahlt schön in türkis vor sich hin.
Mein Workaround für die Container-Reboot-Problematik war letztlich ganz simpel...
Ich habe einfach...

Code: Alles auswählen

docker network connect --ip "${CCU_CONTAINER_IP}" ccu "addon_${CCU_CONTAINER_NAME}"

...ganz ans Ende des Scriptes verschoben. Damit wird das Netzwerk direkt beim Container-Start eingehangen.

Was so aufgefallen ist:
- Stop/Start des Containers über das Script/Portainer wirft dann einen "Unclean-Shutdown" Watchdog-Alarm.
- Bei Stop/Start des Containers per docker-command oder "Restart" über Portainer bleibt das Netzwerk bestehen.
- Laut Portainer ist das Gateway des "ccu" Netzwerkes die 192.168.113.1, das echte Gateway (Fritzbox) hat aber die .222
Scheint aber unproblematisch zu sein.

[jmaus]

Hatte ich schon mal erwähnt das ich kein Docker-Freund bin...

In der Tat. Umso dankbarer bin ich das du dich dem ganzen trotzdem hier angeschlossen hast. Danke dir dafür nochmal explizit. Ich denke aber weiterhin das auch die reine Docker Installation so ihren Platz hat und es durchaus Szenarien gibt wo es Sinn ergibt eine Docker/OCI Installation auch von RaspberryMatic zu betreiben. Es ist aber natürlich weiterhin nichts für Einsteiger!

Auf jeden Fall ist die Lösung an sich funktional.
Der HAP ist am RM-HA-AddOn (mit HmIP-RFUSB) angelernt und strahlt schön in türkis vor sich hin.

Das ist schon einmal sehr gut das hier zu lesen. Super, dann sollte prinzipiell auch die Nutzung eines HmIPW-DRAP nun damit möglich sein. Wenn sich dafür ggf. noch ein Tester/Nutzer finden könnte wäre das super, denn davon hab ich definitiv kein Gerät zum testen selbst übrig.

Mein Workaround für die Container-Reboot-Problematik war letztlich ganz simpel...
Ich habe einfach...

Code: Alles auswählen

docker network connect --ip "${CCU_CONTAINER_IP}" ccu "addon_${CCU_CONTAINER_NAME}"

...ganz ans Ende des Scriptes verschoben. Damit wird das Netzwerk direkt beim Container-Start eingehangen.

Verstehe ich immer noch nicht ganz genau? Beim vorherigen Beitrag hast du ja das Prozedere unter HomeAssistant getestet und hier jetzt aber unter einer reinen Docker/OCI Umgebung ohne HomeAssistant. Oder sprichst du jetzt hier von HomeAssistant? Ist es da definitiv von dir reproduzierbar das der Container nicht sauber neustartet durch das docker stop/start das da eigentlich ganz hinten steht? Wundert mich ehrlich gesagt das es anders herum anscheinend geht, d.h. du zuerst den container neustartest und dann das network connect machst?!? Weil das brauch man eigentlich definitiv vorher damit das network überhaupt dem container zugewiesen ist bevor dieser neugestartet wird...

Was so aufgefallen ist:
- Stop/Start des Containers über das Script/Portainer wirft dann einen "Unclean-Shutdown" Watchdog-Alarm.

Passiert das auch wenn du ein manuelles "docker stop ccu" machst und dann danach den container wieder mit start startest?

- Bei Stop/Start des Containers per docker-command oder "Restart" über Portainer bleibt das Netzwerk bestehen.

Danke, das ist in der Tat so und auch bei HomeAssistant so der Fall. Nur wird im Gegensatz bei HomeAssistant immer der gesamte container gelöscht bei einem neustart bzw. bei einem stoppen des containers. Das ist auch der Grund wieso änderungen am rootfs bei HomeAssistant nicht persistent sind.

- Laut Portainer ist das Gateway des "ccu" Netzwerkes die 192.168.113.1, das echte Gateway (Fritzbox) hat aber die .222
Scheint aber unproblematisch zu sein.

Was ist denn die .1 IP da in deinem Subnetz? Der Docker Host selbst?