Hi,
ich weiß nicht, ob das eine Rolle spielt, aber ich habe FHEM und RaspberryMatic in 2 Containern auf einem RPI4 laufen.
Mein Problem:
Ich habe mehrere Homematic-IP Thermostate, die alle in FHEM sind und sobald ich den RPC-Server starte, werden alle Readings aktualisiert. Auch funktioniert die Steuerung der Thermostate aus FHEM heraus problemlos, d.h. ich kann die Temp erhöhen, etc pp.
Was aber nicht funktioniert ist, dass die Readings aktualisiert werden. D.h. wenn ich manuell am Thermostat die Temp ändere oder sich die Temperatur ändert, wird dies in FHEM nicht angezeigt...
Ich verstehe nichts von der Kommunikation zw. RPC-Server und RaspberryMatic, aber irgendwas stimmt da icht. Hat jemand eine Idee?
Im Log von RaspberryMatic steht Folgendes:
2022-11-23 14:30:59,136 io.vertx.core.impl.ContextImpl ERROR [vert.x-worker-thread-10] Unhandled exception
de.eq3.cbcs.legacy.communication.rpc.RpcIOException: java.net.ConnectException: Connection refused (Connection refused)
at de.eq3.cbcs.legacy.communication.rpc.internal.transport.http.HttpTransport.sendRequest(HttpTransport.java:110) ~[HMIPServer.jar:?]
at de.eq3.cbcs.legacy.communication.rpc.internal.rpc.RpcClient.sendRequest(RpcClient.java:94) ~[HMIPServer.jar:?]
at de.eq3.cbcs.legacy.communication.rpc.internal.rpc.RpcClient.invoke(RpcClient.java:82) ~[HMIPServer.jar:?]
at com.sun.proxy.$Proxy40.event(Unknown Source) ~[?:?]
at de.eq3.ccu.virtualdevice.service.internal.rega.vertx.RegaClientWorker.handleEvent(RegaClientWorker.java:73) ~[HMIPServer.jar:?]
at de.eq3.ccu.virtualdevice.service.internal.rega.vertx.RegaClientWorker.access$000(RegaClientWorker.java:13) ~[HMIPServer.jar:?]
at de.eq3.ccu.virtualdevice.service.internal.rega.vertx.RegaClientWorker$1.handle(RegaClientWorker.java:35) ~[HMIPServer.jar:?]
at de.eq3.ccu.virtualdevice.service.internal.rega.vertx.RegaClientWorker$1.handle(RegaClientWorker.java:26) ~[HMIPServer.jar:?]
at io.vertx.core.impl.AbstractContext.dispatch(AbstractContext.java:100) ~[HMIPServer.jar:?]
at io.vertx.core.impl.WorkerContext.lambda$emit$0(WorkerContext.java:59) ~[HMIPServer.jar:?]
at io.vertx.core.impl.WorkerContext.lambda$execute$2(WorkerContext.java:104) ~[HMIPServer.jar:?]
at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76) ~[HMIPServer.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_342]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_342]
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[HMIPServer.jar:?]
at java.lang.Thread.run(Thread.java:750) ~[?:1.8.0_342]
Caused by: java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:1.8.0_342]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[?:1.8.0_342]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[?:1.8.0_342]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[?:1.8.0_342]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:1.8.0_342]
at java.net.Socket.connect(Socket.java:613) ~[?:1.8.0_342]
at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:120) ~[HMIPServer.jar:?]
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:179) ~[HMIPServer.jar:?]
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144) ~[HMIPServer.jar:?]
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:134) ~[HMIPServer.jar:?]
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:612) ~[HMIPServer.jar:?]
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:447) ~[HMIPServer.jar:?]
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:884) ~[HMIPServer.jar:?]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) ~[HMIPServer.jar:?]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) ~[HMIPServer.jar:?]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) ~[HMIPServer.jar:?]
at de.eq3.cbcs.legacy.communication.rpc.internal.transport.http.HttpTransport.sendRequest(HttpTransport.java:106) ~[HMIPServer.jar:?]
... 15 more
Hilft das weiter?
Zitat von: maddhin am 23 November 2022, 14:46:30
aber ich habe FHEM und RaspberryMatic in 2 Containern auf einem RPI4 laufen.
Beide Container im gleichen Docker Netzwerk?
Hintergrund meiner Frage: Es braucht mehrere Ports für die Kommunikation, die Firewall der RaspberryMatic muss offen sein usw.
Gruß Otto
Ja, beide Container sind im gleichen Docker-Netzwerk und unter rpcServerAddr habe ich den (Docker-)Hostnamen (homematic-raspi) eingetragen. Die richtige Docker-IP wird auch unter ip, etc. angezeigt.
In RaspberryMatic sind Ports offen, 2x Homematic-API-Vollzugriff und unter IP-Adressen mit eingeschränktem Zugriff:
192.168.0.1;
192.168.0.0/16;
fc00::/7;
fe80::/10
Es wundert mich, dass eigentlich alles funktioniert, nur die Werte dann nicht mehr aktualisiert werden. Irgendwo fehlt hier noch ein Häckchen... :)
typischerweise haben die container im docker 172.er Adressen ???
Beide Container laufen im Hostmodus?
Aber vielleicht geht meine Idee in die falsche Richtung ...
mit der 172er IP-Adresse habe ich es auch probiert, hat aber am Verhalten nichts geändert. Der Hostname ist mir lieber, falls sich die Docker-IPs mal ändern.
Hostmodus sagt mir leider nichts :-[ Ich habe etwas darüber gegooglet, aber da FHEM und RaspberryMatic über die LAN IP erreichbar sind, sollte das eigentlich richtig konfiguriert sein, oder?
Theoretisch muss das Problem da sein, wo sich der RPC-Server zum 2. Mal die Daten von RaspberryMatic holen will. Das funkt ja nicht. Der initiale Abruf und die Kommunikation zu RaspberryMatic geht ja problemlos. Vielleicht sind das aber andere Kommunkationswege und die Verbindung mit dem RPC-Server geht bei mir grundsätzlich nicht. Da bin ich überfragt.
Normalerweise rpcServerAddr auf die IP-Adresse des Docker Containers setzen, in dem FHEM läuft. Hostnamen werden vermutlich nicht unterstützt.
Zitat von: maddhin am 23 November 2022, 17:57:03
aber da FHEM und RaspberryMatic über die LAN IP erreichbar sind, sollte das eigentlich richtig konfiguriert sein, oder?
Nein, da liegst Du falsch.
Wie sieht Deine docker Definition aus? Dort definierst Du normal port mappings!
Innerhalb vom docker Netzwerk sind alle Ports erreichbar, von außen (vom Host) nur die gemappten!
Das Thema mit den Ports hatten wir schon mal
https://forum.fhem.de/index.php/topic,129310.msg1236166.html#msg1236166
Aus der Docker Compose von Fhem:
version: '3.8'
services:
##FHEM
fhem:
#image: fhem/fhem:latest
#image: ghcr.io/fhem/fhem-experimental:dev
image: ghcr.io/fhem/fhem/fhem-docker:bullseye
container_name: fhem
privileged: true
restart: unless-stopped
ports:
- "8083:8083"
- "7072:7072"
- "3002:3002"
volumes:
- ./fhem/core/:/opt/fhem/
networks:
- fhem-network
#devices:
# - "/dev/ttyUSB0:/dev/ttyUSB0"
environment:
FHEM_UID: 1000
FHEM_GID: 1000
TIMEOUT: 10
RESTART: 1
TELNETPORT: 7072
TZ: Europe/Berlin
APT_PKGS: "python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl libjson-perl libwww-perl libsoap-lite-perl libjson-xs-perl librpc-xml-perl"
NPM_PKGS: "alexa-fhem alexa-cookie2"
CPAN_PKGS: "Net::MQTT::Constants Net::MQTT::Simple"
#PIP_PKGS: "fhempy"
depends_on:
- "mariadb"
- "mqtt"
networks:
fhem-network:
driver: bridge
Docker-Compose für RasberryMatic:
version: '3.8'
services:
## GENERAL
raspberrymatic:
image: ghcr.io/jens-maus/raspberrymatic:latest
container_name: ccu
#Achtung der Hostname ist als Ziel IP in FHEM eingetragen
hostname: homematic-raspi
privileged: true
restart: unless-stopped
stop_grace_period: 30s
volumes:
- ./ccu_data:/usr/local:rw
- /lib/modules:/lib/modules:ro
- /run/udev/control:/run/udev/control
ports:
- "8086:80"
- "2001:2001"
- "2010:2010"
- "9292:9292"
- "8181:8181"
#RaspeberryMatic zu FHEM-Netzwerk hinzufügen um erreichbar zu sein
networks:
default:
name: fhem-docker_fhem-network
external: true
Ich habe jetz auch noch
- 7411:7411 # rpc for hmccu only hm
- 7420:7420 # rpc for hmccu hm-ip
in FHEM Docker Compose freigegeben, das macht aber leider auch keinen Unterschied.
Könnte ich in irgendeinem Log ein Indiz finden, wo das Problem sein könnte?
die beiden Netzwerk Abschnitte sind mir zu kompliziert - ich behaupte: damit sind beide nicht im gleichen Netzwerk:
Zitatnetworks:
fhem-network:
driver: bridge
Zitat#RaspeberryMatic zu FHEM-Netzwerk hinzufügen um erreichbar zu sein
networks:
default:
name: fhem-docker_fhem-network
external: true
Die würde ich beide streichen ;)
Mal meine als Beispiel https://github.com/heinz-otto/raspberry/tree/master/Docker
pivccu.yml und fhem.yml
beide gestrichen und jetzt habe ich definitiv 2 Netzwerke. Eines mit 172.20.0.X und eines mit 172.21.0.x. - wohl weil ich ccu und fhem in unterschiedlichen Ordnern auf der HDD habe.
D.h. ich muss ein Netzwerk definieren.
Ich könnte es jetzt nochmal mit "network_mode: host" bei allen Containern probieren. Aber ist das Problem wirklich das Netzwerk? Die Kommunikation zw. FHEM und CCU funktioniert per se ja.
nö - weil Du zwei compose Dateien hast. Warum betreibst Du das nicht in einer?
Das ist doch gerade der Vorteil von docker compose: Das zusammengehörige Netzwerk, die zusammengehörigen Container in einer config!?
Das mit dem Host mode ist unnötig.
BTW: man kann auch einzelne compose Dateien zusammenstarten:
docker-compose -f deconz.yml -f sonos.yml -f fhem.yml -f pivccu.yml up
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
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...
Sorry ich will nicht alles durcheinander wirbeln.
Aber nochmal zum Verständnis: innerhalb des docker Netzwerkes sind die Maschinen auf allen Ports erreichbar. Von außerhalb, also über das Hostnetzwerk musst Du jedes Port definieren. Der Host hat natürlich jedes Port nur einmal, d.h. mehrere Container können das gleiche Port intern verwenden, mappen zum gleichen Hostport kann es nur einer!
Du sagst immer Netzwerk geht ja: Das mag für einen Port stimmen, muss aber nicht für alle notwendigen gelten.
Namensauflösung innerhalb des docker Netzwerkes ist auch noch mal eine andere Geschichte.
Also arbeite erstmal mit IP Adressen. Und führe Kommunikation von Container zu Container nicht unnötig außen herum.
Du kannst übrigens die IPs der Container per docker-compose.yml auch festlegen.
Am besten ist immer, wenn man ein "Projekt" in "einer" docker-compose.yml packt. Insofern hat Otto definitiv Recht.
Namensauflösung bei verschiedenen docker-compose.yml ist ein seeeehr schwieriges Thema. Würde ich deshalb nicht machen.
Kannst Du uns ml Deine Zusammengefasste yml geben?
Hallo, ich habe jetzt mal alles in eine docker-compose.yml gepackt und jeglichen Netzwerkskram rausgenommen (hatte ich davor auch schon, aber jetzt ist ccu explizit in der gleichen .yml):
version: '3.8'
services:
##FHEM
fhem:
#image: fhem/fhem:latest
#image: ghcr.io/fhem/fhem-experimental:dev
image: ghcr.io/fhem/fhem/fhem-docker:bullseye
container_name: fhem
hostname: fhem
privileged: true
restart: unless-stopped
ports:
- "8083:8083" # fhem-web
- "3002:3002" # echo devices
- "7072:7072" # fhem-telnet
- "7411:7411" # rpc for hmccu only hm
- "7420:7420" # rpc for hmccu hm-ip
volumes:
- ./fhem/core/:/opt/fhem/
#networks:
# - fhem-network
#devices:
# - "/dev/ttyUSB0:/dev/ttyUSB0"
environment:
FHEM_UID: 1000
FHEM_GID: 1000
TIMEOUT: 10
RESTART: 1
TELNETPORT: 7072
TZ: Europe/Berlin
APT_PKGS: "python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl libjson-perl libwww-perl libsoap-lite-perl libjson-xs-perl librpc-xml-perl"
NPM_PKGS: "alexa-fhem alexa-cookie2"
CPAN_PKGS: "Net::MQTT::Constants Net::MQTT::Simple"
#PIP_PKGS: "fhempy"
depends_on:
- "mariadb"
- "mqtt"
##fhempy
fhempy:
#image: ghcr.io/fhem/fhempy-docker:latest
image: ghcr.io/fhem/fhempy-docker:releases-1.3-beta
container_name: fhempy
hostname: fhempy
restart: unless-stopped
ports:
- "15733:15733"
#networks:
# - fhem-network
depends_on:
- "fhem"
#habridge:
# restart: always
# image: habridge/ha-bridge-raspberrypi3
# volumes:
# - ./habridge/data/:/ha-bridge/data
# - /etc/localtime:/etc/localtime:ro
# - /etc/timezone:/etc/timezone:ro
# network_mode: host
homebridge:
restart: unless-stopped
container_name: homebridge
hostname: homebridge
#image: oznu/homebridge:raspberry-pi
image: oznu/homebridge:latest
ports:
- "8581:8581"
- "8081:8081"
volumes:
- ./homebridge:/homebridge
security_opt:
- seccomp:unconfined
environment:
- TZ=Europe/Berlin
- PGID=1000
- PUID=1000
- HOMEBRIDGE_CONFIG_UI=1
- HOMEBRIDGE_CONFIG_UI_PORT=8081
#network_mode: host
logging:
driver: json-file
options:
max-size: "10mb"
max-file: "2"
depends_on:
- "fhem"
mariadb:
#image: hypriot/rpi-mysql
image: lscr.io/linuxserver/mariadb:latest
container_name: mariadb
hostname: mariadb
restart: unless-stopped
expose:
- "3306"
- "33060"
ports:
- "3306:3306"
- "33060:33060"
volumes:
#- ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
#- ./mysql/data:/var/lib/mysql
- ./mariadb:/config
- ./init/create_fhem_db_mysql.sql:/docker-entrypoint-initdb.d/init.sql
environment:
- TZ=Europe/Berlin
- PGID=1000
- PUID=1000
- MYSQL_ROOT_PASSWORD=XXXXXX
- MYSQL_DATABASE=fhem
- MYSQL_USER=fhemuser
- MYSQL_PASSWORD=XXXXXX
#networks:
# - fhem-network
mqtt:
container_name: mqtt
hostname: mqtt
restart: unless-stopped
expose:
- "1883"
- "9001"
ports:
- "1883:1883"
- "9001:9001"
#image: pascaldevink/rpi-mosquitto
image: eclipse-mosquitto:latest
#networks:
# - fhem-network
volumes:
- ./mqtt/config/:/mosquitto/config/
- ./mqtt/log/:/mosquitto/log/
- ./mqtt/data/:/mosquitto/data/
nodered:
container_name: nodered
hostname: nodered
restart: unless-stopped
expose:
- "1880"
ports:
- "1880:1880"
#image: elzekool/rpi-nodered
image: nodered/node-red
volumes:
- ./nodered/data/:/root/.node-red/
#networks:
# - fhem-network
depends_on:
- "mqtt"
grafana:
image: grafana/grafana:latest
container_name: grafana
hostname: grafana
expose:
- "3000"
ports:
- "4000:3000" #port change because of Alexa-Skill port 3000
restart: unless-stopped
user: "1000"
volumes:
- ./grafana/provisioning/datasources:/etc/grafana/provisioning/datasources
- ./grafana:/var/lib/grafana
environment:
#- GF_PATHS_CONFIG="./grafana/etc/grafana.ini"
- GF_SECURITY_ADMIN_PASSWORD=XXXXXX
- GF_AUTH_ANONYMOUS_ENABLED=true
- GF_AUTH_ANONYMOUS_ORG_NAME=Main Org.
- GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
- GF_AUTH_ANONYMOUS_HIDE_VERSION=true
- GF_SECURITY_ALLOW_EMBEDDING=true
#networks:
# - fhem-network
duplicati:
image: duplicati/duplicati:latest
container_name: duplicati
hostname: duplicati
restart: unless-stopped
# Recommendation: Duplicati needs root user to get access to all files
#user: "ROOTPUID:1000:ROOTPGID:1000"
#network_mode: bridge
ports:
- "8200:8200"
volumes:
- ./duplicati:/data:rw
- /docker/backups:/backups:rw
- ./:/source:ro
environment:
- TZ=Europe/Berlin
#networks:
# - fhem-network
#alexa-fhem:
# #image: fhem/alexa-fhem:latest
# image: ghcr.io/fhem/fhem/alexa-fhem:2
# restart: unless-stopped
# ports:
# - "3000:3000"
# volumes:
# - ./alexa-fhem/:/alexa-fhem/
# environment:
# - ALEXAFHEM_UID=1000 #6062
# - ALEXAFHEM_GID=1000 #6062
# - TZ=Europe/Berlin
# networks:
# - fhem-network
# depends_on:
# - "fhem"
raspberrymatic:
image: ghcr.io/jens-maus/raspberrymatic:latest
container_name: ccu
hostname: ccu #Achtung der Hostname ist ggf als Ziel IP in FHEM eingetragen
privileged: true
restart: unless-stopped
stop_grace_period: 30s
volumes:
- ./ccu_data:/usr/local:rw
- /lib/modules:/lib/modules:ro
- /run/udev/control:/run/udev/control
ports:
- "8086:80"
- "2001:2001"
- "2010:2010"
- "9292:9292"
- "8181:8181"
#networks:
# - fhem-docker_fhem-network
#networks:
# fhem-network:
# driver: bridge
Stur wie ich bin, bin ich immernoch skeptisch, dass es an einem nicht verfügbaren Port liegt, lasse mich aber sehr sehr gerne eines besseren belehren;)))
Meine Linux-Kenntinisse sind beschränkt, aber ich kann gerne irgendwie testen, welche Ports offen oder nicht sind.
Ich neige jetzt dazu, HMCCU in FHEM nochmal komplett neu aufzusetzen. Vielleicht hat sich irgendwo, irgendwann, irgendwie was verhaspelt. Da ich im Log, etc. keine Fehlermeldungen finde, liegt es vielleicht daran, dass irgendwo ein Attribut oder ähnliches gesetzt wurde, was die Readings nicht schreibt o.ä.
Lieben Dank für Eure Hilfe!
Zitat von: maddhin am 23 November 2022, 23:17:45
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
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?
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*
Was wir sagten, Netzwerkproblem
Du solltest Dich mit Netzwerk in Docker nochmals beschäftigen.
Zitat von: Wernieman am 24 November 2022, 13:30:02
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...
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 ;)
Zitat von: Otto123 am 24 November 2022, 16:30:25
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 ..."
fhem:
depends_on:
- "mqtt"
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!
Zitat von: Otto123 am 24 November 2022, 16:30:25
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
fhem:
depends_on:
- "ccu" #hier entsprechenden Namen des RaspberryMatic Prozesses lt. docker-compose eintragenfunktioniert es auch ohne network_mode: host!
Zitat von: maddhin am 24 November 2022, 19:30:51
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 ?
Zitat von: maddhin am 24 November 2022, 17:07:56
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 ;)
ZitatIst 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.