HMCCU kein automatische Readings-update

Begonnen von Joker, 04 Oktober 2024, 10:39:59

Vorheriges Thema - Nächstes Thema

Joker

Hi,
ich betreibe FHEM im Docker Container, und dazu Raspberrymatic in einem zweiten Docker Container. In Raspberrymatic sind ausschließlich HMIP Geräte.

Und damit habe ich aktuell das Problem, dass Readings von Geräte die über HMCCU angebunden sind, nicht automatisch aktualisiert werden.
Soll heißen, wenn ich z.B. ein Fenster mit einem HmIP-SRH aufmache, dann sehe ich in der CCU WebUI wie sich das Status entsprechend auf "Offen" ändert. Das Reading in FHEM bleibt aber auf "closed". Wenn ich im FHEM-Device ein "get update" mache, springt der Status aber sofort um auf "open".

Das hat allerdings schon mal funktioniert, und ich weiß nicht warum es nicht mehr geht...
Was könnte das Problem sein? Die RPC Server laufen, allerdings sehe ich beim Startup einmal einen Timeout... aber manuell geht es ja?

2024.10.04 10:18:19 1:  HMCCU [homematic_ccu] Delayed I/O device initialization
2024.10.04 10:18:19 3:  HMCCU [homematic_ccu] Updating device table
2024.10.04 10:18:19 2:  HMCCU [homematic_ccu] Initializing 4 client devices in state 'pending'
2024.10.04 10:18:19 1:  HMCCU [homematic_ccu] Read 8 devices with 132 channels, 0 programs, 1 virtual groups from CCU 192.168.1.203
2024.10.04 10:18:19 1:  HMCCU [homematic_ccu] Reading device config from CCU. This may take a couple of seconds ...
2024.10.04 10:18:19 2:  HMCCU [homematic_ccu] Reading device configuration for interfaces HmIP-RF
2024.10.04 10:18:19 1:  HMCCU [homematic_ccu] No RPC device defined for interface HmIP-RF
2024.10.04 10:18:19 1:  HMCCU [homematic_ccu] Creating new RPC device d_rpc001203HmIP_RF for interface HmIP-RF
2024.10.04 10:18:19 2:  HMCCURPCPROC [d_rpc001203HmIP_RF] CCU interface HmIP-RF doesn't support RPC multicalls
2024.10.04 10:18:19 1:  HMCCURPCPROC [d_rpc001203HmIP_RF] Initialized version 5.0 2024-04 for interface HmIP-RF with I/O device homematic_ccu
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] Read descriptions of 80 devices, 236 paramsets, 5 links
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] Detecting devices of interfaces HmIP-RF
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] Read RPC device configuration: devices/channels=80 parametersets=236 links=5
2024.10.04 10:18:21 1:  HMCCU [homematic_ccu] Reading device config from CCU. This may take a couple of seconds ...
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] Reading device configuration for interfaces HmIP-RF
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] Read descriptions of 80 devices, 3 paramsets, 5 links
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] Detecting devices of interfaces HmIP-RF
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] Read device configuration in 0.0839710235595703 seconds: devices/channels=80 parametersets=3 links=5
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] RPC device for interface HmIP-RF: d_rpc001203HmIP_RF
2024.10.04 10:18:21 2:  HMCCURPCPROC [d_rpc001203HmIP_RF] RPC server process started for interface HmIP-RF with PID=9154
2024.10.04 10:18:21 2:  HMCCURPCPROC [d_rpc001203HmIP_RF] Initializing RPC server CB2010000002001203 for interface HmIP-RF
2024.10.04 10:18:21 1:  HMCCURPCPROC [d_rpc001203HmIP_RF] RPC server starting
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] RPC server start: 1 started, 0 already running, 0 failed to start
2024.10.04 10:18:21 2:  HMCCURPCPROC [d_rpc001203HmIP_RF] Callback server CB2010000002001203 created. Listening on port 7420
2024.10.04 10:18:21 2:  HMCCURPCPROC [d_rpc001203HmIP_RF] CB2010000002001203 accepting connections. PID=9154
2024.10.04 10:18:21 2:  HMCCURPCPROC [d_rpc001203HmIP_RF] RPC server CB2010000002001203 enters server loop
2024.10.04 10:18:21 2:  HMCCURPCPROC [d_rpc001203HmIP_RF] Registering callback http://172.26.0.2:7420/fh2010 of type A with ID CB2010000002001203 at http://192.168.1.203:2010
2024.10.04 10:18:21 1:  HMCCURPCPROC [d_rpc001203HmIP_RF] RPC server CB2010000002001203 running
2024.10.04 10:18:21 1:  HMCCU [homematic_ccu] All RPC servers running
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] Updating 4 of 4 devices matching devexp=.* filter=ccudevstate=active,ccuif=HmIP-RF nonBlocking
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] CCU device list 2b updated: Hobbyraum.Fenster,GaesteWc.Wandthermostat,GaesteWc.Heizkoerpertermostat,GaesteWc.Fenster
2024.10.04 10:18:21 2:  HMCCU [homematic_ccu] FHEM device list 2b updated: GaesteWc.Wandthermostat,GaesteWc.Heizkoerpertermostat,GaesteWc.Fenster,Hobbyraum.Fenster
2024.10.04 10:18:25 2:  HMCCU [homematic_ccu] Error during CCU request. read from http://192.168.1.203:8181 timed out

Ralli

#1
Das mit dem Timeout ist ein uralter Fehler, dem man sich nie angenommen hat.

Nach jedem Neustart (!) der CCU bzw. Raspberrymatic läuft der allererste Verbindungsaufbau von HMCCU in ein solchen Timeout. Kann ich zu 100% reproduzieren. Während dieser Phase kannst du sehr wahrscheinlich beobachten, dass die CCU bzw. Raspberrymatic dann auch zu manchen HmIP-Devices, vornehmlich zu den batteriebetriebenen, eine Verbindungsstörung meldet. Wenn du dann einen "shutdown restart" von FHEM machst, wird die Verbindung zwischen HMCCU und CCU / Raspberrymatic ohne Timeout funktionieren. Ggf. tritt dieses Verhalten auch nur bei den Installationen auf, bei denen auch HmIP-Devices in der CCU und in HMCCU definiert sind.

Interessanterweise passiert das nicht bei einem ersten Verbindungsaufbau von dem Homematic-Modul von ioBroker zu einer neu-gestarteten CCU / Raspberrymatic.

https://forum.fhem.de/index.php?topic=123686.msg1183134#msg1183134
https://github.com/eq-3/occu/issues/122
https://forum.fhem.de/index.php?topic=91033.msg1103987#msg1103987

https://github.com/zapccu/HMCCU/issues/289
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20250220) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Joker

Ok, ja kann ich bestätigen. Wenn ich ein shutdown Restart im FHEM mache, kommt kein Timeout und stattdessen:

2024.10.04 11:03:47 2:  HMCCU [homematic_ccu] Update success=4 failed=0
2024.10.04 11:03:47 2:  HMCCU [homematic_ccu] Updated devices: GaesteWc.Fenster,Hobbyraum.Fenster,GaesteWc.Heizkoerpertermostat,GaesteWc.Wandthermostat

An meinem Problem dass die Readings nicht automatisch aktualisiert werden, ändert das aber leider nichts...

Ralli

#3
Dann stimmt entweder mit der RPC-Server-Konfiguration in FHEM was nicht oder du hast ein Port-Problem mit deinen Docker-Containern. Ohne weitere Informationen zu den Konfigurationen kommen wir nicht weiter.

Diese Zeile

2024.10.04 10:18:21 2:  HMCCURPCPROC [d_rpc001203HmIP_RF] Registering callback http://172.26.0.2:7420/fh2010 of type A with ID CB2010000002001203 at http://192.168.1.203:2010

deutet für mich darauf hin, dass da ein Netzwerk-/Port-Konfigurationsproblem in den Docker-Konfigurationen besteht.
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20250220) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Joker

Oha. Du hast recht, das ist mir echt nicht aufgefallen  :o . Die IP ist ja völlig Banane... ich hab gerade mal in älteren Logs nachgeschaut, da stand dort auch tatsächlich mal die IP von dem Gerät wo die Docker Container laufen.
Aber ich sehe den Fehler nicht...
Ich benutze docker-compose... hier mal das composeFile von Raspberrymatic:

version: "3.8"
services:
  raspberrymatic:
    image: ghcr.io/jens-maus/raspberrymatic:latest
    container_name: ccu
    hostname: ccu
    read_only: true
    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
    networks:
      ccu:
        ipv4_address: 192.168.1.203
volumes:
  ccu_data:
networks:
  ccu:
    name: ccu
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1

Interessanter ist aber vermutlich das compose file von FHEM:
services:

  fhem:
    container_name: fhem
    build:
      context: .
      dockerfile: Dockerfile.fhem
    pull_policy: build
    restart: unless-stopped
    networks:
      - fhem_net
      - mariadb_net
    ports:
      - "8083:8083"     # fhem web interface
      - "2121:2121"     # fronthem (for access from smartvisu)
    devices:
      - /dev/ttyAMA0:/dev/ttyAMA0
    volumes:
      - "/home/pi/docker-data/fhem/:/opt/fhem/"
    environment:
      FHEM_UID: 1000
      FHEM_GID: 1000
      GPIO_GID: 993

  alexa-fhem:
    container_name: alexa-fhem
    image: ghcr.io/fhem/alexa-fhem:5.0.13
    restart: unless-stopped
    networks:
     - fhem_net
    volumes:
      - "/home/pi/docker-data/alexa-fhem/:/alexa-fhem/"
    environment:
      ALEXAFHEM_UID: 1000
      ALEXAFHEM_GID: 1000
      TZ: Europe/Berlin
    depends_on:
      - fhem

networks:
  fhem_net:
    name: fhem_net
    driver: bridge
  mariadb_net:
    external: true

Was könnte denn da falsch sein, es wird ja ein normales Bridge-network verwendet?

Ralli

#5
Ich bin kein Docker-Experte, bei mir läuft alles in lxc-Containern auf Proxmox - und alle mit Bridge als unmittelbare Netzwerkteilnehmer konfiguriert.

Aber ich vermute (!), es ist die isolierte und Nicht-Bridge-Konfiguration der Raspberrymatic - da steht was von macvlan.
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20250220) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Joker

Hm... ja diese MacVlan Sache wird halt in der Beschreibung der Docker-Installation von RaspberryMatic genau so beschrieben. Aber ich verstehe die auch nicht 100%.

Jetzt habe ich mal im HMCCU device die rpserveraddr auf die IP des Docker hosts gesetzt. Nun stimmt denke ich zumindest der RPC server:
2024.10.04 12:19:37 2:  HMCCURPCPROC [d_rpc001203HmIP_RF] Registering callback http://192.168.1.131:7420/fh2010 of type A with ID CB2010000003001203 at http://192.168.1.203:2010
Leider kommt immer noch kein Status an. Dieses Thema habe ich gerade gefunden:
https://forum.fhem.de/index.php?topic=132064.0
Das hört sich ziemlich genauso an. Die dort angegeben Ports habe ich jetzt im RaspberryMatic container auch gemapped:
    ports:
      - "8081:80"
      - "2001:2001"
      - "2010:2010"
      - "9292:9292"
      - "8181:8181"
      - "7411:7411"
      - "7420:7420"
Leider keine Verbesserung.
Ich schaue mal weiter, aber ich glaube das ist die richtige Spur.

Joker

Ok, so funktioniert es:

- Im FHEM container die listening ports für die benötigten RPC server mappen (in meinem Fall HmIP und BidCos, wobei ich eigentlich nur HmIP wirklich nutze):
    ports:
      - "7411:7411"     # listening port for HMCCU BidCos-RF
      - "7420:7420"     # listening port for HMCCU HmIP-RF
- Im RaspberryMatic container: Keine Ports mappen, Konfiguration wie oben gepostet

Danke, ohne den Hinweis mit der IP wär ich da nicht so schnell drauf gekommen:
HMCCU Attribut rpcserveraddr=<IP-Adresse des Docker hosts>
Das ist wichtig damit die RPC-Server korrekt angelegt werden. Wobei das natürlich fragil ist, wenn sich die IP Adress mal ändert... dann merkt man erstmal nicht dass es nicht mehr geht.

Könnte man da auch einen hostname eintragen? Oder gibts noch eine bessere Möglichkeit?

zap

Rpcserveraddr akzeptiert auch einen Namen. Der Name muss allerdings auflösbar sein. Siehe Doku
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)