DPT 10.001 is wrongly parsed when "no day" is present

[kgoderis]

There is an issue with

https://github.com/calimero-project/calimero-core/blob/4acfe93cebd4149fc7ac25d5810e534e001cd62a/src/tuwien/auto/calimero/dptxlator/DPTXlatorTime.java#L337

when it is fed a 3 byte buffer with the no day set to 0. After shifting the buffer, day == 0, and therefore, "no day" will never be selected from the dow HashMap, hence returning a String which is not correct

For example, I have a device sending data like this:

which is correctly fed into DPTXlatorTime

which ultimately yields

I would expect "no-day, 00:00:10" as a result

[bmalinowsky]

The "no-day" encoding makes the day field optional for that dpt, because many time sources in knx don't have a notion of day-of-week. It doesn't mean or require to literally print it. There is also a method Optional<DayOfWeek> dayOfWeek() which exactly reflects that. It is still parsed from string input, though.

[kgoderis]

Ok, but in fact, within openHAB, which you know if I am not mistaking, we expect this no-day string to be present in order to correctly parse the string back to something meaningful

Nu you agree that because of day == 0 that the no-day part will never be included in the resulting string?

Sent from my iPhone

On 12 Jun 2022, at 15:23, bmalinowsky @.***> wrote:

 The "no-day" encoding makes the day field optional for that dpt, because many time sources in knx don't have a notion of day-of-week. It doesn't mean or require to literally print it. There is also a method Optional<DayOfWeek> dayOfWeek() which exactly reflects that. It is still parsed from string input, though.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.