Hi Darren, I have also noticed that my original implementation doesn't accrually work. So we need to generally fix this. I don't think we need two alternative implementations, but we need to fix the one we have :-)
If you've got an idea on how to do that, I'm Haus to help. Chris Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg> ________________________________ From: Darren Everley <[email protected]> Sent: Tuesday, March 1, 2022 11:40:18 PM To: [email protected] <[email protected]>; Christofer Dutz <[email protected]> Subject: KNX: DPT_Value_Temp aka that 16-bit float with 'special' encoding Hi Chris/All, I've been digging around in the KNX code generation areas for the aforementioned data type; DPT_Value_Temp and it's brethren. So I can see how the code generators work by driving a 16-bit float to be decoded as a 'half-precision' IEEE value, via the readFloat method of the ReadBufferByteBased class. Now, with this additional and alternative 16-bit float implementation needing to live alongside the existing, perhaps it's best to have a discussion on the most prefered approach for handling this as it seems, from my fresh and naive perspective, that changes need to be made to the ReadBufferByteBased class and this will affect a whole bunch of other modules. As always, I'm more than happy to make the required changes here, but would like some advice from the more experienced developers on this project before wading in. Many thanks Darren
