RaspberryMatic vs HomeMatic OCCU vs Homegear

Configuration
1

Hello everyone!

I want to control HomeMatic (RF/IP/IPW) devices through Home Assistant.
The problem is, there seem to be a lot of approaches to realize this and I have some uncertainties with them.
These are the approaches I’m aware of so far:

  • HomeAssistant’s HomeMatic integration with a RaspberryMatic CCU with RPI-RF-MOD (other radio modules are supported too)
    • The RPI-RF-MOD is more advanced than the other HM radio modules
    • RaspberryMatic fully supports everything a CCU3 supports, so there won’t be a compatibility bottleneck there
    • IoT class listed as Local Push, but I don’t know what class the communication of the CCU and the HomeMatic devices would belong to
    • pyhomematic used by the integration supports many HM devices, but some have hiccups and f.e. the new HM-IP Wired series is not yet supported at all
  • HomeAssistant’s HomeMatic OCCU Add-on with HM-MOD-RPI-PCB or HmIP-RFUSB
    • Both radio modules are less advanced (less range and performance) compared to the RPI-RF-MOD
    • The HmIP-RFUSB would only support HomeMatic IP, not RF
    • Both need more soldering compared to the RPI-RF-MOD, but that’s no real problem
    • I wasn’t really able to make out whether this implementation of OCCU is as capable as RaspberryMatic in terms of device compatibility and settings.
      In the configuration f.e. the type is listed as CCU2, and the CCU2 doesn’t support HM-IP Wired either, but only because of its performance, so I’m not sure if this applies here.
  • Homegear with HM-MOD-RPI-PCB or HmIP-RFUSB
    • The same disadvantages listed above that are caused by the radio modules
    • Doesn’t list support for HomeMatic RF or HomeMatic IP Wired even though the HM-MOD-RPI-PCB is capable of it
    • Claims full support for HomeMatic IP and HomeMatic Wired, but again I’m not sure if it can do all RaspberryMatic could do
    • I don’t know how well the devices are handed to Home Assistant

Can someone with experiences with these systems name some advantages or disadvantages or correct what I’ve listed?
I couldn’t make progress with the documentation of the OCCU Add-on and Homegear on the topic and I think only having used these could shed light on some things, or maybe someone can point me to a different resource I’ve missed so far.

The main problem I have with using RaspberryMatic in conjunction with Home Assistant is the limited compatibility because of pyhomematic, but it seems to be advancing quite fast in that matter, but a lot HM-IP components seem to stall because of their different channel architecture and HM-IP Wired has had some people saying they’ll start integration in the past, but nothing has been pushed as far as I know.

The OCCU Add-on approach has the problem of not supporting the superior radio module (Does anyone know whether support for this is planned?) and that I can’t find if it lacks some features/device-compatibility of RaspberryMatic and if so which. Also I’m wondering whether its IoT class would be local push or local polling or whether it depends on the HomeMatic series.

Homegear doesn’t support the superior radio module too and I couldn’t find whether support for it is planned as well. It doesn’t seem to support HomeMatic RF (and maybe also HM-IP Wired because it’s not explicitly stated as well) at all.
Also I’m not sure how well it can be integrated into Home Assistant and how, as I’ve found only the statement that it can be integrated into home assistant on the homegear website up until now. Other than that, I found a deprecated Add-on and no integration or the like. Maybe through MQTT, but I have no experience with that yet. Would it belong to local push or local polling?

I will update and correct this post as new information arrives. I currently have RaspberryMatic with the RPI-RF-MOD and the HomeMatic integration running. I could go into a bit more detail what features of specific devices aren’t supported because of the interface to Home Assistant, but I think to keep it more general for now is better.

Kudos if you’ve made it to here! Because I couldn’t find anything comparing the approaches, I hope that we can create a resource together which can help other people in the future who want to use HomeMatic with Home Assistant.

I have another similar post comparing approaches for integrating ZigBee devices, so if you’re versed with it I’d be glad if you could help me out with some infos there too!

2

I have a mixture of HM and HM-IP devices, but mosly HM-IP. I have tried Homegear, but found that it was very difficult to get it to a good working config. I then ordered a CCU2 which was much better but really, really slow.
Switched to RaspberryMatic and RPI-RF-MOD (connected via USB) on a Tinkerboard S and haven’t looked back since. The only problem is that if HA looses connection with the CCU, it will not retry it. You have to restart HA to get it to reconnect. It’s a known bug, but it doesn’t look like it will be fixed anytme soon.
So now, I run all my HomeMatic automations from the HomeMatic side, as I can’t risk loosing heating because HA won’t talk to it! Mainly I use NodeRed, and that connects easily and reliably to HA to pull entities and states from there.
Next step is to transfer RaspberryMatic to Proxmox on my NUC so everything is on one box instead of two.I’m not aware of any issues with device compatabilty on RaspberryMatic, but I’m just about to start ordering some wired devices for the next stage of my home renovation, so we’ll see how that goes!
Only other change I made was to add an external antenna to the RPI-RF-MOD, and now it easily reaches over three floors with concrete walls and ceilings.

3

Very interesting! Also, I currently have exactly the same setup as you (Tinkerboard S, RPI-RF-MOD, extra antenna) :smile:

I only recently began my journey with HomeMatic, so I haven’t set it up personally already, but a workaround for the reconnection issue I’ve read about on the integration’s page is to either use a HM device that should always be available and updates its status (like a light or temperature sensor) and frequently check whether it has updated its status or use the the “last reboot time” to detect whether connection might have been lost. Did you try such a workaround for your setup?
My plan is to use my three motion sensors that also deliver lightness measures and check against all three (so that if should permanently loose connection because of its battery or something it won’t keep reconnection) and use the last reboot time as a fallback to notify me if something unusual is happening.

Moving all to one system sounds smart, I think I will strive for that in the future too!

Regarding the compatibility of RaspberryMatic I misphrased a bit:
From what I know, RaspberryMatic has no incompatibilities whatsoever too, the problematic part is the interface to Home Assistant, which is pyhomematic. If you haven’t checked it out already, at the bottom of this file on GitHub you can find all devices which are known to be compatible.
To get an overview for myself I made a small table with some components and whether they’re listed or not:

grafik
grafik756×503 36.4 KB

From what I’ve read on GitHub support for HomeMatic IP Wired is stalled and HM-IP devices are also only partly supported. HM-RF should mostly be fully functional. Or would a workaround for that be possible with NodeRed?

4

All the different setups use pyhomematic. The HomeMatic IP Cloud integration is the exception to this. It uses the HmIP Access Point. But that’s irrelevant to you. So in terms of device support, all the solutions you took into consideration have the same limits regarding the supported devices). So essentially using the HomeMatic integration equals using pyhomematic. With Home Assistant there is no other option.

That being said, support for new devices does get implemented from time to time. It just requires contributors to do so. I (the maintainer of pyhomematic) have more and more less time to spend on this, so I depend on the help of others to get things done. Some users post their datapoint-output, which I can then use to guess how the device should be implemented. But that’s always a lot of work with a lot of back and forth because I can’t test it myself. And by integrating just the “easy” parts of a device there will always be users that feel some important parameter is missing.
Anyways, I would greatly appreciate if people at least attempted to try and implement their devices themselves. There have been people in the past that did just that, and after some minor corrections / hints from my side everything worked out perfectly fine. And it’s really not that hard. Copy and paste from a device that’s similar, adjust the channels, maybe add or remove some parameters, and everything should be ready to go.

Now that this is said, implementing the HmIP-wired devices isn’t a big problem at all. As far as I know they show up on the HmIP port along with the wireless devices. We just need the classes that add the support for them. And since these devices often are switches or some form of simple IO, it really shouldn’t be that hard to just reuse the classes of other devices and adjust them a bit. There will be some limitations compared to the old wired devices (because the HMIPServer on the (O)CCU is rather buggy), but at least basic support should be within reach with only a bit of time spent on this. So as you already seem to have RaspberryMatic set up, I want to encourage you to at least give it a try. :+1:

By the way, just in case you didn’t know already, sensors.py, misc.py etc. also have those lists at the bottom. So for a complete list you’ll have the add those as well. :wink:

Edit:
For completeness: local push in this context means, that the CCU / Homegear / RaspberryMatic (they all essentially perform the same job) push events to Home Assistant to update the state of entities locally (without going through the cloud).

5

Hi @JamesMatthew, great minds think alike :wink:! I have tried all the work-arounds, but none of them work for me. Calling the homematic.reconnect service directly, also does not work. So I think that if I run RaspberryMatic OVA under Proxmox, I can set it to start before HA to avoid this issue. Also, I rarely need to reboot RaspberryMatic as it’s very stable.

Hi @danielperna84, thank you for the clarification and for all your work on this integration, but I find it confusing with the different versions - OCCU, debmatic, piVCCU, RaspberryMatic, etc. Initially I ordered the HmIP Access Point by mistake, but was cloud-based so I exchanged it for a CCU2.
I hope to order a Homematic IP Wired Access Point HmIPW-DRAP and some other wired device soon, so I will bear your comments about implementing device in mind :+1:.

6

That’s true. Essentially these all are just different solutions for the same problem. They provide a hub to which you attach your HomeMatic devices, and provide an API that allows 3rd parties to communicate with the devices. This API is standardized, and all pyhomematic really does is to access that API in Python. Hence any software that exposes the XML-RPC API as specified by eq3 can be talked to through pyhomematic.

7

Wow, that’s something I severely misunderstood before! Especially with Homegear I thought they had a somehow different approach, as I not once read that pyhomematic does the translation there too.
I read a lot on its GitHub page, like that it’s primarily intended for use with Home Assistant which is why it’s only compatible with python3 at the moment.
So that HomeMatic OCCU uses it too comes kind of naturally now that you said it, but because homegear also advertises its speed which comes with C++, I thought they were following a different approach.

I’ve seen that first-hand, I tried going through many of the closed and open issues through GitHub to get an idea how one can help the project. It’s just fantastic how much time you have invested and are investing there and here to answer questions.
I’d really like to help with what you and the many other contriubtors built. I found some topics that addressed how one can go to improve device compatibility, like the script you supplied and testing code in the /config/deps/, but for me this folder is empty (did the pyhomematic code of Home Assistant move somwhere else?).
Is there any resource or post which I can follow to get a general understanding of the workflow in the project?

That’s good to hear! I read through most of the device support issue on GitHub and understood that the new channel architecture at least makes it difficult to support many devices at once, which seems reasonable. What dubitated it a bit for me were the people making progress on implementing some of the devices and then going silent :sweat_smile:
Currently, I only have some motion detectors and plugs, but am planning to add HomeMatic to my distribution box as soon as my budget allows it. I’m still unsure whether to use the HM-IP Wired series or the DIN-rail RF components. If any of the components I decide on are unsupported, I’ll do my best to add them.
One problem I have with the ip dimmable plug is that the transition attribute is set on the wrong channel; this issue is already reported on GitHub and I’ll try to help solving it!

Ups, I read that about the actors.py in some issue and only scrolled to the bottom of the generic and helper.py
I updated my table with the other three files and by chance all the components I tested against weren’t in the other files as well :smile:

I think I was a bit unclear in what I’m unsure about there - I read the descriptions of the classes in the docs, so the CCU communicating with Home Assistant on a push basis is great! I wasn’t sure whether the communication of the CCU with the devices is also on push basis or whether it maybe depends on the series. The RF motion sensor reports a state change almost immediately, so that seems like push, but the HM-IP plugs I have have a delay of about five seconds of reporting a new state when changed on the device and not via Home Assistant, which seems a bit more like polling to me as I don’t know why the plug would linger over the push message for some time before sending it.
If I were to guess before, I would have thought that maybe the RF devices work via polling and the newer IP devices via push, but my observations threw me off a bit.

Thank you again for taking your time with answering my questions. I would love to tip you, but read in many posts that you’d rather have more people working on the project, so I’ll gladly try to support there. Nonetheless, if you ever should change your mind on the topic, I’ll definitely treat you at least some coffee!

8

Oh, you! :kissing_heart:

There’s a question that came to my mind after reading your post again: I saw some intel NUCs before and looked at some pictures again now, but I don’t see GPIO connectors on them - or is there a version that has them?
Otherwise, is there an option to use the RPI-RF-MOD nonetheless I’m unaware of?
I currently have HA virtualized on my server, but refrained from RaspberryMatic because I wanted to use the RPI-RF-MOD.

That sadly seems to be the same for me too. Just tested the behaviour in HA after a reboot of the CCU and after calling homematic.reconnect subsequently:
After the reboot, none of my devices were sending updates to HA; they were still controllable, but that was to be expected. This also let to the effect that switching a light on or off does switch the light, but the visual representaion in HA switches back shortly after, possibly because HA didn’t receive an acknowledgement that the command arrived.
After calling homematic.reconnect, my rf motion detectors started to work fine, pushing movement immediately as usual. My HM-IP switches though still didn’t send their states, which seems weird to me. Do you experience similar behaviour with the homematic.reconnect service?

9

Yes, there is good news about this. You can buy a USB adaptor for the RPI-RF-MOD here: https://technikkram.net/2019/03/homematic-funkmodul-per-usb-anbinden-hb-rf-usb-tk-jetzt-verfuegbar
They also have a small plastic case to hold the two modules.
There is a little soldering involves, but it’s very straightforward. Once it’s assembled, you just plug it in and reboot the CCU, no configuration required.
This is how I connect it on the NUC. The site also has a very good blog with lots of useful HomeMatic articles.
My experience was the same, but now I just try to schedule HA and HomeMatic reboots for the same time. @danielperna84 had a post about this recently, it’s a bug in the EQ-3 code if I recall correctly, but as it only affects HA so it’s unlikely to be fixed.

10

That’s awesome, thanks for the info! This will definitely be the route I’ll take in the long run too.

An already soldered solution is available too if someone were to not have a soldering iron, but this convenience is quite expensive compared to the effort one would have.
Anyone interested can find it through the hyperlink above.

Ah yes, found it.
He also explains why the reconnect works for the RF components and doesn’t with IP, thank you for pointing me to it! The docs seemed so confident in the workaround that I hadn’t this is issue was known since about 4 months.
A simple workaround for now would be to use one or both of the approaches in the docs with homeassistant.restart instead of homematic.reconnect.

11

Just a short info for now:
I have created a minimal development VM which should make it easier to dive into development for pyhomematic. Here’s the Wiki-Entry at the pyhomematic repository: Contributing and development for pyhomematic · danielperna84/pyhomematic Wiki · GitHub

12

Let me rephrase. None of these solutions use pyhomematic themselves. Home Assistant uses pyhomematic to talk to those solutions. They all expose the XML-RPC API, which Home Assistant itself is not capable of speaking. Hence I made the translator pyhomematic to allow Home Assistant to talk to any software that exposes the XML-RPC API for HomeMatic devices.

It depends on the device. There are a few devices where a channel has different behaviors, depending on the configuration. For example the old wired IO module, where the outputs can be configured to either operate digitally or analog. To load it correctly in Home Assistant, pyhomematic has to ask the CCU how the device is operating. Which was no problem for the old devices. But as you have meanwhile discovered, the HmIP-Server is buggy. As a result, asking for such behaviour-information during the Home Assistant startup may not work because it just doesn’t respond properly. So for these devices we don’t have the possibility to know what the correct entity type would be. As an intermediate solution we can just assume the default. But obviously that won’t be the case always.
To overcome this issue we would need some big changes in the architecture of pyhomematic. Or at least my hope is, that it would help that we cache all configuration parameters once when the integration is initially set up, and on successive restarts we would just use the cached values to dodge the buggy CCU-responses. But that’s a lot of work to implement.

Typically I would say to go with wired whenever it is possible. And even now you can control any device with the homematic.set_device_value, even if it is not supported. You just don’t get an entity for it and you can’t read the state. But at least that’s better than nothing. And with time the support will eventually be added.

It depends on the type of device. For devices that are connected to the mains for their power supply pretty much always listen for commands from the CCU or directly linked devices. And they push their state directly as well.
For battery powered devices there are a few different methods to save energy, depending on the type of the device. A motion sensor for example doesn’t need to listen for packets since it’s just a sensor. Those device typically send state changes immediately (and in cyclic intervals if configured to do so). On the other end of the spectrum there are radiator thermostats. Since they are a combination of sensor + actor (to control the radiator), they do send status packets, but they also listen for packets. However, unlike mains-powered devices they don’t do this permanently. They wake up periodically. Which is fine because it doesn’t really matter if the thermostat starts operating 5 seconds sooner or later.
And there are other variants, which I don’t all have in my head. But that’s very technical, so you can google that kind of information. Here’s one source for that information: HomeMatic – Reicheltpedia

It’s still pushed. pyhomematic does not poll at all, except during startup to get the initial values for the devices. Some devices just aren’t that quick to report their state. There probably is a good reason for this which we just don’t know about.

13

Great, thanks a lot!
I’ll try to learn the ropes as soon as possible.

Ah, then I think I understand the system.
What I guessed before was that Homegear, with its support for many different systems with different protocols, would translate the devices to something general that it itself uses for communication, which would then be the interface to Home Assistant. But that’s what happens from trying to grasp something you’ve never used :smile:

I understand the problem. I don’t think I’d be of any help with that before understanding how pyhomematic’s code works more thoroughly. As soon as I have the time I’ll try to get to know it better; till then I’ll try to help with stuff that’s a bit more superficial.

Do you mind explaining why that is? So far I didn’t find major advantages between the kind of operation (other than maybe range, as the wired series naturally could be attached basically anywhere). But please only do so if you really have the time, I’ll surely find some resource eventually or just make my own experiences, no problem!

Exactly, figured that too after fiddling around with my dimmer. Before I was quite sure that it is possible in some way, but not so sure how.

Just glanced through it, that’s something I’ve searched for! I’ll have a closer look soon.

That’s good to know too!

Thanks again for all your help!

14

Because wired connections are more reliable. Wireless sensors can be sabotaged rather easily. Imagine using door/window-sensors for your selfmade home security system. With RF, a burglar just needs an RF-jammer that prevents the CCU from receiving the packets. The same also applies to WiFi, Zigbee etc… So if you went with a wired solution, physical access is required to tamper with your installation. And ideally by that time your alarm system has already taken care of the dangerous situation.

Well, actually it depends what the better solution is. Compared to wired devices, battery powered devices (which typically are RF), will keep operating even with a power outage. So for example the KeyMatic doorlock wouldn’t make sense if it was wired (except if it hat a batter backup). After all you still want to get into your house, even when there’s no power.

15

Oh yeah, that makes sense.
I’m mostly going into the comfort direction with my current home automation plans - the only thing that I could think of as somewhat security relevant would be my outside motion detectors, but they don’t have any critical function either - so I didn’t think in that direction.
Speaking of the advantage of the battery powered devices: Network and Server would need to have a backup-battery too to remain operable in case of an emergency, therefore I think security-wise the wired devices are most advantageous. If you were to have a battery backup for server and network, you might as well invest in a standby generator for the wired setup and have the security against jamming as well! :smile:

16

Hi
sorry to dig up this post but I find it quite interesting
I’m considering replacing my Homematic IP AP by a raspberrymatic installed in a proxmox VM, and using a HmIP-RFUSB stick
I only own the HmIP-eTRV-B vanes and the HmIP-WTH-B wall thermostat, so I don’t think there is a support issue for these devices

shall I expect any issue?