Connecting a switch from one technology (e.g. KNX) with a light in another technology (e.g. hue)

Hi guys,

I recently switched to HA comming from OH. I had a steep learning curve the last days. I am impressed about what can be achieved with HA and lovelace. I still struggle with some key concepts and I lack experience how to solve those efficiently. Thus my question …

How to “connect” a switch from one technology with a light in another technology.

I have a KNX switch switch.knx which I want to use for turning on/off a hue light light.hue. Should be a common problem one might have. A switch in one technology and a light in another.

The way which works for me is defining a set of automation.

[configuration.yaml]

...
automation:
- alias: "KNX-HUE Link On"
  trigger:
    - platform: state
      entity_id: switch.knx
      to: 'on'
  action:
    - service: light.turn_on
      entity_id: light.hue

- alias: "KNX-HUE Link Off"
  trigger:
    - platform: state
      entity_id: switch.knx
      to: 'off'
  action:
    - service: light.turn_off
      entity_id: light.hue

...

Is this how it’s supposed to be?

The above works currently, but has some flaws.

  • A lot of code reqruied on different positions in the configuration file (switch/light/automation).
  • Someone turns on the HUE lamp via the HUE app. I want the KNX swtich to be set accordingly. This is not working with the above.

Is the HUE-KNX link done via another set of two rules for HUE-KNX direction? Do I create a race condition (KNX triggers HUE, triggers back KNX, triggers back HUE, …).

Can this be done simpler/better?

I thought of a template switch.

[configuration.yaml]

...
switch:
  - platform: template
    switches:
      hue_knx:
        value_template: "{{ is_state('switch.knx', 'on') }}"
        turn_on:
          service: light.turn_on
          data:
            entity_id: light.hue
        turn_off:
          service: light.turn_off
          data:
            entity_id: light.hue
...

If I read the above I exepect switch.hue_knx and switch.knxshould be always in sync. And turning on either switch will turn on/off the light. Right?

Wrong. If you turn on switch.knx, it turns on switch.hue and vice versa, but not the light.hue. I dont uderstand why.

If you turn on switch.hue_knx it turns on the light but obviously not the switch.knx. One might be able to solve this with running two services.

If this is a silly question I appretiate some help in enabling me to imrove my search skills in this forum … . Thanks.

Talk to you soon.
Ralf

Get rid of this app :slight_smile: Once I created a nice interface for home assistant, my wife stopped using the Hue app.

For the rest a light template may be what you need.

try exposing the state of the hue light to a state-group-address of your knx switches.

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

Alternatively use an automation with the light as trigger and set the state of the switch as action.
see Switch or binary sensor exposed to KNX bus - #15 by stoffus (but I’d avoid the knx.send service)

A very different approach would be to try to just toggle the lights instead of turning them on or off. I personally have not tried it but it might work

automation:
- alias: "Test Toggle"
  trigger:
    - platform: state
      entity_id: binary_sensor.knx_your_sensor
      # to: 'on' # omit the "to" to react to all state changes
  action:
    - service: light.toggle
      entity_id: light.hue

I’d use a binary_sensor instead of a switch device then and configure sync_state: False for it to avoid hourly syncronisation - the light would probably toggle then.

1 Like

I don’t use KNX so I needs to ask some questions.

I assume the KNX switch is a physical switch that you can walk up to in the real world and mechanically turn on/off?

If that’s true then what does that mechanical switch control? where does the switch output go?

The switch has an LED and shows the state of the knx adress.

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 :

  1. You need to activate the “fire_event” in the knx configuration and specify the GA range which will be used for all the control commands of the Hue lights.
    You should also expose the state of the Hue light to KNX
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
  1. Create a KNX binary sensor through which we will switch the state of the Hue ON/OFF
- 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
  1. Edit the automation yaml file to set brightness, color, and receive feedback about the light state
- 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 :

  1. 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.

  2. 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 :stuck_out_tongue: 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.