Adding a feature to control HomeAssistant entities with knx group addresses

[Chri5chu]

Hello there,

I have an idea for a new feature in the knx integration. Maybe it's already discussed but I couldn't find anything with this topic.
There is the expose feature where you can expose different entity states to knx. I want also to be able to control a relais or something like that from the knx bus. I could possibly build an automation with the knx telegram trigger but that would switch some parts of the function to the automation location and the other half to the knx integration.
It would be really need if both ways are in the same place.

For example: If I'm using the Matter Server integration and connect a Smart Relais or a Smart Light Bulb to Home Assistant I already have an entity for the HomeAssistant dashboards. If I want to switch it now with a KNX Button from my wall I have to build an automation and if I want to get a status update on my button I have to build an expose, too.

I hope I described my request understandable.

I would be happy about a short feedback about this request either if it's possible and/or how I can help with it.

Best regards,

Christopher Schulte

[farmio]

Hi 👋!

Currently this is mostly solved by blueprints. See https://community.home-assistant.io/tags/c/blueprints-exchange/53/knx/91

It was my plan to have some kind of "bidirectional controlling of HA entities" (at least some common cases) in the integration at some point.

how I can help with it

Well, there's a lot to do for such a feature

• we'd need a good name for it (naming is hard 🙃). I've always thought about "control" or "bind".
• we'd need a schema for every platform
  • which states should be exposed by which DPT
  • which service-calls (actions) shall be triggered by which DPT
  • do we need any additional configuration
• a frontend view has to be created
• backend storage needs to handle this
• backend logic has to be implemented
• documentation has to be written
• strings will have to be translated

[ordex]

I just worked on the "write-back" option of the "expose" KNX feature.
Basically after exposing a specific HA entity, you will be able to change its state by writing to the exposed GA.

This way you can use KNX devices (living on the KNX bus only) to change HA entities, such as lights, and other things.

PRs here:

• HA core: KNX: expose write back home-assistant/core#177495
• KNX frontend: Add write-back toggle and source whitelist to expose editor knx-frontend#422

[Chri5chu]

I just worked on the "write-back" option of the "expose" KNX feature. Basically after exposing a specific HA entity, you will be able to change its state by writing to the exposed GA.

This way you can use KNX devices (living on the KNX bus only) to change HA entities, such as lights, and other things.

PRs here:

• HA core: KNX: expose write back home-assistant/core#177495
• KNX frontend: Add write-back toggle and source whitelist to expose editor knx-frontend#422

That would be exactly what I'm searching for. Thanks a lot. Will there be an option to use a different address for changing the entity from KNX as for sending the status to the knx bus?

[Chri5chu]

Hi 👋!

Currently this is mostly solved by blueprints. See https://community.home-assistant.io/tags/c/blueprints-exchange/53/knx/91

It was my plan to have some kind of "bidirectional controlling of HA entities" (at least some common cases) in the integration at some point.

how I can help with it

Well, there's a lot to do for such a feature

• we'd need a good name for it (naming is hard 🙃). I've always thought about "control" or "bind".

• we'd need a schema for every platform

  • which states should be exposed by which DPT
  • which service-calls (actions) shall be triggered by which DPT
  • do we need any additional configuration

• a frontend view has to be created

• backend storage needs to handle this

• backend logic has to be implemented

• documentation has to be written

• strings will have to be translated

Well I'm afraid to say that I think that I can't really help programming it. I mean I would be happy to try but can't say that I'm definitely able to help there. What I'm capable of is helping with the documentation. And as for naming it I think it could be possible to look for the matter integration of some other devices. If you want to expose your matter entities to knx bus they name it matter controller...maybe it could be named knx controller. I'm also happy to help with the KNX DPT. In my opinion it should be group as devices like a lamp for switching you would need DPT 1.001, for dimming 5.001 and on and on. If I can help with it tell me how I can do it the best way.

[ordex]

That would be exactly what I'm searching for. Thanks a lot. Will there be an option to use a different address for changing the entity from KNX as for sending the status to the knx bus?

That's a good point, like a separate setpoint and a state address.
However, if you check the PR in ha-core, you'll see that the whole feature has been rejected in its current form. This is closer to a hack rather than a solid extension for the xknx integration.

Hence this requires to be re-designed before we could move on.

[Chri5chu]

That would be exactly what I'm searching for. Thanks a lot. Will there be an option to use a different address for changing the entity from KNX as for sending the status to the knx bus?

That's a good point, like a separate setpoint and a state address. However, if you check the PR in ha-core, you'll see that the whole feature has been rejected in its current form. This is closer to a hack rather than a solid extension for the xknx integration.

Hence this requires to be re-designed before we could move on.

Thanks a lot anyway for the massive amount of work. As I said to farm I'm happy to help with anything if I'm capable to do something. Unfortunately I'm not confident enough in changing or adding code but I can help with the stuff around like documenting.

[farmio]

I also think having discrete set
and state GAs would be essential for this feature.

For a start, I guess doing switch and light entity platforms would probably be a good scope. Switch is an easy proof of concept since there isn't much it can do. Light is very complex in its config and thus shows shortcomings of design and implementation early. (I did the same for Ui entity config)

[Chri5chu]

I also think having discrete set and state GAs would be essential for this feature.

For a start, I guess doing switch and light entity platforms would probably be a good scope. Switch is an easy proof of concept since there isn't much it can do. Light is very complex in its config and thus shows shortcomings of design and implementation early. (I did the same for Ui entity config)

Just let me know how I can help you when you start the project. I would really love that feature. I think the main functions should be Light, Cover Control, Thermostats and Sockets...You can do really much with just these four. Maybe you could combine sockets and lights if you go for a modular design light you want a switching address plus status and activate a checkbox for dimming and so on. But Maybe it's not possible like that. I don't know exactly how light entities are managed and if it's possible to get modular functions out of it.

[farmio]

Many entities provide a supported_features attribute. This could be used to prepare the schema shown to the user. So for a light that doesn't support colors, we don't show color-GAs.