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

[ThomasSiegmund]

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]

Thanks for this nice elaboration, this is highly appreciated.

After some investigation, this (as you outlined) can be quite easily solved with adding network_mode: host in the docker/OCI use case. And I think to "solve" it for native docker/OCI users, we simply have to tune the documentation to some extend and could even adapt the deploy.sh script to allow to run docker using the necessary --net=host option so that the container will use the host network accordingly.

However, the same limitation exists in the HomeAssistant addon use case in principle, but seems to be quite harder to solve, I am afraid. While in principle, the HA addon could also be switched to the same network_mode: host mode using a home assistant addon config setting (see https://developers.home-assistant.io/docs/add-ons/configuration/#add-on-config), this could immediately negatively affect other addons running on the same HomeAssistant host. In addition, the internal RaspberryMatic iptables firewall could then quite easily mixup/break the whole host firewall setup if the RaspberryMatic HA addon will run on the host network of HomeAssistant. AFAIK, there is unfortunately indeed no solution to get a docker container to accept UDP broadcast messages that are received by the actual docker host. Perhaps @pvizeli or some other HA dev has some other idea how to forward UDP broadcast packages to the docker containers in HA without having to set host_network: true in the config.json addon config file. Otherwise, I am currently quite puzzled how to consistently solve this for the HA addon use case.

[pvizeli]

If you know the port, then you just need to set it. If it's multicast, then it could pick-up in future by the new multicast plugin

[jens-maus]

Thanks @pvizeli for the hints. Where exactly do I have to set the multicast port? In the config.json of the addon? Do you have some example you can show? And when will the new multicast plugin be part of HA or does a HA user have to install it himself to get udp multicast routing into a HA addon going?

[TVR-X]

Is it possible to test a modified config.json file with "network_mode: host" inside? I can't find a way to modify this on a Addon from a repository
because i think this is the same issue like in #1327.

[jens-maus]

Is it possible to test a modified config.json file with "network_mode: host" inside? I can't find a way to modify this on a Addon from a repository

Sorry, but it is not possible for a user to override the network_mode: host for a published add-on. I, as a add-on developer would have to do that in the config.json of the add-on itself. However, I actually tested this myself and just using network_mode: host will end up in other issues that you seeing because of the add-on generally running on the host network (e.g. the network firewall will be modified by the add-on). Thus, I am still waiting for @pvizeli to answer my question and help in getting this multicast issue somewhat solved in the near future.

[pvizeli]

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 home-assistant/plugin-multicast#17

[jens-maus]

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.

[dkadioglu]

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.

[jens-maus]

FYI: I just tested the issue myself again and tried to use eQ-3 NetFinder to identify a running RaspberryMatic CCU as a HomeAssistant add-on. As soon as I specify port 43438/udp in the add-on config to be forwarded to the add-on NetFinder is perfectly able to identify the RaspberryMatic also within a HomeAssistant environment. See:

The only thing that is missing/strange is, that this virtual CCU is listed with "refer to help" in the reachability column. This might be, however, due to the fact that this virtual CCU cannot be pinged/reached directly form the system running thie eQ-3 NetFinder tool.

Regarding reachability of the virtual CCU from a HmIPW-DRAP or HmIP-HAP, the situation can be easily similar and needs to be tested. Note, however, that for the DRAP to identify/find your CCU you would have to open port 43439/udp as well.

[THorst92]

Hi @jens-maus,

I don't know if you've received already a feedback to the reachability of the virtual CCU from a HmIPW-DRAP or HmIP-HAP. I've tried to connect a HmIP-HAP to RaspberryMatic which runs as AddOn in Home Assistant without success.

SW-Version:

• RaspberryMatic 3.61.7.20220226
• HMIP-RFUSB 4.4.16
• HMIP-HAP no new update available (checked with the HomeMatic IP App)

In RaspberryMatic all ports are open.
The ports 9293, 43438 and 43439 are activated in the configuration of the RaspberryMatic AddOn in Home Assistant.

When I reset the HMIP-HAP twice and try to activate the pairing mode, the LED stays static blue (or yellow if I block the internet connection). In RaspberryMatic I was not able to teach in the HMIP-HAP (local and with internet connection). Also in the option "Access point with incompatible firmware" the access point was not displayed.

Do you have an idea what I can try next?

[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 (home-assistant/plugin-multicast#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.

[firstusing]

@jens-maus thanks for your efforts.
I have rebuilt my complete smart home to get the Rasperrymatic installed as Addon within HA. I was reading slowly thru your guideline and had luck to see the issue before I did start. Nothing within my home would work without DRAP and the Second HAP.
What can we do to trigger the issue so they will get manpower to the ticket?

Thank you!

[jens-maus]

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

If you cannot work on it yourself you can just lean back and wait until someone else is going to implement the missing piece.

[vore]

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.

[dersch81]

Yes, it just was reachable for some minutes. I had to use the hotfix again

[Phil7989]

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.

Hi all, i have no idea about all this linux stuff. I have execute the support patch and get the error message „RaspberryMatic isn't running or hostname incorrect.„ Do you know this issue? IP ans Host are correct.

[jens-maus]

Hi all, i have no idea about all this linux stuff.

Don't you think that it would then be better to simply wait until a permanent solution is available? Because you will need to perform these step each time you restart RaspberryMatic or your Home Assistant host. And also note that this here is no support fora, but a bug/issue tracker!

I have execute the support patch and get the error message „RaspberryMatic isn't running or hostname incorrect.„ Do you know this issue? IP ans Host are correct.

No the hostname you have selected does not seem to be correct (see the e.g. XXXXXXX-raspberrymatic pattern), see the add-on page and use the correct hostname, then it should work.

[jens-maus]

Hallo Jens, wie geht es bzgl. der permanenten Implementierung des Patches in das Add-On weiter? Hab keine Lust mehr nach jedem Neustart den Patch auszuführen :-) Beste Grüße und vielen Dank für die tolle Arbeit!

Zu allererst: Wenn hier primär englisch gesprochen wird bleiben wir auch bei Englisch, bitte.

Und was den Patch angeht, nun dann wende dich an die HA Entwickler. Von RaspberryMatic Seite aus gibt es hier nichts weiter zu tun bzw. kann ich nichts weiter tun. Die HA Entwickler sind gefragt die notwendige Infrastruktur in deren Addon Schnittstellen zur Verfügung zu stellen damit ein Addon eine eigene separate IP-Adresse erhalten kann und das addon eben mit mac-vlan funktionalität gestartet werden kann.

Und zu guter letzt: Das ist kein Diskussionsforum hier sondern ein Bug-Issue Tracker. Wenn du nur nachfragen willst wann es hier weitergeht bzw. wie der stand ist, dann nutze den Diskussionsteil bzw. ein Diskussionsforum.

[ThomPre99]

Hi Jens,

first of all: great work you're doing!

Is it possible to start the "patch script" in the POST section of the add-on (if configured) and to control the script using configuration parameters? This means that the Raspberrymatic add-on including HmIP-HAP support would be independent of HA development (although an HA solution would of course be better). It is logical that the start time of the addon is extended if the script is activated.

Unfortunately, my docker knowledge is not so good that I could create a solution myself.

Thanks in advance and best regards
Thomas

[jens-maus]

Is it possible to start the "patch script" in the POST section of the add-on (if configured) and to control the script using configuration parameters? This means that the Raspberrymatic add-on including HmIP-HAP support would be independent of HA development (although an HA solution would of course be better).

No, this is unfortunately not possible, simply because HomeAssistant does not allow to specify such PRE or POST scripts to be defined by the addon which are then executed upon start/stop in the context of the HomeAssistant host OS. Thus, a HA addon can only modify or affect things within its own limited context (within the docker container) and not outside of that. And that's simply because of security reasons.

So, I am sorry, but the only way to get the necessary macvlan based networking running for being able to communicate with a HmIPW-DRAP or HmIP-HAP from a running RaspberryMatic addon is by either manually running my mentioned patch in the context of the HomeAssistant host each time your RaspberryMatic HA addon is (re-)started or simply wait for the HA developers (@pvizeli, @agners) to actually implement the necessary changes into the HA addon infrastructure so that HA addons can employ such macvlan docker network setups themselves.

[caldriks]

Hello jens-maus,

thank you for your great work at first!
Im currently getting in touch with ur Software and running into several Problems, especially with the HmIP-HAP Integration.
Do you recommend to setup a standalone raspberrymatic instead of the addon installation in this case?

again, thank you for your great work!

[dn-gt]

Hello,

first of all thanks for all your efforts and for providing the patch!

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

Since my Home Assistant and Homematic Installation does not have Internet yet I downloaded the Shell Script and put it to the Config Directory of my Home Assistant Installation.
From there I'm running the script using config cat patch.sh | bash

Unfortunately, the script does not find the network parameters itself so I provide them manually and but I can't reach Raspberrymatic under the new static IP Address 192.168.0.3 (also no ping possible). Any idea what's going wrong here?

cat patch.sh | bash
ip: can't find device ''
HomeAssistant Main Gateway (e.g. 192.168.178.1): 192.168.0.2
RaspberryMatic Add-on Hostname (e.g. 5422eb72-raspberrymatic): de838cd8-raspberrymatic
RaspberryMatic Add-on IP (e.g. 192.168.178.4): 192.168.0.3
Creating docker macvlan network
every ip-range or gateway must have a corresponding subnet
Connecting add-on to macvlan network
Error response from daemon: network ccu not found
Stopping add-on (addon_de838cd8_raspberrymatic)
addon_de838cd8_raspberrymatic
Starting add-on (addon_de838cd8_raspberrymatic)
addon_de838cd8_raspberrymatic

My HomeAssistant installation is available under 192.168.0.2 - I assume this is the IP I need to provide as "HomeAssistant Main Gateway", correct? Or do I need to supply the Router Gateway which would be 192.168.0.1? I tried this as well but without any effect. Should I worry about the highlighted error message?

Any hints are appreciated. HomeAssistant is running on ODroid Hardware with the latest October Release.

[ivo7B4]

Hello dn-gt
I have user knowledge for homeassistant and the integration only, but to support that jens-maus and other developers here can focus on their great work (also thanks a lot!) and as I think I can answer this question, my comment:
Do I see correctly that you have homeassistant and raspberrymatic running on separate devices? If yes, you don't need this add-on; as you have raspberrymatic already running on another device.
What you need is the custom homematic integration (which you actually is needed in both cases to integrate CCU3 or raspberrymatic; independent wheter you are running it separately or on the same device). And the custom_homematic integration is a great integration! With having it running on two devices (and you thus don't need this add-on), you also don't need to worry about this patch as the DRAP/HAP are reacheable from the CCU3 or raspberrymatic.

And a P.S.: I also propose to use the support forums as also jens-maus has mentioned above for such topics (Diskussionsforen).

[dn-gt]

... Do I see correctly that you have homeassistant and raspberrymatic running on separate devices? If yes, you don't need this add-on; as you have raspberrymatic already running on another device. What you need is the custom homematic integration (which you actually is needed in both cases to integrate CCU3 or raspberrymatic; independent wheter you are running it separately or on the same device). And the custom_homematic integration is a great integration! With having it running on two devices (and you thus don't need this add-on), you also don't need to worry about this patch as the DRAP/HAP are reacheable from the CCU3 or raspberrymatic.

And a P.S.: I also propose to use the support forums as also jens-maus has mentioned above for such topics (Diskussionsforen).

Thanks for your feedback, I'm using the addon version of Raspberrymatic however and not the integration. I thought it's better and saves additional hardware (the Odroid N2+ is powerful enough). I'll try to find more adequate thread in General Discussion secition. Thanks for the hint.

[ivo7B4]

I assumed that you have it on a separate device as you've mentioned two different IP addresses. I use it on two different devices; thus I don't use the add-on, only the integration. But I still would expect the same IP address.
Add-ons in home assistant you reach typically trough "settings, add-ons", then selecting the corresponding add-on and clicking on "open web-ui" afterwards. Alternatively, you can also actived "show in sidebar". I hope this helps.

[Thorsten1982]

Hello, I was able to successfully apply the patch and learn the DRAP, DRBL and DSR. Am I correct that I now always have to call Raspberymatic using the static IP. Or can you still access the Raspberrymatic web interface via the home assistant. Does calling the static IP address also work from outside? Also, for example, via VPN or Myfritz, with the background that I use German fiber optics and therefore I don't have an IPv4 address but have to use it via IPv6.

Homeassistant was assigned an Ipv6 address by the Fritzbox but the static IP address of Rapsberymatic is only an Ipv4 address. The point is that the equipment could then be set up at work and not have to be on site. Because it is a new building.

[Thorsten1982]

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!

Hello, you say it works for you without any problems. Do you also have a wired 6-fold button in operation? For me, 3 different buttons are not trained, the Falmot c12 could be trained.

[jens-maus]

Hello, you say it works for you without any problems. Do you also have a wired 6-fold button in operation? For me, 3 different buttons are not trained, the Falmot c12 could be trained.

Sorry @Thorsten1982, but please stay on topic. This is not a discussion fora here, but a bug/issue ticket system and it is about HmIPW-DRAP/HmIP-HAP integration if RaspberryMatic is used as a HA addon. Thus, if you were able to apply the mentioned patch mechanism and you were able to teach-in a HmIPW-DRAP/HmIP-HAP, there is nothing more that needs to be talked here. So if you have other questions, please walk to the discussion part in GitHub here and start a new discussion or use extenal discussion fora instead. We really need to keep this issue ticket clean from such support requests, I am afraid.

[Thorsten1982]

Yes, sorry, that's of course true. I just wanted to give feedback that the patch works for me but I can't get a wall button or RT trained and thought maybe this could be related to the patch.

[jens-maus]

Yes, sorry, that's of course true. I just wanted to give feedback that the patch works for me but I can't get a wall button or RT trained and thought maybe this could be related to the patch.

No it is not. This is a completely different layer issue which needs to be discussed elsewhere.

[ZTHawk]

I have been struggling with this decision for some time and have now moved to a standalone version instead of HA addon.
I have now 2 VirtualBox instances. One with HA and the other with RaspberryMatic.

• Advantages (at least for me):
  • UI is faster/smoother
  • Support for Accesspoint as gateway (which is important to have everything locally and mitigate HmIP server unavailibility)
• Disadvantages:
  • Requires more resources (RAM + disk space)
  • A bit more difficult to setup (VirtualBox - no disk space #2473) (I have only assigned 1GB RAM and 8GB disk space (only 800MB are used though))
  • Same sidebar behaviour only possible with proxy (alternatively Make X-Frame-Options configureable #2033 [see my comment at the end])
  • No update notification

[jens-maus]

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

home-assistant/architecture#1034

[ciB89]

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.

I've successfully used the script and can reach raspberrymatic via the new IP. But now my connection to Home Assistant via Homematic(IP) Local is not working anymore - I obviously updated the IP in the integration, but I guess I also need to setup the callback host and port? Any help here would be appreciated.

[mcmuller]

Thanks for the patch! In my enviroment (RPi4&Rasperrymatic-Addon&2xHmIP-Hap, all latest versions), I even see persistence over a HA-reboot unlike the limitation in "4.". Let's see what happens after updating HA or Rasperrymatic.

[PantheraIgnis]

For my understanding, the issue is that we cannot receive multicast upd packages within the docker container running inside HAOS? It shouldnt be too hard to create a workaround as integration, basically an integration with very little interaction to HomeAssistant itself just reading a config for its settings and listening for multicast packages and relaying them into the container via unicast. The required few lines of code can be derived from the KNX integration i think.

[jens-maus]

For my understanding, the issue is that we cannot receive multicast upd packages within the docker container running inside HAOS? It shouldnt be too hard to create a workaround as integration, basically an integration with very little interaction to HomeAssistant itself just reading a config for its settings and listening for multicast packages and relaying them into the container via unicast. The required few lines of code can be derived from the KNX integration i think.

Well, then please go ahead and try to solve it. IMHO the only sensible and straight forward way of solving the "multicast udp" issue with HA addons requiring multicast udp communication is to support to setup the docker containers with macvlan support as suggested here home-assistant/architecture#1034 Anything else would be a potential workaround only. Nicer would be to have that macvlan functionality directly integrated in HA addon support itself.

[PantheraIgnis]

Macvlan would mean that we always have to define a secondary ip address for containers requiring multicast?

[jens-maus]

Macvlan would mean that we always have to define a secondary ip address for containers requiring multicast?

Exactly. You would have to specify/reserve an additional static IP address of your LAN network which will be assigned exclusively to the add-on container (e.g. RaspberryMatic HA Add-on) under which the container will then be accessible and thus would allow to receive/send multicast udp packages.

[PantheraIgnis]

Alright i did some research:

1. I can access all network interfaces from the main homeassistant container, inlcuding the actual network and hassio.
2. I acquired the method the KNX integration uses to open a udp multicast socket and am able to replicate that. (xknx/io/transport/udp_transport.py)

Does RaspberryMatic send messages to subscribe to the required multicast traffic and/or is there a documentation for it?
If it does i can in theory autodetect the required multicast addresses and play proxy.

[jens-maus]

Alright i did some research:

1. I can access all network interfaces from the main homeassistant container, inlcuding the actual network and hassio.
2. I acquired the method the KNX integration uses to open a udp multicast socket and am able to replicate that. (xknx/io/transport/udp_transport.py)

Does RaspberryMatic send messages to subscribe to the required multicast traffic and/or is there a documentation for it? If it does i can in theory autodetect the required multicast addresses and play proxy.

Well, as said: Feel free to develop a working example. I myself and some others have already invested quite some time in getting this whole multicast traffic communication between the CCU and the DRAP/HAP working in a docker like environment like HA addons are using, but have failed so far. I would suggest you walk through the whole discussion line above and check links to other tickets, etc. in trying to identify potential solutions apart from the current idea to simply implement macvlan support for addons in HomeAssistant. Note especially, that there is already a plugin-multicast available in HomeAssistant which back then we tried to modify to get this going. However, this also didn't work out, I am afraid. So, for example, have a look at:

home-assistant/plugin-multicast#17
home-assistant/plugin-multicast#61
home-assistant/plugin-multicast#61 (comment)

Especially the last link should get you to a rather comprehensive explanation about the multicast traffic between the CCU and DRAP/HAP to identify each-other. So if you can come up with some other solution, I am of course interested to hear how to potentially implement this without the need for macvlan support. Nevertheless, please keep in mind that I am rather seeking for a straight and user-friendly way in getting this going. So having to install a somewhat workaround-integration just to forward/proxy this specific multicast-traffic to the RaspberryMatic HA add-on container reads like one step too much at the moment.