Just use default sync_state (or sync_state: init if you prefer… doesn’t really matter).
The type depends on the actual DPT that is being used. Refer to your GA report, your installer or the devices manual.
1 Like
Hi Jörg, I wonder if you found a solution for this in the meantime.
I also started at looking into a way to change the color of my rbgww led strips from the MDT Glass Switch 2.
All my lights are Dali controlled and for the rgbww strips I use the individual_colors option from HA (only rgbw possible at the moment) as the installer that setup the knx environment didn’t use gateway’s that does not support colour modes. Setting up a development environment to try making and improvement to support rgbww in a feature release…
I can control the strips using the custom:light-entity-card or the mushroom light card from HA but can not yet turn them on from a switch on the KNX panel.
Any hints are appreciated.
Hello! I am having some issues trying to “connect” a KNX-switch with an LED-strip running WLED. It ends up in an infinite loop and I am trying to understand why it happens.
At first i simply added the GA “LED-list switch” as a normal knx_switch. I made an automation that simply toggled the light.wled if there was a state change in the knx switch.
All was working well but i felt that it would be nice to get feedback to my GA “LED-list status”. So i exposed this GA (1/2/10) as a binary:
- type: binary
entity_id: light.wled
address: "1/2/10"
default: false
Now when the automation triggers it goes in to an endless loop toggling the automation on and off every 50ms.
So I made two automations, one for “off” and one for “on” but no change.
After adding a one second duration as a condition it now works beatiful but I would like to know what is happening when it goes into the endless loop. Any ideas?
You can see what triggered an automation with the automation debugger.
Other than that one would need to see the automation and how you configured the switch to have a better view of what is happening.
The switch:
- name: led_tvrum.switch
address: ‘1/2/9’
state_address: ‘1/2/10’
Automation to turn on:
alias: Tänd LED-list
description: ""
trigger:
- platform: state
entity_id:
- switch.led_tvrum_switch
for:
hours: 0
minutes: 0
seconds: 0
to: "on"
condition: []
action:
- type: turn_on
device_id: 7a79f7033687f2448e476bedafa36cb4
entity_id: light.wled
domain: light
mode: single
Automation to turn off:
alias: Släck LED-list TV--rum
description: ""
trigger:
- platform: state
entity_id:
- switch.led_tvrum_switch
to: "off"
for:
hours: 0
minutes: 0
seconds: 0
condition: []
action:
- type: turn_off
device_id: 7a79f7033687f2448e476bedafa36cb4
entity_id: light.wled
domain: light
mode: single
There is no info in the debugger but ETS diagnostics is flooded with messages. Deactivating the automation instantly stops the traffic on the KNX bus.
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.