RaspberryMatic: HmIPW-DRAP/HmIP-HAP cannot identify RaspberryMatic as a HA addon

FYI: After some more work and tests with HomeAssistant I was able to create a manual patch procedure to create the necessary macvlan docker bridge also within HomeAssistant and assign the RaspberryMatic add-on to use this macvlan bridge, thus being directly connected to the respective LAN subnet. See here for the respective documentation on how to apply this patch procedure on your HomeAssistant / RaspberryMatic add-on installation while the HA developers are still working on directly providing this functionality for add-ons like ours here:

https://github.com/jens-maus/RaspberryMatic/wiki/Installation-HomeAssistant#hmip-haphmipw-drap-support-patch

After applying this patch procedure to a running RaspberryMatic add-on it should be indeed reachable via the assigned ip address, thus communication with a local HmIP-HAP or HmIPW-DRAP in the same LAN segment should then work as expected. Note, however, that there still exists a quite strong limitation for this patch procedure, namely the point that upon reboot of HomeAssistant or even restart of the RaspberryMatic add-on one has to manually re-apply this patch procedure.

Nevertheless, if there are some HA/RaspberryMatic users out there waiting for HmIP-HAP/HmIPW-DRAP support, feel free to test this manual patch procedure and please report back if this solves your issues until the HA developers are directly integrating a more convenient solution in a future version.

FYI: Please note that discussion regarding general support for macvlan docker container support in HomeAssistant has actually started. See here:

https://github.com/home-assistant/architecture/discussions/1034

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.

Very well done, Jens. I Backed up my Raspberrymatic environment and installed HomeAssistant on a fresh hard drive, enabled RPI-RF-MOD. Then added the raspberrymatic addon and restored Raspberrymatic. It restored fine but then got stuck afterwards, so I ignored that, installed the Advanced SSH console via the Store (need to remember setting a password afterwards), launched it and followed your instructions. All went absoluteley fine and I now have a steady connection between the HA Raspberrymatic Addon and my HmIP-DRAP. Let’s hope the HA folks are able to pick this up much quicker now. Thanks again for working on it!

Please note, that I was finally able to work on that topic again and now at least for the plain docker container / OCI use case it should be possible to use a HmIP-HAP or HmIPW-DRAP if following my updated documentation at https://github.com/jens-maus/RaspberryMatic/wiki/Installation-Docker-OCI and potentially also using the new install-docker.sh helper script as explained there.

This script (and the docu) utilizes a macvlan docker network setup now like previously explained by @dkadioglu (cf. https://github.com/jens-maus/RaspberryMatic/issues/1373#issuecomment-922508274) and thus should allow the docker container to communicate via UDP multicasting to a HmIP-HAP or HmIPW-DRAP and also make it unnecessary to open dedicated ports because the container will receive a dedicated ip address from the same subnet and thus should act as a “real” RaspberryMatic CCU (also with its own firewall setup).

However, please note, that for the HomeAssistant Add-on use case the issue/limitation discussed here still applies because it is currently not possible to setup the HA add-on docker container to work on dedicated docker networks, thus not being able to use a macvlan docker network. This is still something the HA developers (e.g. @agners, @pvizeli) are working on.

Hello! The ticket is still open… it does not look like it is going to be closed. Should I maybe ask on the current status?

No reason to constantly ask for the status here. As already said in october: It’s done when it’s done. And if there is something relevant to report it will be and if the issue is solved, the ticket will be closed. Thus, no need to further discuss on the status.

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.

What can we do to trigger the issue so they will get manpower to the ticket?

Hello! Same here… I waiting for this in order to switch to Homeassistant. Until I can’t use the DRAP I can’t change over. Unfortunately this is nothing I could help to implement.

I am not sure, if the following is of help or does have any short comings, so I just would like to describe my approach and I would be happy, if it helps as well as about feedback. I have a HMIP-HAP working with Raspberrymatic in a Docker container on a RPi4 without using network_mode: host. Instead, I am using the macvlan driver with a exclusive network for the Raspberrymatic container.

This is my docker-compose file:

version: "3.8"
services:
  raspberrymatic:
    image: ghcr.io/jens-maus/raspberrymatic:latest
    container_name: dkhm
    hostname: dkhm
    privileged: true
    restart: unless-stopped
    stop_grace_period: 30s
    volumes:
      - /home/alarm/dkhm_data:/usr/local:rw
      - /lib/modules:/lib/modules:ro
      - /run/udev/control:/run/udev/control
      - /mnt/storage/HMBackup:/mnt:rw
    networks:
      default:
        ipv4_address: 192.168.1.221
networks:
  default:
    external:
      name: hmnet

Before this works, I created the following network. It is important, that subnet is the same as the hosts network and to take care, that ip-ranges of the host network and the to be created Docker network do not collide:

docker network create -d macvlan -o parent=eth0 \
  --subnet 192.168.1.0/24 \
  --gateway 192.168.1.1 \
  --ip-range 192.168.1.220/30 \
  --aux-address 'host=192.168.1.222' \
  hmnet

To allow communication between the host and the Raspberrymatic container, the following additional steps are necessary - as the Docker firewall configuration seems to block this, as far as I understand it:

ip link add hmnet-shim link eth0 type macvlan mode bridge #create a virtual network device hmnet-shim bound to eth0

ip addr add 192.168.1.222/32 dev hmnet-shim #set the above mentioned (aux-address) ip address of hmnet-shim
ip link set hmnet-shim up

ip route add 192.168.1.220/30 dev hmnet-shim protocol static #add the necessary static route between host and hmnet-shim

As the above four lines don’t survive a reboot, I created a systemd service for this:

[Unit]
Description=Create hmnet device and add static route
Requires=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c '/usr/bin/ip link add hmnet-shim link eth0 type macvlan mode bridge && /usr/bin/ip addr add 192.168.1.222/32 dev hmnet-shim && /usr/bin/ip link set hmnet-shim up && /usr/bin/ip route add 192.168.1.220/30 dev hmnet-shim protocol static'

[Install]
WantedBy=multi-user.target

With this approacv, the communication between Raspberrymatic and the HMIP-HAP works as it should. The turquoise led is solid and not blinking. The only thing I didn’t test is, if the setup process (in german “Anlernen”) between Raspberrymatic and HMIP-HAP works, as I did that with network_mode: host and I can’t redo the process currently. Maybe somebody else can give feedback, if the setup process works with macvlan, too.

I hope this helps.If you’ve got questions, please ask and I try to follow up timely.

You can asign the port on options but set it to null for the host, so people can just enable it if they enter the port manual.

This is already the case, indeed. However, this alone does not seem to help in the end as this issue here shows.

If it using multicast, then it should be solved with home-assistant/plugin-multicast#17

Sorry to bother you, but where exactly does pimd to be installed so that the multicast routing from the host to/from the add-on container works? I am really lacking some more detailed information/know-how here to get this working with HA. As said, right now the relevant udp multicast port (43438) is already defined null in the config.json file: https://github.com/jens-maus/RaspberryMatic/blob/master/home-assistant-addon/config.json#L78

But it seems this alone does not help in getting the multicast traffic from the HA host to the add-on container and vice versa. So any more detailed hint in getting the udp multicast traffic properly routed between the HA host and the add-on container would be highly appreciated.

You can asign the port on options but set it to null for the host, so people can just enable it if they enter the port manual. If it using multicast, then it should be solved with https://github.com/home-assistant/plugin-multicast/issues/17