in my setup I have a HA instance running on one SBC and a RaspberryMatic CCU3 running on another SBC (with radio module).
For now, this worked quite good. I have a mixture of RF and IP devices which are shown and controllable by HA correctly:
6x RF thermostat
1x IP thermostat
1x IP smoke detector
Now the problem:
I have recently added an IP door/window contact. This contact was registered on the CCU and shows up there, BUT it refuses to show up in my entity list in HA !
I have tried many things like restarting CCU, restarting HA, updating CCU, updating HA, tinkering around with the configuration on both sides, rebooting… no success! Just to say it again: the other devices (RF and IP) work just fine.
This is my HA config (which worked for the device list above):
Which specific device model are you talking about? If it’s a new device, then it simply is not supported by the integration.
In any case, there is a new Homematic integration available as a custom component. With this most newly released devices will work automatically without the need to update.
By the way: the 2001 in the hosts → ccu3 section probably is incorrect. It should be 80.
Regarding the port:
I almost don’t dare to ask, but are you sure? The docs dont mention that afaik. And I’ve kept my config close to the docs example .
About the custom component:
thanks, I’ll take a look at that! I am running a supervised installation of HA and until now I wanted to have the CCU3 separated from the HA instance. But Maybe you convince me .
So it’s a HmIP-SWDM. That one should be supported and available as a binary_sensor entity directly after pairing. The entity_id probably looks something like binary_sensor.aabbccdd1122334455. It wouldn’t make sense that other devices are available and just this one is missing, as the whole list of devices if evaluated at once (except during runtime when you were pairing the device). So at least once you have restarted Home Assistant, it has to be available.
Thanks for making me look at the documentation. It appears as this commit has actually added incorrect information. It is only valid for Homegear, which a minority of people are using. With a CCU JSON-RPC is used, which is operating on port 80 or 443 usually. But as TLS is not supported, 80 is the correct value in most cases.
Also make sure the user you have configured has admin privileges on the CCU. And JSON-RPC has to be allowed in the CCU firewall as well.
Yep, I totally agree that this behavior does not make sense . But that is the reason why am I am here now.
So you seem to have the feeling that a firewall setting might be wrong? I will definitely recheck that again. But as you say: usually it “should” be okay, because the other devices are shown!
Anyway, I will check it again and let you know.
Thanks for your support!
Okay, good point about the user privileges. I have changed the privileges to admin, restarted HA → no change.
Changed port in host config to 80 → no change.
Checked firewall, should be correct:
Before digging any deeper I suggest you just switch to the new integration I have mentioned above. And you have to allow access for Remote Homematic script API.
I had already tried to grant access to the API. Without any difference.
Just tried to re-teach-in the device. From CCU3 side it worked. But from HA side nor difference → not found :(.
But if I understand it correctly the new integration is only available trough HACS, right? When this is true, will this integration sooner or later replace the current one?
Yes. Or you could install it manually. But its much simpler with HACS.
It was the plan to replace the integrated one, but currently it doesn’t look like it will happen. So you should go the route via HACS. The internal integration is not being maintained anymore. Aoart from that, the new integration is A LOT better.
Reading that, I think it would be the more sustainable solution to not solve my individual problem, but pushing the new integration forward.
As it was planned to replace the current integration anyway, and it is already much better, so why not going ahead in that direction? I believe that Homematic will be used by many more people in the future. So it would make life much easier for the devs and supporters (like you, appreciate!), when there is a solid and reliable foundation!
What can we do to make the new integration find its way into HA by default?
I’m not saying the switch will solve your problem. To be honest, the only explanation for your problem is, that you don’t recognize the entity because it has a name you don’t expect. On a technical level it’s impossible to have some entities while not having others (assuming they are all supported). In any case, the new integration will provide proper “devices”, which may make it easier for you to spot the correct entity.
There are multiple reasons why it hasn’t happened yet. And even if it was done, there would be A LOT of breaking stuff because there are so many changes in the architecture. So simply waiting for this to happen wouldn’t spare you the effort. You’d still have to invest a couple of hours to fix everything.
I know that it makes logically (and surely programmatically) no sense that one specific device does not show up! But I don’t think that the name might be the problem, because:
I went into my Entity list and filtered for all entities provided by the (current) Homematic integration
I went into my entity list and filtered for all binary sensors from ALL integrations
I searched the entity list for the name and the serial number of the sensor.
I changed the name of the sensor in CCU
I re-paired the sensor to the CCU (default name)
So I would think that at least one of these measures should have worked, but no.
Again, I totally agree that this behavior incomprehensible. But thats why this topic exists :/.
Sorry, you implicitly got me wrong in this point. I definitely DON’T want to just wait for things to happen. In contrast: if I can contribute in any way (whatever is possible with my limited knowledge ) I am happy to do! My intention to push the new integration forward is NOT to save my time. My intention was/is just to aim for the best solution and value it.
In the meantime I managed to install the new integration through HACS.
And I must say: It works like a charm! Awesome work so far, high respect and appreciation!
And: the binary sensor is found and displayed correctly
Yes, it is definitely a “breaking change” because all names are different now. But: from my point of view this is the preferable option over obsolete/current integration that seems to be not only old-fashioned but also seems to have some bugs .
I agree that it would be nice. But as has been mentioned in the discussion I have linked above, there are obstacles for which we currently don’t have solutions.
Yes, I just went through this discussion. Most points and positions are reasonable, both on the pro-side as well as on the cons-side. But the overall mood seems a little bit “desperate” - which is really sad! Because your new (custom) integrations is so much better and promising compared to the old one.
If it would bring any benefit I surely can join the discussion on github. First thing to decide would be to go either for core integration or for keeping it custom (the majority seems to tend to a core integration). And then define next steps: collecting all the pro-arguments to convince the devs to accept a PR and a replacement of the current integration.
after all devices/entities have been detected and added by the new custom integration, the names were different which of course broke all my references to them (automations, cards…).
I have then just removed all entities from the old integration (because they were “occupying” the names) just by selecting them all from the Entities list and delete them.
After deletion of the old entities, the names were free again and I renamed all newly added entities with the previous names.
all automations and cards and so on work again as before but just with the new integration.
Of course it depends on the specific amount of devices. But in my case this migration was done in really “no time” (< 1h) and is definitely worth it!
Thanks again for this really amazing work! I would really like to see this integration replace the current one!