Closed nRaecheR closed 2 years ago
I have a similar configuration but without any problems. Are you only using HmIP components or do you have some "classic" devices, too? Can you check the firewall settings on you openHAB Raspi and make sure that the ports 9125 and 9126 are open.
The Firewall is set to All ports open and it works for days when I just poll the bridge item Duty Cycle. So the communication itself shouldn't be the problem. I've around 25 devices connected, all are HmIP wireless.
As far as I know, the request to retrieve the duty cycle works differently because it is a system variable. That means the binding has to send requests to the CCU to get the value.
Communication with "real" devices works differently. Then if a data point's value changes the CCU sends an event to the binding. Can you enable the TRACE log output and add at least one device? Then please restart openHAB and wait for the communication error. Hopefully, the trace output gives us the necessary information.
Okay, I presumed you mean the communication from OpenHAB2 to RaspberryMatic. This should be the same (IP, Ports, Protocols) for DutyCyle and other items. Isn't it?
I'll enable the trace as soon as there is another maintenance window later in the week. Thank you.
Here is the log to a case where the HmIP device won't leave the uninitialized state:
https://athena.bockholdt.com/s/c9HEeqYNtJfd5zj
The device is the device with ID 0001D3C99C310F
Hmm, I can't see any error message in the log and no messages about status changes. The binding received a last event for the mentioned device at 10:45:29. After that time there are only ping/pong messages that are used by the binding to test for the availability of the CCU and events from other devices. I can be some sort of timing issue. The mentioned device has 1.200 data points. I need to look closer into the code to understand what's happening here.
Yes, you're right. The symptoms for this specific device are the same as described in my first post but the bridge itself and the other configured device is still functioning. The error messages haven't appeared too.
Thank you, Martin.
It seems that the HM-Binding has a problem with a disappearing Homematic Bridge (e.g. a Restart of it). The Bridge thing will be marked as offline and stays offline until restarting OpenHAB2.
Normally, a restart of the CCU should not be a problem. The binding sends periodic "ping" requests to the CCU and the CCU answers with "pong". (you can see them in the openhab.log). After the CCU was restarted it answers again with "pong" responses and then the Bridge should become online. This works perfectly in my environment.
I have the exact same issues. I have a setup with around 50 HM classic devices and 3 HmIP devices. Only the three HmIP devices are causing the exception.
RaspberryMatic v. 3.61.7.20220115 on Raspberry Pi 3 OpenHAB v. 2.5.2 as Docker-Container on Synology NAS
There haven been several improvements in OH 3.2. Therefore, I highly recommend upgrading your OH installation.
Yes, OH 3.1 fixed the HM-Bridge Online status, during a reboot of RaspberryMatic OH detects the change of status with a OFFLINE and then a ONLINE message. But the things/items are staying offline after that, or at least, they won't receive any updates to their states. So I still need to restart OH after a reboot/update of RaspberryMatic.
Had several problem when I first tried switching from OH 2.5 to OH 3.1:
executeCommandLine
seems to have changed)
Didn't hat enough time to find fixes for thisBut It looks like I have to try it again with OH 3.2...
But the things/items are staying offline after that, or at least, they won't receive any updates to their states.
This has been improved in 3.2. Maybe not completely because some HmIP devices behave a bit strange ...
I haven't seen any real improvement after updating from OH 3.1 to 3.2, the reboot problem still remains. Here're my HmIP devices that I've connected to my RM instance:
14x HmIP-BROLL
1x HmIP-FROLL
4x HmIP-BBL
3x HmIP SWDO-I
3x HmIP-BDT
1x HMIP-PSM
1x HMIP-PS
2x HmIP-SWD
1x HmIP-DSD-PCB
1x HmIP-SWO-PR
That's strange. Normally there are only one or two devices with problems. Please create a TRACE log and attach it here.
Here it is, the TRACE of a reboot of RM seen from my OH 3.2 instance:
https://athena.bockholdt.com/s/yGEPKy7NZaN4HZL
Thank you in advance!
The trace looks a bit strange. There is a mixture of requests that are executed without any problems and then timeouts for other requests. Looks like timing issues. These problems are nearly impossible to debug because every execution looks different, and it's not really funny if you have to restart the CCU (or RM) permanently ...
Meanwhile, I have the feeling that the issue can only be solved by rewriting the connection handling. With every attempt to solve the problem, the coding gets more complicated.
BTW: on what kind of machine is your OH installation running?
Ah, okay, I understand. The binding seems to be generally unreliable. I've got three HmIP-BDT, one of them is working fine with OH 3.2, the others won't work at all. I can add them as things but they won't follow any command I've send through OH. Same with the HmIP-BBLs ("Raff Stores"), I had to reset the actors to factory default after trying to add them to OH. Last time I tried that was with OH 3.0 though.
My OH installation is currently running version 3.2 Release, Openhabian, on a Raspberry Pi 3 Model B Rev 1.2. But I would like to migrate it to one of my amd64 servers as Docker container in the near future.
Your configuration is similar to mine. OH is also running on an Raspi 3 but I only have got 4 HmIP devices. All other devices are non IP devices. The problems regarding the re-connect only occur with HmIP devices. In my opinion, the cause of the problems is not only the binding but also the service for the HmIP devices.
Regarding your issues with the BDT and BBL devices. As far as I remember there have been some fixes for these devices and I don't know about any current problems.
I can live with the reboot, it's inconvenient but it works after a reboot. And I will give it another try with the BDT and BBL devices with OH 3.2. Thank you !
closed due to inactivity
I'm trying to bind my fully working Homematic installation to my OpenHab 2.50-1 running on a RPI3. OpenHab2 is running without issues a lot of other bindings (Hue, Weather, ZWave etc.) but I have major problems with the Homematic binding. I've added the bridge and created an item "Duty Cycle", it updates frequently and normally. When I add another HmIP thing, e.g. a HmIP-SWDO I experience problems. After some hours the bridge will marked as offline and the switch item is offline too. Even the web interface of the Homematic bridge will be slow as a snail and every action takes seconds.
The Homematic Bridge is RaspberryMatic running 3.49.17.20200131 (latest version). 192.168.46.9 ist the OpenHAB2 installation, 192.168.46.8 RaspberryMatic
Authentication on RaspberryMatic is disabled, the firewall too, all ports are open.
Here are the log entries from OpenHab2:
The RaspberryMatic add these entries to the hmserver.log:
I had to remove the item to get the RaspberryMatic working as expected. The bridge only gets online after restarting the OpenHAB2 RPi.
Any ideas how to fix this issue and make the Homematic binding working?