Edomi im Docker-Container - RockyLinux (x86_64 & aarch64)

[ThorstenGehrig]

Kleines Update von meiner Seite: ich habe ein Backup mal manuell installiert (umbenannt in ".tar" am ende - dann tar -xvf backup.tar -C / ) - und es läuft.
Keine Ahnung warum es über die GUI nicht geklappt hat... es hat "ewig" Auspgepackt (backup hat 1.6 GB)... vielleicht war es ein Timeout.
Anyhow.. das nur als Tipp falls nochmal jemand ein Problem beim recover hat :-)

Gruß
Thorsten

[Pendragon]

Danke an Yves für die schöne Portierung und "einfache" Image. Es hat mich dann doch einen Tag und eine kleine Kapitulation gekostet es zum laufen zu bekommen.

Ich habe es zunächst versucht als Bridge zum laufen zu bringen. Da natürlich Port 80 von Openmediavault dort belegt ist, musste ich ausweichen und habe es absolut nicht hinbekommen. Erst als ich nicht mehr auf Port 88 sondern auf Port 80 gemappt habe konnte ich auf die Admin Seite zugreifen. Bei der Visu drehte sich aber nur der rote Kreis...
Hier die NICHT FUNKTIONIERENDE Compose:

services:
Edomi2:
container_name: Edomi
image: starwarsfan/edomi-docker:amd64-latest
restart: on-failure
environment:
- PUID=$PUID
- PGID=$PGID
- TZ=$TZ
- KNXACTIVE=true
- KNXGATEWAYIP=192.168.2.145
- KNXGATEWAY=192.168.2.145
- HTTPPORT=8085
- WEBSOCKETPORT= 8085
- KNXGATEWAYPORT=3671
- HOSTIP=192.168.2.179
hostname: "Edomi"
ipc: "private"
mac_address: "02:42:ac:11:00:10"
network_mode: "bridge"
ports:
- 8085:80
- 50000:50000/udp
- 50001:50001/udp
- 22222:22
volumes:
- edomi-db:/var/lib/mysql
- /srv/dev-disk-by-uuid-9ec9b5a8-c948-4286-b43a-995fb00d8aec/Multimedia/CONFIG/Edomi/backup:/var/edomi-backups
- /srv/mergerfs/Mergerpool/Public:/mnt/Public
- edomi-installation:/usr/local/edomi
volumes:
edomi-db:
external: true
edomi-installation:
external: true​

Weiterhin ist bei Durchsicht der Konsole aufgefallen, dass nicht nur KNXGATEWAYIP sondern auch KNXGATEWAY abgefragt wird. Davon habe ich in der Doku nichts gelesen.

Heute morgen hatte ich dann die Schnauze voll und bin ins macvlan gegangen.

services:
Edomi2:
container_name: Edomi
image: starwarsfan/edomi-docker:amd64-latest
restart: on-failure
environment:
- PUID=${PUID}
- PGID=$PGID
- TZ=$TZ
- KNXACTIVE=true
- KNXGATEWAYIP=192.168.2.145
- KNXGATEWAY=192.168.2.145
- KNXGATEWAYPORT=3671
- HOSTIP=192.168.2.182
hostname: "Edomi"
networks:
IOBroker:
ipv4_address: 192.168.2.182
mac_address: "02:42:c0:a8:02:b7"
ports:
- 80:88
- 50000:50000/udp
- 50001:50001/udp
- 22222:22
volumes:
- edomi-db:/var/lib/mysql
- /srv/dev-disk-by-uuid-9ec9b5a8-c948-4286-b43a-995fb00d8aec/Multimedia/CONFIG/Edomi/backup:/var/edomi-backups
- /srv/mergerfs/Mergerpool/Public:/mnt/Public
- edomi-installation:/usr/local/edomi
volumes:
edomi-db:
external: true
edomi-installation:
external: true
networks:
IOBroker:
external: true
name: "IOBroker"​

Damit läuft alles ohne Probleme: KNX, MQTT, etc. Danke nochmal!

Keine Ahnung warum es über die GUI nicht geklappt hat

Das Problem hatte ich gestern auch. Alle meine Updates sind beim widerherstellen fehlgeschlagen. Ich schrieb es gerade schon in dem anderen Thread: Wenn die root-Platte inkl. dem temporären Backup auf 100% ist (direkt nach Erstellen des manuellen Backup mal df in der Konsole ausführen), dann wird das Update nicht genommen.
Nachdem ich Platz gemacht habe und vermutlich ein "End-Flag" in dem Update File geschrieben wurde, dann wird erst das Backup angewendet.
Bei dir würde ich (wenn es genauso ist) vermuten, dass in dem Backup Daten fehlen

[starwarsfan]

Hi

Es hat mich dann doch einen Tag und eine kleine Kapitulation gekostet es zum laufen zu bekommen.

Hm, das wundert mich...

Ich habe es zunächst versucht als Bridge zum laufen zu bringen. Da natürlich Port 80 von Openmediavault dort belegt ist, musste ich ausweichen und habe es absolut nicht hinbekommen. Erst als ich nicht mehr auf Port 88 sondern auf Port 80 gemappt habe konnte ich auf die Admin Seite zugreifen. Bei der Visu drehte sich aber nur der rote Kreis...

Ja ist klar. Aber warum es nicht ging, siehst Du gleich weiter unten... ;

Hier die NICHT FUNKTIONIERENDE Compose:

services:
Edomi2:
container_name: Edomi
image: starwarsfan/edomi-docker:amd64-latest
...

Du weisst schon, dass Du hier ein vier Jahre altes Image verwendest? Das scheint noch aus der Zeit zu sein, als es noch kein Multiarch-Image gab oder das Websocket-Handling noch nicht sauber funktioniert hat. Aktuell ist "latest" oder 2.03.10

- WEBSOCKETPORT= 8085

Hier ist ein Space vor dem Port aber ich vermute, dass es nicht funktioniert, weil Du diese Variable explizit gesetzt hast! Muss das im Detail anschauen aber Du hast hier ein Überbleibsel aus früheren Zeiten gefunden. Das heisst, dass wenn diese Variable gesetzt ist, selbige in die Edomi-Konfiguration eingetragen wird. Das braucht es aber nicht mehr, weil mit dem aktuellen Dockerimage eben nur noch genau ein Port für den Zugriff benötigt wird, welcher auf den internen Port 88 gemappt werden muss. Der vorgeschaltete nginx im Image handhabt dann das Handling des Websocket.

Weiterhin ist bei Durchsicht der Konsole aufgefallen, dass nicht nur KNXGATEWAYIP sondern auch KNXGATEWAY abgefragt wird. Davon habe ich in der Doku nichts gelesen.

Wo genau hast Du das gesehen? Diese Variable wird nirgendwo verwendet.

Heute morgen hatte ich dann die Schnauze voll und bin ins macvlan gegangen.
...
Damit läuft alles ohne Probleme: KNX, MQTT, etc. Danke nochmal!

Es gab mittlerweile diverse Verbesserungen am Image. Du solltest entweder "latest" verwenden oder die Version angeben.


Anyway, danke für's Feedback!

[Pendragon]

Es gab mittlerweile diverse Verbesserungen am Image. Du solltest entweder "latest" verwenden oder die Version angeben.

Ich habe mich doch nur an die Anleitung aus Git gehalten...
image.png
Dort wird genau das Image mit den Tags vorgegeben. Ich werde aber gleich mal

starwarsfan/edomi-docker:latest

probieren.

Hier ist ein Space vor dem Port aber ich vermute, dass es nicht funktioniert, weil Du diese Variable explizit gesetzt hast! Muss das im Detail anschauen aber Du hast hier ein Überbleibsel aus früheren Zeiten gefunden. Das heisst, dass wenn diese Variable gesetzt ist, selbige in die Edomi-Konfiguration eingetragen wird. Das braucht es aber nicht mehr, weil mit dem aktuellen Dockerimage eben nur noch genau ein Port für den Zugriff benötigt wird, welcher auf den internen Port 88 gemappt werden muss. Der vorgeschaltete nginx im Image handhabt dann das Handling des Websocket.

Habe das auch ohne die Variable probiert. An der wird es vermutlich nicht liegen.

Wo genau hast Du das gesehen? Diese Variable wird nirgendwo verwendet.

Hier habe ich das gesehen, aber liegt vermutlich am alten image:
image.png-------------------------------------------------------------------------------------------------------------------------------

Update: Bin jetzt auf latest.

Und der Wahnsinn: ES GEEEEEEHT!
(Kaum macht man es richtig, funktioniert es auch)

Magst du vielleicht die Git Seite updaten oder soll ich ich nen Pull Request schreiben?

[starwarsfan]

Hi

Update: Bin jetzt auf latest.

Und der Wahnsinn: ES GEEEEEEHT!
(Kaum macht man es richtig, funktioniert es auch)

Na das hört man gern. Vermutlich war das genau einer der Changes von Deiner alten Version zum aktuellen Stand in der 2.03.10. Könnte man im Git natürlich herausfinden aber sooo wichtig isses nun ja auch nicht mehr.

Magst du vielleicht die Git Seite updaten oder soll ich ich nen Pull Request schreiben?

Oh, wenn Du einen PR machen würdest, gerne!

[mfd]

Ich hoffe die Anfängerfrage passt hier rein:
als EDOMI noch nicht virtualisiert lief hatte ich bei mir den Wake on LAN LBS in Benutzung (LBS 19000150). Seit dem Umzug in die VM will dieser aber nicht mehr funktionieren. Ich vermute, dass die Ursache in der Virtualisierung zu suchen ist, aber wo genau?

[wintermute]

Ich vermute, dass die Ursache in der Virtualisierung zu suchen ist, aber wo genau?

Ist das Binary /sbin/ether-wake im Container eventuell nicht vorhanden? Der LBS ruft das auf...

[mfd]

Gerade überprüft, ether-wake ist vorhanden.
Muss ggf. an der Angabe Interface (vormals eth0) etwas geändert werden?

[wintermute]

Dann wirds wohl generell schwierig
Sender und Empfaenger vom Paket muessen in derselben Kollisionsdomaene liegen (also quasi am selben Ethernetkabel) - wenn dein Hypervisor fuer die Container ein eigenes Netzwerk aufzieht (wie zB docker das im Standard tut), dann wird das nicht klappen. Der Container muesste sich mit dem Host die Netzwerkkarte "teilen" (also Host Networking), ausserdem muss UDP Broadcasting aus dem Container heraus moeglich sein.

[mfd]

Der Container muesste sich mit dem Host die Netzwerkkarte "teilen" (also Host Networking), ausserdem muss UDP Broadcasting aus dem Container heraus moeglich sein.

Ersteres könnte man zumindest theoretisch wohl noch umstellen, die Sache mit dem UDP Broadcasting erscheint mir aber nicht beeinflussbar.
Heißt ich muss mir mittelfristig wohl eine andere Aufweck-Möglichkeit ausdenken und der LBS funktioniert im Container nicht mehr.

[henfri]

so sollte es doch gehen:
https://chatgpt.com/share/670f8120-c...0-3f46a3c36f60

Im Wesentlichen das Netz als Bridge konfigurieren.

[mfd]

Im Wesentlichen das Netz als Bridge konfigurieren.

Der Container läuft bei mir auf einer Synology, nicht unter Proxmox. Das Netzwerk ist bereits als bridge konfiguriert...

[mfd]

Einen einheitlichen Lösungsansatz konnte ich nicht finden.
Es wird an verschiedenen Stellen die Einstellung

`--network=host`

empfohlen.

Allerdings will ich mir damit nicht andere (schlimmere) Baustellen aufmachen...

[starwarsfan]

Hallo miteinander,

mit "network=host" wird die Kapselung des Containers in (s)einem eigenen Netz aufgehoben. Das hat mitunter sehr "spannende" Nebeneffekte und wenn man nicht weiss was man tut, sollte man da lieber die Finger davon lassen. Details siehe https://docs.docker.com/engine/network/

[mfd]

mit "network=host" wird die Kapselung des Containers in (s)einem eigenen Netz aufgehoben. Das hat mitunter sehr "spannende" Nebeneffekte

Deshalb war auch mein Gedanke das lieber nicht auszuprobieren.