I’m using the HA KNX integration for climate devices (A/C) and also created a few KNX switches for them. Never have experienced the message looping, if I change the state of the A/C unit it nicely updates the HA entities, when I control them from HA it also works well. Maybe some message loop is broken within the HA KNX integration? I.e. when KNX sends the telegram when it is turned on, the HA captures it, changes the entity state but does not send the telegram back to KNX bus. When the state of entity is changed in HA e.g. via Lovelace the telegram is sent to KNX bus, it also sends back the status telegram and that’s it. The same for switch entities (On/Off control and status) and input_select - used to control A/C fan speed.
Hi @adorobis,
no, you got me very wrong. I never experienced msg loops within the KNX integration. That is exactly why I ask @farmio how this is prevented within HA.
Loops only happen when you build the back channel yourself (or the forward channel, for what its worth). And it happens extremely easy when you are manually syncing two external systems through HA (i.e. KNX & Zigbee). Because the entities that you create in HA can only be either KNX or Zigbee but not both. So you have to create separate entities for each world and have to sync them through automations.
OK, clear, this is still ahead of me - once I find some good thermostats 
Hi, and thanks for your replies. I am not currently on the beta channel, and think I will wait for the stable release, but I’ll keep that option (always_callback) in mind when it arrives. There seems to be three options left:
- Create automation to change scene sensor back to 0.
- Use knx_event. I havent looked into how events work, and quite frankly the documentation is sparse. Will my other HA KNX devices work as before even if the relevant GAs are not added to the fire_event_filter? Ie. should I only add the scene GA to the filter?
- Use KNX Ultimate node in Node Red to capture the scene GA. Although I have installed the KNX ultimate node, I havent been able to make it pick up on telegrams to 0/1/35, and I suppose there is a problem with tunneling. If I insert an KNX ultimate node into a flow in Node Red, and restarts HA. Then HA is not able to connect to KNX, but the Ultimate node works, and vice versa if I restart HA without the node and insert it after rebooting. I have an ABB IPR/S3.1.1 IP router, capable of 5 tunneling servers. I am unaware of how it is configured, and how to configure the Ultimate node to make use of a different tunneling server, so this might not be an option before i get my ETS dongle (and then I presume I have to shut down HA to make ETS connect to the IP router).
Ill look more into option 1 and 2 later today.
As to your PS: The GA (0/1/35) which is toggling my binary_switch is not a DPT 1 byte used for scenes, but rather a 1 bit, so I think my setup is future proof? I have different GAs for some of the scenes in my KNX setup, and the problem is the DPT 17.001 - and how to make HA react even if the same scene is activated twice, and the scene number wasnt changed.
EDIT: I’m not sure if I just didnt notice before or there was a change in the docs, but the documentation for the KNX sensor now includes the always_callback config variable: KNX - Home Assistant (home-assistant.io). I cant test it now, but will do first thing in the evening.
I couldnt wait to test the variable always_callback, and it seems to work! The “events: state” node in NR now fires every time a scene is called (regardless of scene number being changed or not), with a payload msg including the scene numer. That should make it easy to integrate KNX scenes with HA entities, such as door lock etc.
Thanks for your help!
I’d say its HAs thing. For the switch entity case: When we have a new state from KNX we call Entity.async_write_ha_state() whereas if HA wants to send something out we get eg. a Entity.async_turn_on(). We can do write_ha_state again then but it will not trigger a turn_on.
turn_on is afaik only called on user interaction or automations etc. not from state changes.
I have never used NodeRed so I can’t really help you there, but if you stick to HAs events you should be fine.
This won’t affect your other knx entities at all. It just filters which Telegrams, additionally to their normal usage, trigger a knx_event HA-Event. If I recall correctly the filter was required to not spam the HA event bus.
If it is proper DPT1 you are fine.
I don’t recall when this was added exactly, but if you are on 0.118 I’d strongly advise to update to 1.0.0 as the knx integration in 0.118 has some major bugs rendering it quite unreliable.
2 Likes
Wow, what a great Home Assistant conference it was yesterday! So inspiring.
With it came a new release of HA with a new versioning scheme. From the blog post of HA 2020.12:
“Changes made to your KNX integration’s YAML configuration, can now be reloaded without restarting Home Assistant. Thanks @spacegaier!”
This is super helpful!
And thanks to @farmio too for all his work on the KNX integration and for killing that nasty bug in 0.118.
2 Likes
Hey!
I think connecting knx switches to arbitrary lights (with switching, dimming, color and TW control if you will) would be a perfect chance to create some nice new blueprints.
Spoiler: thanks to buergi@GitHub and his patience for refining a PR over 2 years, we will, with the next version of xknx, Support DPT3. This could maybe satisfy all your dimming needs with the power of HA sensors. (I personally have not tested this, would be nice if someone could).
We could even host blueprints for KNX in an extra GitHub repo, so they can be improved on by others. I propose github/xknx/HA-blueprints.
What do you think?
1 Like
@Jpsy You’re welcome 
. Not having that option really annoyed me, so I went ahead to put it in.
@farmio Haven’t worked with blueprints much yet, but would those blueprints really be KNX specific?
BTW: I’d prefer “ha-blueprints” (no mixed case).
1 Like
They are because we need to handle payloads coming from xknx (eg for dimming).
Sure if you just want to ON/OFF a light, a more generic blueprint would probably also work.
Maybe we can even set up exposes from a blueprint 
I have not worked with any blueprint do far, but saw it in the conference ending keynote and was instantly intrigued.
I’m sure there are users who come up with awesome ideas for this. And having them in a common repo can help keeping them up to date with changes in xknx (eg we will change payload of knx_event soon - this could be changed on release for the blueprints, if one uses it).
Hmmm. I don’t want to spoil your enthusiasm.
I see that automations like the dim script from this cookbook could be packaged as blueprints with freely configurable sensor and actor entities. But I have doubts whether this would be really practical.
With each blueprint you would have to explain the corresponding KNX setup. Like “you need a dim actor configured with an absolut% GA and a status% GA with DPT5, plus a switch configured to send only ON telegrams…”.
I am afraid this will not be as user friendly and intuitive as it may appear on first glance.
Plus - looking at my 99% Node RED automations - they are all so individual with so many variations that I could only see a very small fraction to be standardised into YAML blueprints. (Beside the fact that I always have to refrain from YAML bashing because I think that it is basically just a big syntactical bull*#@$… damn I lost control again. 
)
Well, maybe I am getting it all wrong and just don’t see the full potential of blueprints for KNX yet.
I have understood we’d only need to specify the input (switch). The output device (light) is then controlled via the HA API. So it doesn’t care if the output is a knx light entity with whatever group addresses but it can be any HA light entity (Hue etc.).
(For the dimming switch example).
And connecting knx switches to different platforms is a very common question (with status update etc) where I don’t really see a need for enhanced logic. (Not to say logic can’t be applied later).
I also think blueprints are more aimed at new HA/Home-automation users. I wouldn’t recommend coupling HA to NR with some loop breaking logic etc just to turn on a light. That’s no good onboarding experience.
We’ll see. I have some questions and feature requirements for these blueprints which I hope to get answers for in some future HA version (HA Discord doesn’t seem to be helpful for that).
Edit: seems like it is planned for integrations to be able to bundle blueprints. If dimming is the only idea that comes up we may just wait for this.
1 Like
Hi
I’m relatively new to HA.
My question concerns KNX. Now I’ve set some values as a sensor - unsigned byte.
But I should be able to SET these values to a certain value, like 0 to 4.
There exists an object “light”, but my objects are certainly not lights.
And I think the object switch can only contain a binary value.
How can I SET a KNX object to an integer 0 to 4?
Hi! Welcome to HA 
No, sensors are read only by design.
¯_(ツ)_/¯ without configuration or entity infos ( HA-IP:port/developer-tools/state ) we can’t say anything about this.
Definitely.
You can use expose or knx.send service to send values to the bus - it depends on where these values shall come from.
Is there a workaround to assign areas to knx devices?
Hey together, thank you very much for this cookbook, this helped me a lot understanding KNX and HA. However, there is one thing I cannot get to work and that is to use a KNX scene as a trigger for an automation.
In ETS, I created a switch, which simply sends scene number 64 to the bus.
In knx.yaml I added:
- name: Scene_Testszene_64
state_address: '10/1/241'
type: scene_number
The scene number appears correctly in HA:
Then I would like to use the scene as a trigger for an automation. In the following, to make it easy, it is just supposed to switch on a light. However, when I hit the switch on my KNX switch, nothing happens.
I have been working around with in automations.yaml
- id: KNX_Scene_64
alias: KNX Szene "Test"
initial_state: 'on'
trigger:
- platform: state
entity_id: sensor.scene_testszene_64
to: '64'
condition: []
action:
- service: light.turn_on
entity_id: light.arbeitszimmer
or with
- id: KNX_Scene_64
alias: KNX Szene "Test"
initial_state: 'on'
trigger:
- platform: state
entity_id: sensor.scene_testszene_64
to: '64'
condition:
- condition: template
value_template: '{{ (float(trigger.to_state.state) == 64) }}'
action:
- service: light.turn_on
entity_id: light.arbeitszimmer
but I cannot get it working. Hopefully, there is somebody around here, who can help me.
Thanks a lot in advance. If you need additional information, I am glad to send them.
Thank you,
Stefan
Try either one or both of
- set
always_callback = Truefor the sensor - use
numeric_stateas trigger platform and int instead of string into:
1 Like
@farmio Thank you very much. always_callback = true did the trick.
Numeric_state looked odd, as it wanted to get above and below…
Yeah, right. I think this is odd too. An exact: condition would be nice.
Hey! Just a heads up for the 2021.2 release tonight:
-
knx_eventdata attributeaddressis renamed todestination(becausesourceand others are added) so rename this in your automations etc. -
fire_eventboolean configuration is deprecated - you can delete it safely -
fire_event_filterconfiguration is renamed to justevent_filter- no flames involved
and a little shameless plug you can use (and possibly improve) my blueprint for dimming HA lights from knx KNX - relative dimming for lights
2 Likes