Knx.telegram condition template works with payload but not value

Configuration
1

When using knx.telegram as trigger and the condition for it to be 0 will for some reason not work with trigger.value but does work with trigger.payload
From the trigger message i can see its an actual 0 or 1 its receives and not a string.

This will always render False

triggers:
  - trigger: knx.telegram
    destination: 9/4/0
    group_value_read: false
    outgoing: false
conditions:
  - condition: template
    value_template: "{{ trigger.value == 0 }}"

But this one works:

triggers:
  - trigger: knx.telegram
    destination: 9/4/0
    group_value_read: false
    outgoing: false
conditions:
  - condition: template
    value_template: "{{ trigger.payload == 0 }}"

The example given in KNX - Home Assistant is with trigger.value

Trigger:

variables:
  trigger:
    id: "0"
    idx: "0"
    alias: null
    destination: 9/4/0
    destination_name: ""
    direction: Incoming
    dpt_main: null
    dpt_sub: null
    dpt_name: null
    payload: 0
    source: 1.1.223
    source_name: ""
    telegramtype: GroupValueWrite
    timestamp: "2025-04-03T12:57:20.618814+02:00"
    unit: null
    value: null
context: null
2

You can always just check the value in the automation editor directly (when it fires), automation traces debugger or just in HAs group monitor.
Usually DPT 1 has string values like “off” or “active” depending on the DPT read from the imported project file. If you don’t have imported a project, or the GA isn’t included, value will always be null - like shown in your example.

TLDR: for DPT 1, just use trigger.payload. It’s more resilient.

1 Like
3

:man_facepalming:
But good to know i need to import the KNX for that to work with trigger.value
Will use trigger.payload as i just need a few triggers.

Also i need some new reading glasses :sob: Thnx

1 Like
4

Yeah, for DPT 1 payload is straightforward.

For things like DPT 9, not so much… there value is the better choice. You can also configure the trigger with type to get a value - in case you don’t have a project file or you are working on a blueprint (and thus don’t know if users have one).

5

type: binary is not in the allowed list for knx.telegram
Worth it to add that in a new version? That way my automations would be uniform.

6

“binary” in expose is used for the other way: HA → Knx there is no “value” needed as the HA state is converted to a payload directly.

There are >20 different DPT 1 types, so “binary” alone wouldn’t suffice. See https://github.com/XKNX/xknx/blob/b304ee76868ca93a564cee59bad065364e453b2d/xknx/dpt/dpt_1.py

If you think it is, feel free to do so. I’m happy to review PRs for Knx.

7

What info should i provide in a PR? I take it i should go here: Pull requests · XKNX/xknx · GitHub
Should i provide code? where do i need to look?
Sorry for all these basic questions, but better be safe then sorry.

Also now that you pointed me to that list, adding type: switch lets me use off in trigger.value

Thanks again, i think i will look at the doc and suggest an edit for the KNX types so they include the DTP1.x types KNX - Home Assistant

8

Oh well, then it seems it’s already supported :grinning: didn’t know that.

Great! Just be aware that these are not usable as sensor types, so it would need proper distinction (extra list or something like that) to avoid confusion.