Hi @farmio, thanks for the feedback. Actually I thought that knx: event: in configuration.yaml was to generate events from HA to the KNX bus, not to read them. Now it’s crystal clear and I’ll give it a try.
EDIT: @farmio, regarding your 2nd bullet point: the GA 7/1/1 is already assigned to that scene call in the parameter config of the ekey KNX gateway, in ETS. Should I link the same GA to a dummy device?
This is only necessary if the Telegram needs to travel over a coupler / router with filtering activated.
So if one of the devices linked to the GA is on the same line as your HA tunnel endpoint it already travels the filter and you should be fine.
You can always link it to a dummy if you think this is providing you useful information in ETS.
Tldr: if it works, no action needed.
Hi @farmio, I actually hadn’t luck getting this working. I added the event config to my knx: block:
knx:
event:
- address:
- "7/1/1"
type: "scene_number"
and I correctly have this in ETS Diagnostic:
But still I can’t get my test automation triggered:
trigger:
- platform: event
event_type: knx_event
event_data:
address: 7/1/1
condition: []
action:
- service: persistent_notification.create
data:
title: Fabio
message: impronta Fabio
mode: single
I also tried to flag the 7/1/1 GA with “Pass through Line Coupler” in ETS, but HA doesn’t receive any event.
Thank you.
You are using the wrong key for event_data - it should be destination:, not address:. See the KNX events documentation
You can see all events (or filter just for knx_event) at 
- there you will also see the exact format of the fired event.
So, long time, no update. But 2022.4 will change that 
We now support KNX IP Secure Tunnelling connections 
. Have a try with the current beta if you have an interface that supports secure! We are especially interested if getting a connection when using a .knxkeys file works as intended.
Preliminary documentation can be found here: KNX Secure Netlify Preview
You will need to delete the integration, re-add it and select “tunnelling” (no data should get lost in this process - except for configured KNX options like IP address).
Also be sure to remove connection options from YAML configuration (eg. tunneling:), which were deprecated in December (you should have has warnings in your logs about this). The KNX integration won’t start anymore when these keys are still in your config.
We also moved KNX protocol logic to a separate thread, which should increase connection stability. Disconnections were mainly caused by (async-) misbehaving 3rd-party integrations, components or libs. This should now not affect KNX tunnel connections anymore.
Today I have to ask for guidance myself in this cookbook.
Maybe @farmio or any of you other guys has an idea how to solve my problem.
I want to use the HSL controls (Hue, Saturation, Lightness) of an MDT Glass Switch 2 (see pic below) to control non-KNX lights. So basically I have the H, S and L sliders on the KNX switch and only want to read their state into HA to use it there. (In my case I will use it in Node RED within HA, but that should not make a difference.)
I am looking for the most elegant way to do this.
I will have to receive the DPT 3.007 dimming information (4bit) from each slider, accumulate it into percentage values and send it back as DPT 5.00X status information, so the sliders on the switch move when the buttons are touched. Normally all this is done by a KNX dimming actuator, but as explained - in my case there is none.
HA’s KNX lights actually provide a HSL model. So I could create a light with hue, sat, brightness to hold the calculated status information. But unfortunately KNX lights in HA have no option to respond_to_read. So I cannot use this information to send it back to the KNX bus and update the sliders on the switch.
I know that I can solve it all with distinct event and number entities in HA for each slider. But is there a more elegant way? Maybe one that would at least hold a direct RGB or RGBW representation in HA?
Thanks for your thoughts!
I have to guess - never did such thing myself…
Id try to expose the HSB levels from the target light directly and use a modified version of my blueprint KNX - relative dimming for lights to adjust it from DPT3. No KNX Light (or number) entity needed.
Does anyone knows how to manually control the speed of my fancoil?
I cannot find any variable in the climate options.
Is there some workaround?
A number or select entity would be a workaround.
And would you make it a part of the climate options or put it in a different platform?
It’s not supported by Knx climate entity. It would be an extra entity. Maybe you can also use a fan entity.
I am going to try, will let you know.
Hi Jorg,
Thanks for this guide. I was able to set up my lights, curtains and thermostats. I do have a question as
I am relatively new to HA and KNX. I am using MDT controllers. When my installer set them up, and handed me the group address report, I noticed that all the lights had a “power” address meaning it can log the consumption when a light is switched on (at least that is my assumption).
For example:
1/0/0 Switching - Wardrobe Lights L12
1/0/1 Status - Wardrobe Lights L12
1/0/2 Dimming - Wardrobe Lights L12
1/0/4 Value STATUS - Wardrobe Lights L12
1/0/5 Activ POWER meter - Wardrobe Lights L12
My KNX yaml file for the wardrobe light looks like this:
- name: "Wardrobe Spots"
address: "1/0/0"
state_address: "1/0/1"
brightness_address: "1/0/3"
brightness_state_address: "1/0/4"
How would I add the consumption reading “1/0/5” ?
Hi 
!
Just configure an additional sensor for it.
Thanks Matthias, that makes sense…
Can you suggest the “type” and “sync state” I should use?
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.
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:
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.