Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
die ursprüngliche Installation ware eine naive Edomi V2.03 auf einer Atom CPU auf einem Ubuntu 18 Linux. Die HW auf der der Docker läuft (laufen soll) ist eine Celeron CPU mit Ubuntu 20 (auch V2.03). Ich denke aber, dass es nicht an der HW liegt.
Und wie gesagt: Edomi läuft wie erwartet. Erst nach dem Einspielen des Backups entsteht mein Problem. Kein Zugang per Browser. Ich erreiche aber den Container per web. Auch Edomi meldet sich ja nach Aufruf von 192.168.178.XX/admin , nur der Anmeldedialog bleibt aus (siehe Bild oben). Somit bin ich abgeschnitten.
Erst nach dem Einspielen des Backups entsteht mein Problem. Kein Zugang per Browser. Ich erreiche aber den Container per web.
...
Hab ich was vergessen?
Ja und zwar die wichtigste Information: Was sagt das Edomi-Log?
Hab auch gerade noch den Log nach dem restore und vor dem reboot abgefangen:
--------------------------------------------------------------------------------
edomirestore.sh
Restore wird gestartet
--------------------------------------------------------------------------------
TERM environment variable not set.
rm: cannot remove '/usr/local/edomi': Device or resource busy
--------------------------------------------------------------------------------
Restore abgeschlossen. Reboot in 5 Sekunden...
--------------------------------------------------------------------------------
Exiting container with return value 1 to trigger Docker restart
Die global_visuIP scheint es nicht zu sein.
Hat Edomi auch nach dem ersten Start im docker Container. Habe Sie dann abgeänder und neu gestartet. -> Mein Eintrag wurde überschrieben. global_visuIP='172.17.0.2 ist wie zuvor. Und Edomi per Browser erreichbar.
Wenn kein Backup eingespielt funktioniert Edomi auch mit der Einstellung global_visuIP='172.17.0.2'.
--> An global_visuIP='172.17.0.2' liegt es nicht.
Nachdem ich das Backup einspiele erreiche ich Edomi nicht mehr per Browser (Es kommt zwar das angehängte Bild. Aber kein Login Dialog).
Ansonsten scheint alles zu funktionieren. grafik.png
Mir ist vor gut einer Woche meine edomi-Installation abgeraucht.
Bei der Neuinstallation dachte ich mir "Probier halt mal die Docker-Geschichte aus, so schwer kann das ja nicht sein...".
Wie habe ich mich geirrt - ich bin seit mehreren Tagen komplett am verzweifeln.
Vorab - Ich bin mehr oder minder Laie was Linux und Netzwerkstrukturen, etc. betrifft. Bisher bin ich durch meine hohe Frustrationstoleranzgrenze aber immer irgendwie ans Ziel gekommen ;-) Also bitte geht nicht zu hart mit mir ins Gericht.
Was ist das Problem?
Der Container läuft mittlerweile. Webinterface und edomi-Adminseite sind erreichbar.
Backup konnte ich auch schon entsprechend einspielen (passenderweise ist mir vorgestern auch noch mein NAS abgeraucht und ich habe die letzten beiden Tage damit verbracht das RAID in Linux zum Laufen zu bekommen und irgendwie die dort gespeicherten edomi-Backups zu retten...).
KNX-Verbindung kann allerdings nicht aufgebaut werden.
Ich vermute es liegt an den verschiedenen Subnetzen, IP-Adressen und Ports:
2022-08-14 10:21:26
318134
KNX
441
CE > | DESCRIPTION_REQUEST / Timeout nach 10s / ErrMsg: Kein DESCRIPTION_RESPONSE vom Router erhalten
ERROR
2022-08-14 10:21:26
328763
KNX
441
KNX-Verbindung verloren.
ERROR
2022-08-14 10:21:39
339109
KNX
441
CE > | DESCRIPTION_REQUEST / Timeout nach 10s / ErrMsg: Kein DESCRIPTION_RESPONSE vom Router erhalten
ERROR
2022-08-14 10:21:39
349817
KNX
441
KNX-Verbindung verloren.
ERROR
2022-08-14 10:21:43
401926
MAIN
429
ACHTUNG: Keine KNX-Verbindung möglich (Timeout)!
Docker läuft auf einem Rechner mit der IP 192.168.2.124, der Container selbst bekommt eine IP aus dem Subnetz 192.168.2.0/24 (im konkreten Fall die 192.168.2.2) zugewiesen, das habe ich entsprechend über macvlan so eingestellt.
Die IP des Containers ist anderweitig nicht vergeben, das habe ich schon geprüft.
edomi Webinterface ist über die 192.168.2.2/admin ganz normal erreichbar.
KNX IP-Router hat die IP 192.168.2.5 - ist auch im Netzwerk erreichbar. Gruppenmonitor in der ETS zeigt auch regen Busverkehr.
Die Installation lief mit edomi als "standalone" in CentOS jetzt mehrere Jahre ohne Probleme.
Ich bin mir relativ sicher, dass ich irgend eine Einstellung in Docker verbockt habe - allerdings habe ich, wie gesagt, (noch) nicht genügend Ahnung von der ganzen Materie um meinen Kopf selbst aus der Schlinge zu ziehen.
Wäre für jeden Tip äußerst dankbar!
Grüße,
Johannes
EDIT:
Steter Tropfen höhlt den Stein. Die KNX-Verbindung steht. Man sollte dann schon die Readme-Datei gründlich genug lesen, auch wenn man vielleicht nicht alles direkt versteht.
Host-IP war falsch gesetzt, ich habe jetzt sämtliche IP-Zuweisungen aus dem Container Startscript rausgenommen und sie manuell in edomi gesetzt, jetzt funktioniert es erstmal.
Eine Frage habe ich aber trotzdem noch, ich hoffe, die passt hier rein:
Kann ich dem edomi container eine feste IP zuweisen? Subnetz habe ich ja bereits zugewiesen, aber der Container bekommt, so wie ich es nachvollziehen konnte, immer die erste freie IP aus dem Pool zugewiesen. Ich möchte aber eine vorher fest definierte IP-Adresse für den Container vergeben, also anstatt bspw. der 192.168.2.2 die 192.168.2.125. Nach kurzer Recherche im Netzt scheint das nicht wirklich trivial zu sein und ich möchte nicht meine mühsam erreichten Fortschritte direkt wieder zerschießen
Zuletzt geändert von Vielfrass; 14.08.2022, 12:00.
Kann ich dem edomi container eine feste IP zuweisen?
Das ganze MacVLAN-Geraffel ist eine Krücke. Wenn Du mich fragst, ist das der Workaround für all die, welche nicht verstanden haben, wie Docker funktioniert oder für die Software, die nicht mit Docker umgehen kann.
Edomi kann's aber, von daher würde ich mir MacVLAN gleich schenken, das macht nicht wirklich Sinn an der Stelle. Wenn Du also nicht wirklich triftige Gründe hast, MacVLAN zu verwenden, dann lass es weg.
Unabhängig davon: Ohne zu wissen, wie genau Du den Container startest, ist jegliche Hilfe schwierig... Dazu kommt die Frage, welches Image Du genau verwendest! Also welche Version?
Das ganze MacVLAN-Geraffel ist eine Krücke. Wenn Du mich fragst, ist das der Workaround für all die, welche nicht verstanden haben, wie Docker funktioniert...
Bingo Ich bin was die ganze Docker-Geschichte angeht momentan absoluter Nichtschwimmer. Was ja nicht heißt, dass ich das bis an mein Lebensende bleiben muss. Habe eigentlich immer Spaß daran, mich in neue Themen einzuarbeiten, auch wenn es mit viel Fluchen und Mühe verbunden ist.
Die Docker-Thematik war aber, glaube ich, eine Nummer zu groß für mich. Das habe ich aber erst mittendrin festgestellt, und einfach kneifen will ich jetzt auch nicht
Die Zuordnung des Subnetzes mache ich dann nach dem Start des Containers über Portainer.
Image ist die latest-Version.
Wenn ich irgendwie auf den ganzen MacVLAN-Kram verzichten kann, ist mir das nur recht. War jetzt auf die Schnelle halt das einzige, was ich mit meinem bescheidenen Fachwissen zumindest so weit verstanden habe, dass ich es zum laufen bringen konnte.
Nach knapp einer Woche ohne edomi (und meiner Wenigkeit von morgens bis abends bei Reparatuversuchen vor dem Rechner) hängt der Haussegen hier schon ein bisschen schief. Da war mir in erster Instanz erstmal wichtig, dass das System überhaupt wieder irgendwie ans Laufen kommt.
"Schön" machen kann ich es ja jetzt im Anschluss
Ok, mit diesem Setup bist Du hier falsch. Die Parameter beziehen sich auf die RockyLinux-Version des Images, verwenden tust Du aber die "alte" Variante. Von daher ist hier in diesem Thread schluss.
Bitte hier weitermachen, sprich dort das erste Posting lesen und auch das dort angegebene Image verwenden. Dass Du keine KNX-Verbindung bekommst, liegt übrigens mit grosser Wahrscheinlichkeit daran, dass Du KNX gar nicht aktiviert hast, siehe Doku auf Github.
Zuletzt geändert von starwarsfan; 14.08.2022, 14:49.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar