Hager 80660100 doesn't take DateTime with source_reliable bit set to 1

[r4nt]

If I send a DateTime with source_reliable set to false, which leads to 0x80 in the last byte, the Hager devices take date and time.
If I send a DateTime with source_reliable set to true, which leads to 0xC0 in the last byte, the Hager devices do not update.
When using home assistant's "expose" interface, by default source_reliable is set to true.
I've created my own workaround automation that sends the DateTime without source_reliable so I have a workaround.

I don't have access to the KNX spec, so I don't know whether this is an optional feature or needs to be supported by all devices.
I did not find a way to set the source_reliable bit from ETS 6, so Hager is pushing back.

Not sure whether this is an issue in xknx or a problem of the implementation of the Hager devices.
I'd be curious whether somebody with access to the KNX spec can shed some light on this issue that I can use to link in an email to Hager folks.

Thanks for all the great work!

[farmio]

Hi 👋!

The full KNX specification (at least the 2.1 version) can be found at https://my.knx.org/de/shop/knx-specifications?product_type=knx-specifications . All you'll need is a (free) my.knx.org account.
The part you are looking for is also accessible without an account here: https://support.knx.org/hc/en-us/articles/15392604906514-Interworking-Datapoint-types

Imho setting the source_reliable bit is right way according to the specs. I'd understand to ignore unreliable sources, but ignoring reliable for local time is kind of awkward 😬

[r4nt]

Thank you so much for the links, I do not know how I wasn't able to find those. Given the spec this is clearly a problem on the device side, and I'll push it a bit before just relying on my workaround :) Thank you so much for the quick turnaround, xknx is literally making a difference in my life!

[r4nt]

Ok, re-opening after finding this in the notes of the spec:
"
Note 15
Bit 7 of the octet 1 is used for “Quality of Clock” bit (CLQ). The other bits of this octet are reserved for
future extensions. Their values shall be 0. If this Datapoint Type is used for transmitting data, transmitters
shall set the lower 7 bits to 0. Receivers shall check these bits to be 0.
This bit is called “Quality of Clock” (CLQ).
"

Especially "receivers shall check these bits to be 0" - is this a leftover from a previous spec where there was no bit 6? Requiring receivers to check seems to go against the idea of backwards-compatible extension mechanisms?

[farmio]

Oh right, that odd. Even in the schema this bit is denoted "reserved".

Do you want to open a ticket at KNXA to ask what that's exactly about? If not I'll do.

[r4nt]

I've never done this, so I'd appreciate if you'd do it - if you don't have time, let me know, and I'll try my hand at this.

[farmio]

No problem, if you are interested, I can set you cc (would need e-mail).

[r4nt]

Thanks (I looked and didn't find a way to file a bug :,)

Email is klimek at box4 dot net.