Strange, seems ok to me. Have you tried without the default: false for expose?
Other than that have a look at this blueprint: KNX Virtual Device: Light
Tried to remove âdefault: falseâ with no success. Tried to remove the expose but no success.
Tried the blueprint and GREAT success. Works like a charm.
I am able to repeat the issue with my old automations and I try to read the debugger but there is not really alot of information.
Trace of turn off automation:
this:
entity_id: automation.tand_led_list_tv_rum
state: 'on'
attributes:
last_triggered: '2022-08-24T18:49:53.114795+00:00'
mode: single
current: 0
id: '1660506150623'
friendly_name: SlÀck LED-list TV--rum
last_changed: '2022-08-24T18:43:12.356818+00:00'
last_updated: '2022-08-24T18:49:53.129220+00:00'
context:
id: 01GB8K106TAJ8P7WB40DJZNVTC
parent_id: 01GB8K106T8S3R7V2G5QBGQ4YJ
user_id: null
trigger:
id: '0'
idx: '0'
platform: state
entity_id: switch.led_tvrum_switch
from_state:
entity_id: switch.led_tvrum_switch
state: 'on'
attributes:
friendly_name: led_tvrum.switch
last_changed: '2022-08-24T18:49:53.165579+00:00'
last_updated: '2022-08-24T18:49:53.165579+00:00'
context:
id: 01GB8K108DE6RQ5QKZRK2Q32W3
parent_id: null
user_id: null
to_state:
entity_id: switch.led_tvrum_switch
state: 'off'
attributes:
friendly_name: led_tvrum.switch
last_changed: '2022-08-24T18:49:53.216825+00:00'
last_updated: '2022-08-24T18:49:53.216825+00:00'
context:
id: 01GB8K10A03357ZT9AWJEEW85B
parent_id: null
user_id: null
for:
__type: <class 'datetime.timedelta'>
total_seconds: 0
attribute: null
description: state of switch.led_tvrum_switch
Trace of turn on automation:
this:
entity_id: automation.slack_led_list_tv_rum
state: 'on'
attributes:
last_triggered: '2022-08-24T18:49:53.268885+00:00'
mode: single
current: 0
id: '1661277818780'
friendly_name: TĂ€nd LED-list
last_changed: '2022-08-24T18:48:42.675994+00:00'
last_updated: '2022-08-24T18:49:53.482983+00:00'
context:
id: 01GB8K10BM7YMYZGZ4A7Q20269
parent_id: 01GB8K10BMRA84DNX9BX564K5D
user_id: null
trigger:
id: '0'
idx: '0'
platform: state
entity_id: switch.led_tvrum_switch
from_state:
entity_id: switch.led_tvrum_switch
state: 'off'
attributes:
friendly_name: led_tvrum.switch
last_changed: '2022-08-24T18:49:53.478541+00:00'
last_updated: '2022-08-24T18:49:53.478541+00:00'
context:
id: 01GB8K10J6PKQZV1R1HZMYSY7S
parent_id: null
user_id: null
to_state:
entity_id: switch.led_tvrum_switch
state: 'on'
attributes:
friendly_name: led_tvrum.switch
last_changed: '2022-08-24T18:49:53.529779+00:00'
last_updated: '2022-08-24T18:49:53.529779+00:00'
context:
id: 01GB8K10KSKDP9T1RRSH3NH4E3
parent_id: null
user_id: null
for:
__type: <class 'datetime.timedelta'>
total_seconds: 0
attribute: null
description: state of switch.led_tvrum_switch
It seems the two automations are fighting each other because if I deactivate either one the loop stops.
Iâll keep running with the nice blueprint but i bothers me that I cant figure out what is happening with the original setup.
Thanks for the help!
Hello, I have inherited an old (ETS4, installed 2012) KNX installation and am slowly gaining control over this beast. Reading up on KNX documentation and did the eLearning this morning, so starting to understand the domain more.
I managed to fix a buggy light (wouldnât turn off properly) so that was a big win! Many hoops to go through in order to get there but now I know how to update configuration on the devices although the project I inherited is incredibly messy and I donât dare to start from scratch.
And now I have hit a snag when trying to connect HA with KNX.
There is communication between KNX and HA however the actual light isnât turning on after I send the signal from HA.
I added a switch (Device type is Zennio Quad 3.3) which has the address 1.1.50
This switch has 4 group objects, of which two are functions to trigger two different scenes (which dim the light on/off). One of those functions has the Group Address 1.4.20
I have the following configuration:
knx:
switch:
- name: "WC"
address: "1/4/20"
state_address: "1/4/20"
expose:
- type: binary
entity_id: light.staircase
address: "1/1/64"
default: false
logger:
default: warning
logs:
xknx: debug # sets the level of all loggers
xknx.log: debug # provides general information (connection, etc.)
vxknx.raw_socket: debug # logs incoming UDP frames in raw hex format
xknx.knx: debug # logs incoming and outgoing KNX/IP frames at socket level
xknx.telegram: debug
The staircase device was just to experiment with reading something from KNX.
In the logs I see the following when I boot up:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />
body="<TunnellingAck communication_channel_id="20" sequence_counter="1" status_code="ErrorCode.E_NO_ERROR" />" />
2022-09-01 19:21:49.205 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.1.50" destination_address="1/4/20" payload="<GroupValueResponse value="<DPTArray value="[0x31]" />" />" />
2022-09-01 19:21:49.205 WARNING (MainThread) [xknx.log] Can not process <Telegram direction="Incoming" source_address="1.1.50" destination_address="1/4/20" payload="<GroupValueResponse value="<DPTArray value="[0x31]" />" />" /> for WC - State: <CouldNotParseTelegram description="Payload invalid" payload="<DPTArray value="[0x31]" />"/>
2022-09-01 19:21:49.207 WARNING (MainThread) [xknx.log] Can not process <Telegram direction="Incoming" source_address="1.1.50" destination_address="1/4/20" payload="<GroupValueResponse value="<DPTArray value="[0x31]" />" />" /> for WC - State: <CouldNotParseTelegram description="Payload invalid" payload="<DPTArray value="[0x31]" />"/>
When I change state on the light in HA nothing happens with the actual light but I do see some entries in the Group Monitor. They are grayed out, havenât come across this in the documentation, what does it mean?
Any idea what I can try next? Thank you all for collecting so much valuable knowledge here in this thread!
I solved it!
I actually needed to define two scenes (dim on, dim off) because of how the light was setup! So now it works via HA, beautiful 
Now my next step is to turn it into a switch somehow within HA. Perhaps automation might be the way to goâŠ
Hi 
!
Maybe you can make use of a template switch and the knx.send service for that.
Itâs kind of tricky, as a knx scene usually has no state - so you canât really say if it is âonâ or âoffâ since the GAs value could not only be 0 and 1 but also 5 or 69âŠ
For your debugging purposes:
Use this as it reduces the amount of logs you very likely donât need drastically:
logger:
default: warning
logs:
xknx.telegram: debug
Here you can see DPTArray value="[0x31]" which means it is a 1-byte DPT since the list ([ ] denotes a list) has one element (2 byte would look like value="[0x12, 0x34]").
DPT: Data Point Type - you find these in ETS group objects and GAs. I guess its DPT 17.001 Scene.
A DPT 1.x, 2.x or 3.x would read DPTBinary and not be list-notated.
DPT 1 is binary data - on/off, open/closed etc. DPT 2 is 2bit, DPT 3 is 1 bit plus 3 bit information used eg. for dimming lights while holding buttons.
See https://www.knx.org/wAssets/docs/downloads/Certification/Interworking-Datapoint-types/03_07_02-Datapoint-Types-v02.02.01-AS.pdf for more (all 
) information about DPTs.
Unfortunately a Knx telegram transports no information which DPT is in use except of the length - and that is shared across a range of DPTs. In the HA Knx documentation every (I hope) configurable address key has an expected DPT noted. So you can match this with your project to see if a GA can fit. If the length doesnât match you get this âPayload invalidâ warning.
1 Like
####################
# Lights
####################
light:
# LumiĂšre du bureau du haut
- name: "Bureau Haut"
address: "1/1/0"
state_address: "1/1/1"
Pour ma part je sĂ©pare lâadresse pour actionner et lâadresse dâĂ©tat au niveau dâETS
Great Cookbook - that really helped me a lotâŠ
Only thing for now i canât figure out, is where to put what if i want to split my config from configuration.yaml - and want to have a knx.yaml where all KNX related is placedâŠ
I tried in Configuration.yaml to set !Include knx.yaml
And inside KNX.yaml:
âââKnx:
number:
name: âtestâ
address: â1/0/0ââââ
That is not working - i need some platform data it says error on :S
Hi 
! This is documented here: Splitting up the configuration - Home Assistant
Basically move knx: to configuration.yaml in front of the !include statement.
knx: !include filename
PS: multiline code segments are denoted by tripple backticks ``` in a separate line and please copy&paste full exact error messages, this makes it easier to help.
Hi to all routing users out there !
It would be awesome if you could give the current beta a try (or update early after release of 2022.10).
I did make some changes regarding routing: implemented proper flow control. Since we have a default rate_limit of 20 Telegrams/second this should not make a huge difference as we are unlikely to run into congestion (
).
Nevertheless now you should be save to disable rate limit (set to 0) and the system should keep working fine (but faster 
) - even on heavy load like reading values on startup (where we are also taking different measures to avoid congestion anyway, but I guess you can really test it with automations if you like 
).
Technical details: when your routers canât forward all IP-received telegrams to TP (their sending queue fills up) they send a RoutingBusy message to IP which means - pause sending for some time (~ fraction of second). We previously ignored that. Now xknx handles these properly according to specifications (I hope 
).
3 Likes
Iâve updated to the beta on my system. I have 28 knx devices and a Berker IP router set up for tunneling and rate_limit set to 0. Communicating with most of the devices, lights, thermostats, heating actuators etc. Everything seems to be working fine, is there anything in particular you are looking for?
Thanks for giving it a try!
Then the changes donât even affect you. Itâs for routing only.
Tunnelling has had proper flow control for long time now (I guess since secure tunnelling was introduced). So using Tunnelling without rate_limit should be fine as well.
And I donât expect any observable changes with somewhere below 200 GAs 
- if everything works as expected there should be none observable changes 
(except for faster telegram transmission in 10-milliseconds range).
Ah sorry missed the point about routing even though it was in bold letters I use about 100 GAs now, will probably end up with less than 200 even after hooking up everything I can imagine. I believe I tried setting up routing but did not get it to work. Is there any reason why I should try again? The system seems responsive now, I can feel no difference between switching on a light using a KNX switch and using HA.
No tunneling is just fine - even much more tested and has proper failure feedback. Stay with tunneling if it works for you.
Routing should imho only be preferred on very big installations (having multiple routers) or when no more tunneling endpoints are free.
1 Like
Hello hoping someone can help:
I have a KNX button which I would like to use to toggle my garage door (garage door (non-KNX) is integrated into HA and works fine with HA). The plan is for me to be able to push the KNX button, which will tell HA to open or close the garage door (toggle).
I have ETS.
I am wondering how to setup ETS and HA for this? should I set the button to send a value? or be a switch? thanks for any help!
Id use a knx_event for that in an automation calling cover.toggle (or whatever it is called) service.
In knx define a GA the switch sends a 1 on press.
Thanks!
what should i put in my in the config.yaml under KNX? something like this?
i have set the button to send a 1bit value of 1 to group address 1/2/0
KNX:
event:
- name: "Garage Door button"
address: "1/2/0"No. Events donât have a name key. See KNX - Home Assistant
They are matched by GA in the event_data -> destination field in an automation.
1 Like
Thanks a lot! I am getting there
I am able to get the event to show up in HA when I push the button:
data:
data:
- 1
destination: 1/2/0
direction: Incoming
value: null
source: 1.1.32
telegramtype: GroupValueWrite
origin: LOCAL
time_fired: "2022-10-04T20:04:42.181614+00:00"
context:
id: 01GEJ9KF25FHJYE2RVS272AKX4
parent_id: null
user_id: null
However not having success with the automation:
- id: '1664913676091'
alias: Toggle Garage with KNX button
description: ''
trigger:
platform: event
event_type: knx_event
event_data:
address: '1/2/0'
condition:
condition: template
value_template: '{{ trigger.event.data.data[0] == 1 }}'
action:
- service: light.toggle
data: {}
target:
entity_id: light.1st_floor_hue_go_1
mode: single
I took inspiration for the automation from : Trigger automation with KNX Scene Event - #2 by 123
(I am using the hue go light to test rather than having the garage door open and close, once that works I will switch it to the cover.toggle)
any suggestions?
you seem to send an interger â1â instead of a DPT1 binary â1â. Its ok but unusual. If you use a binary payload you donât need [0] at trigger.event.data.data[0].
Other than that, if you have only one payload to check against you can use
trigger:
platform: event
event_type: knx_event
event_data:
destination: '1/2/0'
data: 1 # or [1] if you use integer payloads
Or even omit data: because there is not going to be a 0 sent to anywayâŠ
Maybe include direction: Incoming
condition is indented too much. It should be on the same level as trigger. You can remove it entirely if you use data key in event_data.
Edit: wrong key in trigger. address should be destination.
Iâm using Node-Red and the KNX-ultimate node. I think itâs quite a powerful combo for people that canât really YAML.