KNX Data Secure: sporadic “cannot decrypt telegram” since Home Assistant 2026.x

[sammawatt]

Summary

After upgrading from Home Assistant 2025.x to 2026.1.x, a sporadic KNX Data Secure error appears.
The same ETS project, devices and keys worked reliably for months on Home Assistant 2025.x.

The problem affects only a single group address and does not occur on every telegram.

Exact error message

Telegramme für Gruppenadressen, die in Home Assistant verwendet werden,
konnten nicht entschlüsselt werden, da die Data Secure-Schlüssel fehlen
oder ungültig sind:

9/7/2 from 1.2.12

Key observations

The error occurs exclusively for group address 9/7/2.
Other group addresses of the same device (9/7/0 and 9/7/1) are not affected.

Most secure telegrams from the device are decoded correctly.
The error is sporadic and not reproducible on every send.

The issue can occur hours or days after the last Home Assistant restart.
No YAML reload, ETS programming or Home Assistant restart is required to trigger it.

Re-importing the knxkeys file clears the warning temporarily, but it reappears later.

Affected KNX device (Data Secure)

Manufacturer: Lingg & Janke
Device: L&J Secure Water Meter KWZC
Order number: KWCZ-SEC
Device type: F002
Application: SEC Wasserzähler KWZV F002-30
Application version: 3.0
KNX Data Secure: enabled
Physical address: 1.2.12

Communication objects:

• GA 9/7/0 – Water meter total (m³) – no issue
• GA 9/7/1 – Water meter request – no issue
• GA 9/7/2 – Water meter high-resolution value (liters) – issue occurs only here

(Except for the IP Interface there are no other secure devices on my ETS-project yet))
The device sends telegrams cyclic every 1800 seconds and additionally on value changes.

Other KNX devices (context)

Home Assistant is connected via an Enertex KNX IP Secure Router.
No other KNX devices are involved in this issue.

KNX / ETS environment

ETS version: ETS Professional 5.7.7 (Build 1428)
The ETS project has not changed since Home Assistant 2025.x.
The knxkeys file was freshly exported after full device programming and imported into Home Assistant.

Home Assistant environment

Installation method: Home Assistant OS
Core: 2026.1.2
Supervisor: 2026.01.1
Operating System: 16.3
Frontend: 20260107.2

Previously working version: Home Assistant Core 2025.x

Steps to reproduce (best known)

Run Home Assistant version 2026.1.x or newer.
Let the KNX Secure water meter operate normally.
After some time (hours or days), a secure telegram for group address 9/7/2 triggers the error.

The issue does not require a Home Assistant restart, YAML reload, ETS changes or key changes.

Actual behavior

A single secure telegram on group address 9/7/2 triggers a persistent repair notification.
The warning reappears even after re-importing the knxkeys file.
This behavior started with Home Assistant 2026.1.x (skipped versions after 2025.x)

Additional notes

This looks like a regression or stricter handling in KNX Data Secure decoding since Home Assistant 2026.1.x, possibly related to specific secure frame types or payload handling for high-resolution values.

Debug logs can be provided if required.

Greetings
Alex

[farmio]

Hi 👋!
Thanks for the detailed report!

The repair issue for undecodable data secure telegrams was introduced in 2026.1 so previously those would probably go unnoticed (except for logs I think).

You can have a look at the time the issue was created and see if you find the according telegram in the group monitor (maybe also check ETS group monitor for it).

Also have a look at the logs if there are some secure related messages. If not, try to set the log level for xknx.data_secure to debug. See https://www.home-assistant.io/integrations/knx/#logs-for-the-knx-integration

[sammawatt]

Hi,

could not find the error in the logs (might be deleted since its from yesterday?

The repair message does not show the exact time ("yesterday" for example). Also it is very difficult to catch the telegram, the error occurs after hours or even days.
As I understand the group monitor in HA is limited.

I uploaded again the knxkeys file (error vanished) and entered xknx.data_secure: debug to the configuration.yaml and rebootet.

If that doesn't show enough, I will run the ETS monitor for a few days and hope it doesn't crash (I really pray for a linux portation of ETS)

Greetings from Germany
Alex

[farmio]

The repair message does not show the exact time ("yesterday" for example)

Hm, maybe have a look at the issue registry file in .storage. You'll probably find a decent timestamp there.

the group monitor in HA is limited.

You can increase the limit to 25k telegrams in the integration settings. But I'm not sure if a telegram triggering such a repair would land there. It might be a safer bet to let ETS run and capture for a day.

I uploaded again the knxkeys file (error vanished)

Yes, uploading a new keyfile deletes the repair issue.

(I really pray for a linux portation of ETS)

(lol)

[sammawatt]

Hi,
after 3 days I got the error again.

There is one entry in the logs:

Logger: xknx.data_secure
Quelle: runner.py:289
Erstmals aufgetreten: 17:08:17 (3 Vorkommnisse)
Zuletzt protokolliert: 17:08:17

Could not decrypt CEMI frame: Sequence number too low for 1.2.12: 253614142278 received, 253614142278 last valid

Text in repair message is the same as ever:

Telegramme für Gruppenadressen, die in Home Assistant verwendet werden, konnten nicht entschlüsselt werden, da die Data Secure-Schlüssel fehlen oder ungültig sind:

9/7/2 from 1.2.12

Um dieses Problem zu beheben, aktualisiere die Konfigurationen der sendenden Geräte über ETS und stelle eine aktualisierte KNX-Schlüsselbund-Datei bereit. Stelle sicher, dass die in Home Assistant verwendeten Gruppenadressen der von Home Assistant verwendeten Schnittstelle zugeordnet sind (1.0.8als das Problem zuletzt auftrat).

Yaml settings of sensor:

• name: "ELW Wasserverbrauch Liter"
  state_address: "9/7/2"
  state_class: total
  device_class: water
  type: volume_liquid_litre
  sync_state: init

I captured the exact moment (17:08) in the history graph. As you can see, data ist coming in normaly after that.

[farmio]

Great! See this

Sequence number too low for 1.2.12: 253614142278 received, 253614142278 last valid

You received a telegram with the same sequence number twice. This is a sign for a replay attack - or, more probably, a bug in the devices firmware.

From KNX specifications 3.0.2 - 03_03_07 Application Layer v02.01.01 AS

I'd recommend to do a bus log (from ETS or maybe a Gira Router if you have one) and contact the devices manufacturer with it.

[MG-PL-MG]

Since I have the same issue and with similar cause I wonder if there can be kind of „ignore” action added to be used as alternative to a need to constantly upload KNX keyring file over and over again?

[farmio]

@MG-PL-MG do you have this issue with the same device / manufacturer?

I'll need to look if there is an option to ignore such an issue. Otherwise you can just stop uploading keyrings and ignore (like in your mind) the issue - it doesn't change anything for runtime communication.

[MG-PL-MG]

I have issue the different device simple switch but also on single group address while all other addresses form the same device report no issues. Ignoring the issue is not that easy as it keeps showing on system settings as problem to repair

and stays there until keyring file is uploaded.

[farmio]

@MG-PL-MG

on single group address while all other addresses form the same device report no issues

are you sure that your address is properly associated with your IP interface and all devices are updated via ETS?
Do you see the same log message as above?

Could not decrypt CEMI frame: Sequence number too low for (...)

What device is it?

[sammawatt]

As you can see in my initial message:
With my device it's the same, only one address shows the error, GA 9/7/0 for example (m³) works without issue while GA 9/7/2 reports a serror every few days (the device only sends when the value changes, and that only happens in the morning or after 16:00, so very few telegrams anf therefore error after days)

[farmio]

@sammawatt I have contacted Lingg-Janke about that. It seems that their devices do indeed re-use the sequence number when a telegram wasn't ACKed on TP. This should - in theory - be fine as, when there was no ACK, no device has ever seen that telegram. But it looks like we did see it - and also the repeated one.
So I guess, have a look at if and why there are repeated / un-ACKed telegrams on your line. Maybe there is some issue with a coupler setting or something like that.

[skibbi]

Does it really make sense to display the repair issue in these cases? Because repeated sequence numbers won't be repaired by re-uploading the keys. If it is really the same sequence number it's probably not an encryption related problem. More probably missing ACKs or a loop.

[farmio]

@skibbi Currently every DaraSecure exception triggers the repair issue. Nobody expected that there are devices sending the same sequence number twice - as it doesn't comply with Knx specs.

it's probably not an encryption related problem. More probably missing ACKs or a loop

It could just be a replay attack.
Loops are not a thing in a working Knx topology. Same for missed ACKs - if we received the telegram over IP, there should have been an ACK at least from the IP interface.

Anyway, imho the repair issue always points to some issue in the installation or topology. But that's unfortunately not always fixed by uploading a new keyfile (alone).