-
-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HmIPW-DRAP/HmIP-HAP cannot identify RaspberryMatic as a HA addon #1373
Comments
Thanks for this nice elaboration, this is highly appreciated. After some investigation, this (as you outlined) can be quite easily solved with adding 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 |
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 |
Thanks @pvizeli for the hints. Where exactly do I have to set the multicast port? In the |
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 |
You can asign the port on |
This is already the case, indeed. However, this alone does not seem to help in the end as this issue here shows.
Sorry to bother you, but where exactly does 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. |
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. This is my docker-compose file:
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:
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:
As the above four lines don't survive a reboot, I created a systemd service for this:
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. |
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 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 |
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:
In RaspberryMatic all ports are open. 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? |
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 |
@jens-maus thanks for your efforts. Thank you! |
If you cannot work on it yourself you can just lean back and wait until someone else is going to implement the missing piece. |
Hello! |
FYI: After some more work and tests with HomeAssistant I was able to create a manual patch procedure to create the necessary 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 Nevertheless, if there are some HA/RaspberryMatic users out there waiting for |
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. |
I followed your patch instructions with macvlan and the HAP directly connected to the RaspberryMatic AddOn. Many thanks. Looking forward to have some persistent patch in the future. |
Hello, we are currently building our family house and we will use Homematic IP Wired here. I currently own a CCU2 and use Home Assistant on a Rasperry 3. I have now read that there is the Raspberrymagic OS on which I can install the Homematic addon. Then I heard that there are currently problems with the DRAP. Now there seems to be a first solution. Now my question is to assume that I can use it in 2 to 3 months without any problems? Since I want to set up everything from scratch for the new house, I could switch directly to Raspberrymagic. |
Is it fixed? I have upgraded RasperryMatic to 3.69.7.20230626 and HASS to 2023.6.3 and the HmIP-HAP is reachable without repeating the MAC VLAN Hotfix. |
No, the macvlan solution is still pending / not implemented in HA. Thus, as long as this ticket/issue is open the workaround patch is still required to be executed each time the addon or HA is going to be restarted... |
Yes, it just was reachable for some minutes. I had to use the hotfix again |
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!
No the hostname you have selected does not seem to be correct (see the |
This comment was marked as resolved.
This comment was marked as resolved.
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. |
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 |
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 |
Hello jens-maus, thank you for your great work at first! again, thank you for your great work! |
Hello, first of all thanks for all your efforts and for providing the 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. 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?
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. |
Hello dn-gt 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. |
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. |
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. |
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. |
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. |
I have been struggling with this decision for some time and have now moved to a standalone version instead of HA addon.
|
FYI: Please note that discussion regarding general support for |
Running RaspberryMatic in a standard Docker subnetwork on the host prevents a DRAP from connecting
...
Steps to reproduce the behavior
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:
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
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:
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.
The text was updated successfully, but these errors were encountered: