Cause most of my system is now up and running like it should (except a couple projects I’ve planned later this year (badge-reader, irrigation,…), I’m getting out the little faults I find.
One of the things was that all of my devices from knx_binary_sensor.yaml file had 14 entries in Home Assistant.
The fix was very easy in the end… While moving my (very) old HA-configuration to my new Raspberry Pi 4 and updating a lot of it, I made a simple mistake: my sensors from knx_binary_senors.yaml also did still have an entry in my binary_sensors.yaml file…
A normal light in my house is in multiple groups. That means I have one group address to control only this light, but I have other group adresses which control more than this light. The usual use case is the “central off” feature. When sending to this group address all lights can be controlled.
That means I would configure a knx light with an “address”. This address can be used to listen for the state of the light on the KNX bus, but also to control that light.
Where can I enter the central address?
What I’m missing there is a list of listening addresses … The light state in HA should follow the address and all the listening addresses. HA should send commands only to “address”.
In KNX this is a basic principal. Every item can be connected to multiple group addresses. Only one of them is marked as the sending address.
Home Assistant has its own grouping of entities (lights, switches etc) and can control those groups similarly like you have in KNX. Based on my experience I would not link the KNX groups to anything in HA but rather replicate the grouping in HA. Read more here:
Happy to hear if anyone has different opinion on the subject.
But these grouping is part of KNX. It’s a base principle.
With one telegram I can switch of the light in the whole house. If this would be done with HA this would create a telegram storm as any light must be switched off by its own telegram.
Look at the zigbee integration. There the groups are also kept in zigbee.
This is currently only supported through actuators that provide state COs.
This is not as bad as it sounds - as long as you don’t turn off a whole hotel that way
You can always use a Switch / Service to trigger the central GA directly too. A scene would be even knxier.
Well, there is significant difference between zigbee and KNX - zigbee configuration is as far as I know visible to the controller and therefore to HA. For KNX you would need to replicate it all manually in the HA configuration therefore I think it is much better to do it natively in HA. You can still send telegrams to the group group addresses to benefit from the config of the KNX bus devices.
The benefit is here the user experience. The lights and the visualisation would react immediately at the same time. The state telegrams may create a storm to, but all what these telegrams says is already known. So even when these telegrams get lost it doesn’t matter.
That’s true. In zigbee one can read the group memberships from the controller. In KNX you can find these only in the ETS …
But I’m used to that
I never tried that out. Therefore it’s theoretical only.
I just have problems to understand that such a thing like listening group addresses, which is a core principle of KNX, is not supported. What makes me wonder even more is that there seem to be many people which uses this integration and have no problems with this.
I will see how I can work around that problem …
But you can listen to the group addresses. There is just no easy way to connect the group address of multiple KNX devices to a group of the same devices in HA. You can create a switch (or light) in HA which will control a group of switches (or lights) in KNX. No problem with that. You can’t just link a group entity in HA to a group in KNX.
That’s clear. Sending to e.g. the all lights off group is not a problem. But then all lights go off and this I can see in HA only if the actuator has a state address. I have some old actuators without that feature.
So today i went and checked. Well you are right Both instances doesnt really work. They get confused, and after a while either one works or the other or both stop to work. I really need to find a solution since the lights are on one IP and the Climate is on Another…
Do you guys think this would be a solution? Tomorrow I will try to contact my KNX provider to see what can be done… But they are so hard to get a hold to… specially now with the Corona symdrome!
KNXnet/IP Routing is a multicast-based telegram, which allows a KNX IP device to perform the function of a Twister pair to IP coupler. This means the backbone of a KNX system can be Ethernet-based, allowing a much higher speed of transmission and more flexibility when installing.
Multicast is a group-orientated connection method where, instead of using device IP addresses, all devices point to a standard multicast address. This allows all telegrams to be seen by all KNX IP devices looking at this address. The KNX Association has reserved multicast address 224.0.23.12 but any address could be used as long as it is the same on all devices.
You can also use a simple line coupler. But the projects would maybe have to be adapted. Or both installations could be merged to one line. If you have an knx integrator he/she should know what to do.
Line coupler would require a KNX bus to be connecting the two sections. I understand that only TCP/IP is available so you would need an IP router in each section. Even IP KNX gateway probably would not be enough. But let the KNX installer validate what is possible
can anyone confirm this?