HMCCU/Docker: Readings werden nicht aktualisiert

[zap]

jain, ich wollte FHEM und z.B. Backup, Portainer, phpmyadmin, etc. eigentlich als separate Pakete. Wahrscheinlich ne philosophische Frage...

Habe jetzt das nach Deiner Art umgestellt, aber da tut sich nichts. Im Gegenteil, jetzt werden die devices nicht mal mehr beim Starten des RCP-Servers aktualisiert.

Ein

Code: [Auswählen]

HMCCU [d_ccu] Error during CCU request. read from http://172.20.0.4:8181 timed out
ist mal aufgetaucht. Vielleicht ein Indiz, aber der RPC-Server meckert sonst nicht und alles fährt ohne Fehlermeldung hoch.

Werde weitersuchen...

Diese Meldung hat nichts mit RPC zu tun. Hier kann FHEM nicht auf die CCU zugreifen. Ist denn 172.20.0.4 die IP der CCU? Ist auf der CCU die Firewall freigeschaltet?

[maddhin]

Heureka! Ich habe jetzt die ccu in das host Netzwerk (network_mode: host in docker-compose) "gestellt" und die IP des RPI als DEF angegeben und es funktioniert nun! Bei homebridge ist das auch so. Wieso genau, weiß ich nicht, aber es funktioniert nun *glücklich*

[Wernieman]

Was wir sagten, Netzwerkproblem

Du solltest Dich mit Netzwerk in Docker nochmals beschäftigen.

[maddhin]

Was wir sagten, Netzwerkproblem

Du solltest Dich mit Netzwerk in Docker nochmals beschäftigen.

Naja, gut, ich habe aber jetzt ja genau das getan, was Ihr gesagt habt, was ich nicht tun soll: ich habe die ccu aus dem Docker-FHEM-Netzwerk rausgenommen und greife jetzt ja über die externe IP auf die ccu zu. Als wäre die ccu extern. Eigentlich nur ein Workaround.

Wieso das funktioniert und wieso es nicht im "internen" Docker-Fhem-Netzwerk (172.x.x.x) verstehe ich in der Tat nicht und muss das mal lernen. Was mir aber überhaupt nicht einleuchtet: wieso funktioniert die Docker-Fhem-Netzwerk-Lösung bei anderen, aber bei mir nicht? Offensichtlich muss man da noch irgendwo was anders einstellen...

[Otto123]

ich stelle fest: ich muss das auch alles nochmal durchspielen und noch besser dokumentieren. Meine derzeitige Doku von einer Installation von vor einem Jahr ist lückenhaft.

Was mir noch einfällt: Der ccu Container muss laufen bevor man FHEM startet. Ansonsten kann sich FHEM nicht verbinden. Trotz Timeout hat das bei mir damals nicht funktioniert. Ich hatte dann die Startreihenfolge abhängig gemacht, finde aber gerade nicht wie ich das gemacht habe. 

Ich finde Deine Konfiguration jetzt sehr dahin gebastelt das es irgendwie läuft, da gäbe es noch viel zu verbessern. Und Du solltest vor allem wissen warum es läuft

Ich wäre immer nur in Ausnahmefällen dazu bereit sowas wie network_mode: host oder privileged einzusetzen. Das ist wie: alles einfach unter root laufen lassen

[OdfFhem]

Ich hatte dann die Startreihenfolge abhängig gemacht, finde aber gerade nicht wie ich das gemacht habe. 

"... You can control the order of service startup and shutdown with the depends_on option ..."

Code: [Auswählen]

fhem:
  depends_on:
    - "mqtt"


[maddhin]

Wenn die Doku die unter HMCCU ist, dann habe ich mich daran gehalten. Ich fand die eigentlich gut:)

Im Grund muss man auch mal bei Homebridge gucken, da ist ja genau das gleiche Problem.

Ich stimme auch voll zu, was die Flickschusterei angeht. Das ist allerdings ein Kompetenz- und Zeitproblem. Ich kenne mich zum Einen nicht gut genug aus und zum Anderen fehlt mir die Zeit die technisch perfekte Lösung zu erarbeiten (es geht -> fertig). Der Wille zum Erarbeiteten ist da bei mir zum Glück nicht das Problem.

Gerade was Docker angeht, würde ich mir eigentlich auch mehr in der Fhem-Community „erwarten“. Ich meine das jetzt nicht unbedingt negativ sondern als Plus. Wenn man z.B. ein schön sauber konfiguriertes docker-compose zur Verfügung stellen würde und ggf immer das docker-compose im Wiki hätte, wäre das für alle ein Gewinn. Meiner Meinung nach können auch viele Fragen im Forum durch Docker gelöst werden, wenn jeder das gleiche Image benutzt, etc.

Aber meine Intension ist nicht hier zu kritisieren, aber ich habe immer etwas den Eindruck, dass Docker immernoch etwas stiefmütterlich behandelt wird. Das ist aber rein philosophisch und hat jetzt mit diesem Thema eigentlich nichts direkt zu tun Bitte nicht falsch verstehen!

[maddhin]

Was mir noch einfällt: Der ccu Container muss laufen bevor man FHEM startet. Ansonsten kann sich FHEM nicht verbinden.

Das war der entscheidende Tipp!!

Mit

Code: [Auswählen]

fhem:
  depends_on:
    - "ccu" #hier entsprechenden Namen des RaspberryMatic Prozesses lt. docker-compose eintragen
funktioniert es auch ohne network_mode: host!

[OdfFhem]

Das war der entscheidende Tipp!!

Klingt erst mal gut, aber was macht man, wenn nicht alle abhängigen docker-Container auf demselben Host laufen ?

Bei mir liegt FHEM auf Host1; MQTT,UniFi auf Host2; usw.
Nachweislich sorgt auch ein reboot eines benötigten Host nicht für den Verlust der Funktionalität - lediglich für eine kurze Unterbrechung.

Ist ccu diesbezüglich empfindlicher ?

[Otto123]

Wenn man z.B. ein schön sauber konfiguriertes docker-compose zur Verfügung stellen würde und ggf immer das docker-compose im Wiki hätte, wäre das für alle ein Gewinn.

Es gibt ja Beispiele auf Github https://github.com/fhem/fhem-docker/blob/dev/docker-compose.yml
Die Welt ist eben bunt. Sieht man ja an Deiner Zusammenstellung. Am Ende gibt es genau so viele Beispiele für docker-compose wie Anwender

Ist ccu diesbezüglich empfindlicher ?

Das weiß ich nicht, aber die Spezialität ist die RPC Kommunikation.
[OT] Seit dem ich diese kenne (hat Kleinstweich mal irgendwann in den ersten Windows Versionen implementiert) lief die theoretisch ganz einfach und praktisch hat es immer geklemmt und einen Haufen Randbedingungen gegeben. Ich bekomme immer ein Kratzen im Hals, wenn ich RPC höre. [/OT]
Mit dieser Erfahrung sage ich, man muss für RPC Kommunikation Bedingungen einhalten. Und hier scheint es so zu sein: Die CCU muss laufen wenn der FHEM RPC andocken will.