KNX Cookbook

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 :slight_smile:

Now my next step is to turn it into a switch somehow within HA. Perhaps automation might be the way to go…

Hi :wave:!
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 :rofl:) 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 :wave:! 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 :wave:!
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 (:snail:).
Nevertheless now you should be save to disable rate limit (set to 0) and the system should keep working fine (but faster :racing_car:) - 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 :upside_down_face:).

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 :rofl:).

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 :upside_down_face: - if everything works as expected there should be none observable changes :wink: (except for faster telegram transmission in 10-milliseconds range).

Ah sorry missed the point about routing even though it was in bold letters :slight_smile: 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 :rofl: 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 :slight_smile: 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 :slight_smile:
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.