KNX - scenes - scene number issue

Configuration
1

Hi,

I have defined a KNX scene as follows:

  - name: "Gardenlights - scene 1"
    address: 3/2/0
    scene_number: 7

This is the same scene number (7) as when I would press my Gira Tastsensor:

image
image812×234 7.42 KB

However, when I look to my group monitoring, the value that Home Assistant is sending is actually different than what my Gira TS (or OpenHAB for that matter) is sending:

image
image1486×85 13.6 KB

So what am I doing wrong?

2

HA seems right to me (but I may be biased :rofl:). ETS has the same opinion. Just as the DPT specifications say. See https://www.knx.org/wAssets/docs/downloads/Certification/Interworking-Datapoint-types/03_07_02-Datapoint-Types-v02.02.01-AS.pdf
Raw $06 (0x06) → scene number 7

The other devices do send scene number 8.

I wonder what the Gira device sends for a value 1 or 64. If 64 yields a 0x41 that would actually be a “save scene 1” telegram.

3

Hi Mathias,

Thanks for your quick response. So let’s assume HA is right. :wink:

It seems to read the KNX bus differently than sending scene numbers to the bus. Let me explain.

I have created an automation that should kick in when my Gira Tastsensor is calling scene number 7:

- id: '1674122732129'
  alias: Scene - Vijververlichting - Uit
  description: ''
  trigger:
  - platform: event
    event_type: knx_event
  condition:
  - condition: template
    value_template: "{{ trigger.event.data.destination == '3/2/0' and\n   trigger.event.data.data[0]
      == 7 }}\n"
    enabled: true
  action:

This automation is working as I expected. Meaning, it interpretes the scene numbers in the same way as the Gira TS.

Doesn’t that imply that Home Assistant is not consistent? I would expect this automation not to work.

Full KNX event log in HA:

event_type: knx_event
data:
  data:
    - 7
  destination: 3/2/0
  direction: Incoming
  value: null
  source: 1.1.65
  telegramtype: GroupValueWrite
origin: LOCAL
time_fired: "2023-01-19T10:07:38.741790+00:00"
context:
  id: 01GQ4QZ47N87Q67BKKC7K7RRFB
  parent_id: null
  user_id: null```
4

trigger.event.data.data of a knx_event is raw data. Raw data of a “scene number 7” is a list with one item: [6,] (see the link I posted above). So trigger.event.data.data[0] is an integer 6 if coming from HA. Your Gira device sends a raw 7 so it matches your current trigger.

If you want to use decoded values in knx_event you can specify the decoder in your configuration.yaml

knx:
  event:
    - address:
        - "1/3/2"
      type: "scene_number"

and then use trigger.event.data.value instead of trigger.event.data.data. This will yield a number, not a list of integers.
(That is especially useful if you use knx_event for float like DPT 9)

5

Hi Mathias,

Thank you for your reply.
So my KNX devices (such as Gira) and OpenHAB are working with raw data (‘7’) whereas HomeAssistant is working with decoded data.

Since I can’t change the behaviour of my KNX devices (it’s much more than just my Gira TS), I’m considering to adjust my Home Assistant scene numbers. I’ll do some trial-and-error but I believe that defining scene number “8” in Home Assistant actually gives me the raw “7” I am looking for.

Or do you have a better workaround?

6

Yes exactly. Scene number 8 is raw 7. As you see it in the ETS Log.
It’s really just raw + 1 (as you see in the link).

7

Ok, workaround implemented!

Some final words… I’m not saying Home Assistant is wrong, but to “increase compatibility”, another attribute (e.g. “scene_number_raw”) could be added. It could avoid confusion for those who are managing scenes in both HA and in KNX devices.

 - name: "Gardenlights - scene 1"
    address: 3/2/0
#    scene_number: 8
    scene_number_raw: 7
8

For sensors, knx.send, events etc. you can always use “1byte_unsigned” (or just 5).

If you manage scenes in Knx, imho the current notation should always be used. To avoid confusion KNXA has explicitly written that down in their KNX specifications.
Unfortunately not all device applications are implemented properly.

We generally try to stick to the specifications as close as we can and avoid implementing workarounds for bugs or proprietary features of single devices to keep good maintainability lower technical dept.

9

Fair point. Anyway, thanks for you help!

1 Like
10

So… since I also have one “Gira Tastsensor 3 Komfort 3-fach” in my Installation I gave this a try. Configuring Scene number 7 does yield a raw 6 on the bus. No matter if I use “with storage function” or “without…”. :woman_shrugging:
I use Application version 1.1 (10D711)

11

That is very strange. I wouldn’t even know where to look to see why the behaviour on my side is different than on your side.

I have the same application version.

Hold on… mystery solved. Aargh. I feel so stupid now.

So my OpenHAB (which I’ve set up in 2017 in my defense) is wrong. Apparently, OH wasn’t following the DPT specifications. And I fixed it (so it seems) by substracting 1 from the scene number as defined in my Gira TS.

When setting up HA, I was copying over from OpenHAB, instead of looking directly at the KNX config in ETS. While troubleshooting, I was assuming that OH and my KNX devices were in sync (“because they both work”) and since I have many scene numbers I didn’t realize that scene number 7 matches scene number 6 in my ETS (and 7 also exists there).

Long story short:

  • Home Assistant is 100% correct - but I believe your from the start. :wink:
  • My KNX devices (Gira,…) and ETS is 100% correct;
  • My OpenHAB instance is wrong;

Thanks for taking the time to check your Gira TS. It triggered me to have that one extra check as well.

1 Like