This was the solution. Thanks!
knx:
expose:
- type: 'binary'
entity_id: light.hue
address: '0/1/2' # a group address attached to the state communication object or a "listening GA" on the trigger group object
FYI. Type binary is undocumented in the KNX documentation.
It’s documented on the Knx integration site at the “Expose” documentation. “Binary” is no valid Knx.sensor because HA has the concept of dedicated binary_sensor - therefore it’s not listed in the sensor type table.
@finity these switches send payloads to preconfigured addresses on the KNX-bus mostly over dedicated twisted pair cables.
I see your point. It can be seen in an example
- type: 'binary'
entity_id: 'binary_sensor.kitchen_window'
address: '0/6/5'
I have the impression this can be improved. On this page
Is a link to here
There I miss the hint to binary type.
CONFIGURATION VARIABLES
type
(string)(Required)
Type of the exposed value. Either ‘binary’, ‘time’, ‘date’, ‘datetime’ or any supported type of KNX Sensor(e.g., “temperature” or “humidity”).
If you can think of a way to highlight it better please file a PR at GitHub - home-assistant/home-assistant.io: 📘 Home Assistant User documentation
Documentation improvements are always welcome!
OK, so the switches don’t have any real world output device connected to them? they are just used as an input to a “controller” of some sort and the controller then turns on the designated output for the real world device (light, etc)?
Yes kind of. There is no central controller for everything but every device on the bus reacts autonomously to its configured addresses.
So eg. a Dimming actuator can receive binary payloads to Turn on a channel and can send a binary telegram to a different address for the status of its channel.
Every switch that has this status group address configured can react to the status telegram - for status Leds or just to send the right binary payload when pushed next time (there is no concept for toggle - it’s always ON or OFF).
Same thing for temperatures, dimming percentage, color values, etc.
It’s actually a really nice and stable system but needs dedicated wiring so it’s more suited for new buildings or big renovations where these can get planned in from the start.
I’m also looking for a way to easily control Hue with KNX. The KNX Cookbook here in the forums also contains a solution but its quite big aswell.
In openHAB you can connect KNX to Hue in one configuration line with correct return status and working dimmer aswell.
I’m also coming from OpenHAB, despite the fact that OpenHAB is in many places complex to configure, the KNX/HUE Integration case is much simpler there. All the KNX / Hue Docs and CookBooks and also the Sample here are either complex or not known to work (as of above) the Samples in the cookbook have not the ver simple ON/OFF case. The Template Idea above seems to be very simple, but it ready as it would not work. @rak or does it? It would be nice to have a simple Example following a best practise pattern.
Did someone ever try the light template I suggested? It should do exactly what OP wants, light and switch are mirrored.
I am also looking for the most elegant and effective way to link KNX and HUE through HA.
I read a lot of topics here and the requirements of the users are not always to same (ie. some wants to use toggles, or even “stepped” ways to change brightness and colors as in the cookbook).
I am personally looking for a solution which would be as close as possible to the KNX way of linking GA to objects in light actuators.
So I used some automations to support turning on/off, defining a brightness value, and defining a color (DPT 232.600 - RGB or DPT 251.600 - RGBW), but also send feedback telegrams with the actual state of the hue light. This is my first attempt at HA scripting so do not hesitate to let me know if you see things which could be improved.
First the code and then some remarks :
fire_event: true
fire_event_filter: ["11/*/*"] # this GA range may vary for you
expose:
- type: 'binary'
entity_id: light.hue_light_1
address: '11/4/1' # this GA is used to feedback the state (ON/OFF) of the Hue light
- platform: knx
name: 'KNX to Hue Light 1'
state_address: '11/0/1' # this GA is used to switch the Hue Light ON/OFF
sync_state: False
- alias: "KNX to Hue Light 1 ON/OFF"
trigger:
platform: state
entity_id: binary_sensor.knx_to_hue_light_1
action:
- entity_id: light.hue_light_1
service_template: >
{% if is_state('binary_sensor.knx_to_hue_light_1', 'on') %}
light.turn_on
{% else %}
light.turn_off
{% endif %}
- alias: "KNX to Hue Light 1 VALUE"
trigger:
platform: event
event_type: knx_event
event_data:
address: '11/2/1' # GA to set the Hue brightness
condition:
- condition: template
value_template: '{{ (trigger.event.data.data != 0) }}' # Block read requests (which only send "0")
action:
- service: light.turn_on
data_template:
entity_id: light.hue_light_1
brightness: '{{ trigger.event.data.data[0] | int }}'
- alias: "KNX to Hue Light 1 COLOR"
trigger:
platform: event
event_type: knx_event
event_data:
address: '11/3/1' # GA to set the Hue color
condition:
- condition: template
value_template: '{{ (trigger.event.data.data != 0) }}' # Block read requests (which only send "0")
action:
- service: light.turn_on
data_template:
entity_id: light.hue_light_1
rgb_color:
- "{{ trigger.event.data.data[0] | int }}"
- "{{ trigger.event.data.data[1] | int }}"
- "{{ trigger.event.data.data[2] | int }}"
# Uncomment line below if you use DPT 251.600 - RGBW
# white_value: '{{ trigger.event.data.data[3] | int }}'
- alias: "KNX to Hue Light 1 FB VALUE"
trigger:
platform: state
entity_id: light.hue_light_1
action:
- service: knx.send
data_template:
address: '11/5/1' # this GA is used to feedback the BRIGHTNESS of the Hue light
payload:
- "{{ state_attr('light.hue_light_1', 'brightness') | int }}"
- alias: "KNX to Hue Light 1 FB COLOR"
trigger:
platform: state
entity_id: light.hue_light_1
condition:
condition: template
value_template: "{{ state_attr('light.hue_light_1', 'rgb_color') != None }}"
action:
- service: knx.send
data_template:
address: '11/6/1' # this GA is used to feedback the COLOR of the Hue light
payload:
- "{{ state_attr('light.hue_light_1', 'rgb_color')[0] | int }}"
- "{{ state_attr('light.hue_light_1', 'rgb_color')[1] | int }}"
- "{{ state_attr('light.hue_light_1', 'rgb_color')[2] | int }}"
# Uncomment lines below if you use DPT 251.600 - RGBW
# - >
# {% if state_attr('light.hue_light_1', 'white_value') != None %}
# {{ state_attr('light.hue_light_1', 'white_value') | int }}
# {% else %}
# {{'0'}}
# {% endif %}
# - 0
# - 15
You may wonder why I didn’t use the “Automation” for the ON/OFF trigger and state feedback, but rather the KNX “Binary Sensor” and “Binary Expose”. Here are the 2 reasons :
I did not figure out how to differentiate a knx event for writing 0 (turning off the light) and a “GroupValueRead”. So every time a KNX device would send a “read request” on the GA, the light would turn OFF.
By using the Binary expose, it is possible to use a read request from KNX to retrieve the status of the Hue light (I didn’t find an easy way to expose a state attribute to show the status of the brightness and color, so those 2 do not support read requests. I could have used some template for that but the code would be even more complex).
Regarding the color to be set, depending of what your KNX switch support, you may opt for the RGB or RGBW DPT (232.600 or 251.600). If you use the RGBW, you should un-comment the 2 lines in the automation yaml code.
I admit that it’s a lot of lines to perform something quite simple, and maybe solutions like this AppDaemon script by da-anda would be more useful, I still have to investigate it.
Anyway, for sure an easier way to connect those 2 technologies together would be great for HA users.
Nice!
You can try to define a template sensor for the brightness
- platform: template
sensors:
hue_1_brightness:
value_template: '{{ states.light.hue_light_1.attributes.brightness }}'
unit_of_measurement: '%'
Then you can expose this to Knx with value type “percent” and it should be readable from the bus.
Wow, that much code for one light. That’s a nightmare.
thanks for the tip @farmio, that would be possible indeed to allow the “read request” from KNX
@crazyfx1 I totally agree with you, it s a lot of code and HA should really have an easier way to perform such thing 
You may use only the ON/OFF part if you don’t need the reset
Maybe the Knx expose Code can be tweaked to not only expose the state but optionally an entity attribute (like brightness).
Edit: It can! see https://github.com/XKNX/xknx/pull/280
Hi i cant get this part to work
- alias: "KNX to Hue Light 1 ON/OFF"
platform: state
entity_id: binary_sensor.knx_to_hue_light_1
action:
- entity_id: light.hue_light_1
service_template: >
{% if is_state('binary_sensor.knx_to_hue_light_1', 'on') %}
light.turn_on
{% else %}
light.turn_off
{% endif %}
HA is complaining about the platform: state mechanism.
I think it is either missing a trigger or condition.
Couldn’t get it to work tough.
Can you point me in the right direction?
Regards.
Hi Hasmi,
Indeed I missed a line when posting the code here (the trigger)
I edited my post and it s now corrected
Regards,
Laurent
Hi.
Thanks that works now.
I can turn the HUE on/off using the Multi Switch.
Now i maybe got something wrong in ETS5 tough.
I connected the Brightness SET and State Adresses to a Dimm Step, but it won’t start to dimm up or down.
Kind of hard to explain but did you also connect the SET Brightness and State Brightness Addresses to one Dim Step in ETS?
Did you have to use the template like farmio suggested or are you still using the config as stated above?
Regards.
My script does not let you dim up or down unfortunately, only to set a specific brightness value to the hue like “50%”. I didn’t figure out how to DIM up/down yet
Brightness in a Knx device is meant to be in percent (0-255 in this case - as it is used in HA)
Stepwise Dimming - DPT3 - is not supported by xknx. You may be able to find a workaround, but I have never tried it and it may break in the future.
Maybe this is interesting for those of you with knx wall switches and deconz: