Is HomeMatic IP a good choice for OpenHAB?

Dear all,

I currently use innogy for all important devices, i.e. mainly thermostats that should not fail. But innogy is very much a closed system. Still, it works very reliable with OpenHAB.

As I plan some hardware investments, I should make a wise choice for the upcoming years. My impression is that HomeMatic IP is probably more popular, provides more devices and - this is the main point - both proprietary (CCU3, AP) and open source gateways (RaspberryMatic, viCCU) are available.

But I have the impression that the CCU/OCCU software follows rather old concepts. As a consequence, data exchange of system variables (“polling”) is limited to very slow cycles of around 30 seconds (see e.g. https://github.com/rdmtc/RedMatic/wiki/Faq#bis-Änderungen-von-systemvariablen-in-redmatic-ankommen-vergeht-sehr-viel-zeit-wie-kann-man-das-beschleunigen). This again looks like quite inconvenient: Say, you send a command to from OpenHAB to switch on a light controlled by HomeMatic, 30 seconds are too much. Updates of variables seem to be a general issue in HomeMatic, see also Homematic status refresh. Here, the binding looks like interfering with the Hue binding: Is the Homematic binding actively maintained?

Are there any experiecences in the community how well this works and if the limited poll capability creates issues in this context? Are there oither things I should consider, e.g. reliability? From innogy, I am very much used to a very simple usage scheme: Send and read values to the gateway, and immediately get a result. Probably, the innogy gateway is simply more efficient in polling…

Thanks for sharing your impressions!

Homematic (IP or not) is a proprietary, closed system designed to work on it’s own, with the CCU controlling your home. It has all the drawbacks of proprietary products (such as lack of alternatives per device, let alone vendor policy).
You will not want to get into proprietary systems unless you happen to already own it.

Look into standards based systems such as KNX, ZWave, ZigBee, WiFi, that work without a gateway or (application level) controller.

Hi Tobias,

i use Homematic window contacts HmIP-SWDO-I at all my windows and garage (around 15 in total) and it works pretty well. if i open a window i see in less than a second the change in home app on my iphone.
i also have 2 HMIP-PSM in my cellar that work as expected but i cannot tell anything about delay - they switch off fews things at the night.

my setup is this:

  • raspberrymatic
  • openhab with homekit and homamatic binding

Good point. I tried.

However, I was unable to find good thermostats that immediately respond to a change in set temperature.

Z-Wave devices have a wake-up internal of 15-30 min to save battery. The only exception is Eurotronic, which offers FLIRS, but a very buggy firmware during my tests. Their customer service is unresponsive. The only Zigbee thermostat that is popular is also from Eurotronic. Wired solutions looks KNX seem to loose market share and might disappear in few years…

Hi Tobias,

I use Homematic with OpenHab since more than 4 years now. In addition I have connected Alexa with the Hue emulation to Alexa and I command directly my Homematic switches and dimmer per voice. The respond is immediate. For now 5 months I’m using the radiator thermostat from Homematic, I can control the temperature directly from OpenHab and again I don’t see delay in the command. From my side I’m very satisfied how OpenHab and Homematic works together.

OpenHab is running on a Raspberry Pi. To monitor the system I use persistence in an InfluxDB and Grafana running on a separate Raspberry Pi. I can access remotely from the Internet.

I have 3 installations, 1 with the CCU from Homematic, 1 with the HM-MOD-RPI-PCB and 1 with the RPI-RF-MOD. All works perfectly fine, but the last one is the better in term of signal quality. I have even some IP modules mixed with non IP modules.

@jclugeon Thanks a lot!
Which Hue emulation do you use? Is this a function of the CCU?

Is there a reason not to use OpenHAB to send Alexa commands to the CCU?

Hello Tobias,

I use OpenHab a central hub for all my different devices, so I have integrated Tradfri, Alexa, Homematic, Squeezebox, and many other sensors other mqtt in one central place.

Therefore I have connected Alexa to OpenHab and I can command per voice any of the system connected to OpenHab.

The CCU is only use as bridge between OpenHab and the Homematic modules.

I have computer science background, so it is not a problem for me to program rules and define the items directly in the files.

With Alexa I almose don’t use anymore the Basic UI but I use HabPanel with Raspberry and Touch Display.

I use the Hue Binding to connect to Alexa.

Best Regards

Jean-Claude

Okay, that clarifies it… Thanks!

@Tobi77

Just wondering what your experience is with the Homematic TRV (in case you bought it in the end).

I am in the same boat. I want to control the radiators and be able to use an external temperature (this last one seems to be missing for all ZigBee valves and most Z-wave ones I found.
I have 4 Eurotronic Spirit Z-Wave values, which do have this feature, but they are not reliable enough, sometimes heating does not stop when the target temperature is already reached and sometimes they miss commands esp. when setting all four of them at the same time.

As far as I understand Homematic IP also can be controlled fully locally for example via openHAB and a CCU3 or alternative, so without an internet connection is this correct? This opposed to TADO which can not be controlled when there is no internet connection (and Tado needs to keep the service running) and therefore a no-go for me.

I don’t personally have Homematic IP, but I’m pretty certain the behaviour in this respect is the same as Homematic and the older Max - the control is all local, no internet connection needed so long as you have a CCU3, or a raspberry pi emulating a CCU (which is what I have).

The advantage of Homematic (and Homematic IP) is that the wakeup cycles are more efficiently handled, and you’re both therefore less likely to overload the maximum transmissions per unit time, and get things like temperature back from the devices more often.

1 Like