KNX Cookbook

Community Guides
, ,
444

@farmio They explained to me that to make the addresses normal they will have to delete all the objects created and create new objects with the normal addresses. They explained to me that it takes 2 days of work. Once the object has been created and saved, it is no longer possible to change the KNX address. That’s what they told me. It is true?

445

I have no idea :person_shrugging: don’t know anything about that specific device.

446

Hope this is the right place to ask the following:

Is there a way to directly log ALL KNX telegrams from HA to influxdb?
I have seen that sensor etc. values can be easily transferred, but what about the “raw” KNX data (source, destination, payload, dpt, APCI, prio)?

I have found a way through Node-Red (https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/1849843-logging-protokollierung-im-docker?p=1850266#post1850266).

Ultimate goal is to build a KNX bus monitor in Grafana.

Thanks for any hints

447

Unfortunately DPT isn’t part of raw telegram data.
Priority isn’t exposed to HA. And so aren’t any APCI other than GroupValue*.
So from HA you could build a Group monitor, but not a Bus monitor.

If you can manually write to Influx (from a service) you could use knx_event (listening on address: *) or better yet, a KNX Interface Telegram device trigger (with no address set) as trigger in an automation.

448

Thanks, I’ll dig into this and report back.
And I guess I’ll need to read the KNX specs, still much to learn.

449

If anyone isn’t familiar with “KNX Interface” Telegram device triggers yet, I made a short video on how to use them to trigger HA actions from Knx telegrams :tv: :smiley: https://youtu.be/O3p3dISvTtI

3 Likes
450

Thanks! Just wondering, does it give any more capabilities than using state triggers from entities provided by knx integration?

451

Well technically, yes. It does provide source and telegram type (write / read / response) etc. but I don’t think that will be needed very often in automations.

The one thing is that you don’t need entities (like knx_event). So it can be used for DPT 2 or 3 (or any other using raw payload). And it also triggers on repeated similar payloads (unlike state_changed).

1 Like
452

Great, thanks!

453

@Jpsy thank you very much for this great guide! It helpf me to control my hue lamps with my Glastaster switch.

I still struggeling with the state and maybe someone has an idea how to fix it.

I have to buttons on my switch. On toggle between 0%, 50% and 100% for the brighness and the second button toggle between 0% and 100% to switch between to colours.

ETS

image
image1892×141 21.5 KB

KNX

sensor:
  - name: "Schlafzimmer Helligkeit"
    state_address: "1/3/30"
    type: "percent"
  - name: "Schlafzimmer Farbe"
    state_address: "1/3/31"
    type: "percent"

expose:
  - type: percent
    entity_id: light.schlafzimmer
    attribute: brightness_pct
    default: 0
    address: "1/3/30"

Automatisation for turn_on

alias: Hue Schlafzimmer Einschalten
description: ""
trigger:
  - platform: state
    entity_id: sensor.schlafzimmer_helligkeit
condition:
  - condition: template
    value_template: "{{ (float(trigger.to_state.state) > 0) }}"
action:
  - service: light.turn_on
    data_template:
      entity_id: light.schlafzimmer
      brightness: "{{ (float(trigger.to_state.state) * 255 / 100) | round(0) }}"
mode: single

Automatisation for turn_off

alias: Hue Schlafzimmer Ausschalten
description: ""
trigger:
  - platform: state
    entity_id: sensor.schlafzimmer_helligkeit
    to: "0"
condition: null
action:
  - service: light.turn_off
    entity_id: light.schlafzimmer
mode: single
initial_state: "on"

Automatisation for brightness

alias: Hue Schlafzimmer Farbe Hell
description: ""
trigger:
  - platform: state
    entity_id: sensor.schlafzimmer_farbe
condition:
  - condition: numeric_state
    entity_id: sensor.schlafzimmer_farbe
    below: 100
action:
  - service: light.turn_on
    metadata: {}
    data:
      kelvin: 2800
    target:
      entity_id: light.schlafzimmer
mode: single
initial_state: "on"

Automatisation for colour

alias: Hue Schlafzimmer Farbe Rot
description: ""
trigger:
  - platform: state
    entity_id: sensor.schlafzimmer_farbe
condition:
  - condition: numeric_state
    entity_id: sensor.schlafzimmer_farbe
    above: 0
action:
  - service: light.turn_on
    metadata: {}
    data:
      rgb_color:
        - 255
        - 0
        - 0
    target:
      entity_id: light.schlafzimmer
mode: single
initial_state: "on"

I can switch the light on, toggle between the brighness and colour with the hardware switch and also with HA. But when I use HA, the state is not synced with the Glastaster hardware switch.

454

Hi,
I am sorry if this has already been asked before but I couldn’t find anything related to the particular question I have when using the search function.

I want to be able to detect a KNX device failure and therefore try making the device send cyclic telegrams and have Home assistant monitor them. I am looking for the recommended way on how to do that on the Home assistant side.

So far I found that I can use a binary_sensor for this if I set its configuration parameters ignore_internal_state to true, invert to true and reset_after to a desired time of my choice, like this :

knx:
  binary_sensor:
    - name: "Test - Alarm ok"
      state_address: "1/2/12"
      sync_state: init
      ignore_internal_state: true
      reset_after: 1500
      invert: true

This results in a sensor which always stays on as long as the cyclic telegrams are coming in and goes to off as soon as the cyclic sending of telegrams stops (or a telegram raises an alarm obviously).

My question is, is this the recommended or intended way to do this? Can I implement cyclic monitoring with the KNX integration like this or is there a downside to my implementation?

1 Like