Max! Thermostats regularly loose connection to the cube

  • Platform information:
    • Hardware: Raspberry Pi 4 Model B Rev 1.1
    • OS: Linux 4.19.75-v7l+
    • Java Runtime Environment: openjdk version “1.8.0_222”, Zulu8.40.0.178-CA-linux_aarch32hf (build 1.8.0_222-b178)
    • openHAB version: openHAB 2.4.0-1 (Release Build)

Hey, I am a beginner with home automation and openHAB. I started using it just a few weeks ago and I read a lot through the google search and different forums. I built my openHAB with files instead of PaperUI and set it up the second time now after I encountered several issues with my first setup.

My issue:
My Max! thermostats loose regularly the connection to the Max!-Cube. I used them with the Max! environment for over a year without issues. Since I integrated them into openHAB that issue occured several times. When I restart the Cube they reconnect, so I assume it is not caused by low batteries (also the channel “low battery” should signal that).

Did anyone here experience a similar issue with the Max! system?
Maybe there is more traffic to be handled when using openHAB as it is with only the Max!-made environment? I recognized in the logfile that there are a lot of requests send to the Max!-Cube every 30sec to verify the temperature, I think.

2019-11-10 10:26:44.134 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Sending request #100 to MAX! Cube

2019-11-10 10:26:44.191 [DEBUG] [b.binding.max.internal.device.Device] - Device 0d3386 (Thermostat): Actual Temperature : 23.7

2019-11-10 10:26:44.195 [DEBUG] [b.binding.max.internal.device.Device] - Device 137b66 (Thermostat): Actual Temperature : 0.0

2019-11-10 10:26:44.197 [DEBUG] [b.binding.max.internal.device.Device] - Device 0d323a (Thermostat): Actual Temperature : 0.0

2019-11-10 10:26:44.201 [DEBUG] [b.binding.max.internal.device.Device] - Device 0d345e (Thermostat): Actual Temperature : 22.8

2019-11-10 10:26:44.207 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat Thermostat 1 (MKF0052910) id: max:thermostat:KEQ0537546:MKF0052910

2019-11-10 10:26:44.211 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat Thermostat 1 (KEW0004828) id: max:thermostat:KEQ0537546:KEW0004828

2019-11-10 10:26:44.216 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat Thermostat 1 (KEW0004525) id: max:thermostat:KEQ0537546:KEW0004525

2019-11-10 10:26:44.220 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat Thermostat 1 (KEW0004280) id: max:thermostat:KEQ0537546:KEW0004280

And sometimes there is request like this:

2019-11-10 10:28:23.339 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - Run MAX! Cube discovery

2019-11-10 10:28:24.180 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - MAX! Cube found on network

2019-11-10 10:28:24.182 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - Found at  : 192.168.178.20

2019-11-10 10:28:24.184 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - Serial    : KEQ0537546

2019-11-10 10:28:24.187 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - RF Address: 0b9715

2019-11-10 10:28:24.189 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - Firmware  : 01.13

2019-11-10 10:28:29.199 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - Done receiving discovery messages.

At the moment I don’t run any rules on the system to verify that my time based heating control doesn’t affect this and is not the reason for this behaviour. So I just sent a single command with a desired temperature to the thermostats and let it run to test.

edit:
I think it is important to know that not all thermostats loose connection at the same time. It can be just one. The next time it were two that lost connection. During these issue I am still able to interact with the others. So the Max!-Cube itself and the other devices work properly.

I found this topic in another forum eQ-3 MAX! connection error, but I have no other software connected to the Cube because as soon as openHAB is online and connected to it, all other Max!-software is dismissed and cannot connect anymore.

Thanks for your answers.