Home Assistant integration needed

[danielperna84]

Someone has to come up with an integration (or at least the boilerplate I can build up upon) that makes use of this project.

This is what I need:

• A boilerplate, which allows me to add the integration via Home Assistants UI
• It has to allocate 3 files (json) where hahomematic can store its cached data
• In the first part of the configuration it should ask for the local listening IP and port of the callback-server. Both options are optional
• After that the user has to be able to configure an arbitrary number of hosts, which need the following options:
• • name (string)
• • host (IP address or hostname)
• • port
• • path (string, optional, default should be /)
• • username (string, optional)
• • password (string, optional)
• • tls (checkbox to enable encryption)
• • verify_tls (checkbox to enable SSL/TLS verification)
• • callback_hostname (string, optional IP address or hostname)
• • callback_port (optional port)
• • local_port (optional port)
• • json_port (optional port)
• • json_tls (checkbox to enable encryption for communication via JSON-RPC)

Any help is welcome!

[chr1st1ank]

Great initiative! Thank you very much for this. I've been using the old integration for years now. It is working fine with exactly the flaws you mention above.

I can try to contribute a bit as my time allows. I've got a bunch of devices here. Async Python and networking is fine for me, but about the HA integration I also have no clue.

One thing would be good: Design the architecture in away that as much as possible can be tested without HA. Setting up an editable HA instance for development was the most complicated thing when I did my tiny contribution some time ago

[danielperna84]

but about the HA integration I also have no clue.

That's exactly the part I need help with because I don't know much about the modern integrations as well. 😅 Apart from some small details and custom devices this project is already working. I'll let you know if there's something I need help with.

Right now I got the basics going, but I don't know if everything makes sense for the integration. Hence I need the HA-part to do more testing and possibly do some changes.

PS: This project does not have any async stuff. There's ne async XML-RPC library we could use, and I suspect the XML-RPC server within the CCU isn't too happy with parallelism as well. So this will stay synchronous.

[hanzoh]

Until now, I have also only developed old-style custom_components or fixed existing ones. Maybe we could start from here?

https://github.com/custom-components/integration_blueprint

Regarding async, can’t these libraries be used?

https://pypi.org/project/async-rpc/ https://pypi.org/project/aiohttp-xmlrpc/

[danielperna84]

Until now, I have also only developed old-style custom_components or fixed existing ones. Maybe we could start from here?

https://github.com/custom-components/integration_blueprint

That's what I thought. My greatest fear is how to implement the configuration of multiple hosts. I want to retain the possibility to connect to different CCUs (and I know there are people doing that from the forum).

Regarding async, can’t these libraries be used?

https://pypi.org/project/async-rpc/ https://pypi.org/project/aiohttp-xmlrpc/

Didn't know these exists. The last time I have checked there were none. The aiohttp flavour is looking ok. But instead of tornado it should probably use some aio-webserver. That being said, I feel for now we should stick to the synchronous flavour for the first implementation. As said before, we had bad experiences with how the CCU handles requests. That's why we are using the locking ServerProxy. Without it we ran into issues with concurrent request against the CCUs API.

[hanzoh]

Multiples hosts should work by adding the integration multiple times, like esphome does it.

https://github.com/home-assistant/core/tree/dev/homeassistant/components/esphome

[danielperna84]

The problem with that is, that we only want to create a single server object that handles all the events. I don't know if it's possible for the configuration to skip the server-step if there's already another instance configured. And even if so, that would make the setup more tricky I guess because the configs what have to be processed in the correct order (the one with the server-config first).

[noxhirsch]

@danielperna84 I'd really like to help, but unfortunately I'm not skilled enough to do more than copy and adapt small code fragments, as I already did for pyhomematic. But if you need help testing hahomematic I'm definitely available (RaspberryMatic VM, ~25 device types, ~60 devices in total - so it's not a very big setup, but it's not the smallest either).

[danielperna84]

For reference: this blog post seems to provide a way how the host-steps can be repeated. Hope that's still valid.

[danielperna84]

Regarding the cache-files I had a look at other Home Assistant components. The TTS integration allows to configure a path for the cached audio-files. I guess a simlar approach would also make sense for hahomematic. Until now I have assumed the exact files should be configured. But maybe just setting a path is more futureproof, as hahomematic could just do whatever it wants based on a single configured path.

Edit:
Done with 6622c37de8d7389e41d9cb00b16837a19de4e0a0.

[dickesW]

hi @danielperna84. I'm happy to help testing the new integration. I just setup a ha sandbox environment. so let me know how I can help to support!

[danielperna84]

@dickesW

There has not yet been any activity regarding the integration from my side. I'm still waiting for contributions. So don't hold your breath. ☝

[danielperna84]

To whom it may concern: I was provided with the base structure for a custom component, which I have published in the custom_homematic repository. I did not yet have time to test it or have a thorough look at it. As far as I know, this doesn't do much yet, except providing the config flow which allows to configure the interfaces one after another, just like I asked for.

I will have a look at it some time in the future if I have more time. Until then anyone else of course can have a look at it and try to come up with something that is working.

The feedback I got with hahomematic so far is, that it creates to many entities. So we might have to gather some commonly uninteresting paramters in some list to exclude them from being created as an entity.

[hzpz]

The feedback I got with hahomematic so far is, that it creates to many entities.

The new entity categories may help, too.

[noxhirsch]

The new entity categories may help, too.

Currently I'd say that the entity categories do not help, because they only make the device view clearer - in the entity picker and states list you still have all entities unsorted. But of course this can change at some point, since it's just the first HA release with entity categories.

[ThomDietrich]

Hey,

The feedback I got with hahomematic so far is, that it creates to many entities. So we might have to gather some commonly uninteresting paramters in some list to exclude them from being created as an entity.

Excluding some undoubtedly uninteresting parameters sounds like one step. As for the rest, I am a big fan of how the Tasmota integration approached that issue:

Important sensors are provided as expected, arguably less interesting ones are disabled by default and can be enabled by the user as needed (in the example I've enabled the RSSI entity).

[SukramJ]

I think this issuer can be closed her. Further opinions and testing feedback should be collected in a discussion.