HmIPW-DRAP/HmIP-HAP cannot identify RaspberryMatic as a HA addon or Docker container

Running RaspberryMatic in a standard Docker subnetwork on the host prevents a DRAP from connecting …

Steps to reproduce the behavior

1. Configure a DRAP to connect to a standalone RaspberryMatic. Make sure it can connect and the LED lights up in turquoise
2. Switch off the DRAP
3. Move your RaspberryMatic installation into a Docker container, e.g. by creating a backup and restoring from it in a freshly set up Docker installation according to the installation guide. I used the docker-compose variant of the docker setup.
4. Power up the DRAP The DRAP goes to the usual sequence of yellow, green and turqoise lights. In the end it flashes in turquoise, indicating that it wants to connect to CCU but does not find it.

Expected behavior The DRAP should discover the CCU and connect to it.

System information:

• RaspberryMatic Version: 3.59.6.20210807
• Host OS: Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-1041-raspi aarch64)
• Used Hardware: Raspberry 4
• Used HomeMatic RF-Module: RPI-RF-MOD on HB-RF-USB-2

Additional context The issue seems to be related to network discovery by UDP broadcasts. I noticed that RaspberryMatic running on bare metal is visible to EQ3’s Netfinder program, but RaspberryMatic running under Docker ist not. So I watched network traffic during Netfinder discovery.

In this example Netfinder is on 10.10.15.1, and two DRAPs are running on 10.10.15.100 und 10.10.15.101

No.	Time	Source	Destination	Protocol	Length	Info
4	0.648462575	10.10.15.1	255.255.255.255	UDP	52	43537 → 43439 Len=10
6	1.348330504	10.10.15.100	255.255.255.255	UDP	103	43439 → 43537 Len=61
7	1.410798515	10.10.15.101	255.255.255.255	UDP	103	43439 → 43537 Len=61

You can see Netfinder sending a UDP broadcast package, which is immediately answerded by the two DRAPs. I guessed that a similar mechanism might also be used by the DRAP at startup to find the CCU. However, this will fail on a standard Docker setup, because Docker does not support this kind of broadcast messages. The only easy way to fix this I know of, is to run the container in host mode like with this docker compose file:

version: "3.7"
services:
  raspberrymatic:
    image: ghcr.io/jens-maus/raspberrymatic:latest
    container_name: ccu
    hostname: homematic-raspi
    privileged: true
    restart: unless-stopped
    stop_grace_period: 30s
    network_mode: host
    volumes:
      - ccu_data:/usr/local:rw
      - /lib/modules:/lib/modules:ro

Here network_mode: host makes the container use the host network without any internal network or port mapping. Just adding this line to the docker-compose.yaml and restarting the container makes the DRAP connect and to go from flashing to solid turquoise light.

Interestingly, in my experience this problem exists only for the DRAPs. HAPs when run as a range extender to a CCU seem to have a different mechanism of network discovery.

[jens-maus]

As long as this ticket is open and not closed there is no other solution than not using the HA addon of RaspberryMatic if you want to connect it to a HmIPW-DRAP or HmIP-HAP.

[jens-maus]

Do you have an idea what I can try next?

Nothing really. If you read through this issue ticket closely you will find reference to a HomeAssistant related ticket (https://github.com/home-assistant/plugin-multicast/issues/17) which is related to the root cause of this issue: The HmIPW-DRAP and HMIP-HAP rely on UDP multicasting network traffic which is currently not correctly routed to an add-on in HomeAssistant. Thus, the HomeAssistant developers (e.g. @pvizeli) would have to work on this by enhancing their plugin-multicast accordingly. That’s the reason why this (no connectivity to a HmIPW-DRAP or HmIP-HAP) is currently a known limitation of using the RaspberryMatic add-on within HomeAssistant.