Hi Darren, today I had to go back into the topic of KNX datatype decoding and I compared the values on the network with what I was seeing on the console. You were right. For some coincidence the floating point value offsetted by 8 bits still produced a sensible output.
Problem was that I only gobbled up the parts of the first byte for values that were less than 6 bits. Had to change that to a bit more complex solution. Now the xslt added a lot of "[reserved uint 8 '0x00']" entries for the 8-bit aligned values. Now I think this should be fixed and the values I can see are way more sensible, than before ... please give it a test-drive. Chris -----Original Message----- From: Sebastian Rühl <[email protected]> Sent: Montag, 7. März 2022 11:15 To: [email protected] Subject: Re: KNX: DPT_Value_Temp aka that 16-bit float with 'special' encoding Hey Darren, you can find a example here: https://github.com/apache/plc4x/blob/develop/protocols/bacnetip/src/main/resources/protocols/bacnetip/bacnetip.mspec#L1262 and here: https://github.com/apache/plc4x/blob/develop/plc4j/drivers/bacnet/src/main/java/org/apache/plc4x/java/bacnetip/readwrite/utils/StaticHelper.java#L38 - Sebastian On 2022/03/03 23:36:21 Darren Everley wrote: > So I've been doing some further digging around to try and understand > more about the MSpec code generators and I think my initial feelings > about how to tackle this issue has evolved. > > I'm now thinking about modifying the XSLT to generate a different > MSpec file that will change the type of the 16-bit float from this: > > ['DPT_Value_Temp' REAL > [simple float 16 value] > > ] > > to something more like this, once I understand what needs to go into > the expressions.... > > ['DPT_Value_Temp' REAL > [manual float 16 value '{serialization-expression}' > '{deserialization-expression}' '{length-expression}'] > > ] > > So now my plan is to dig around for some examples of manual field type > definitions and seek inspiration. If anyone has any interesting/useful > examples thereof that thye would like to point me at them I'm all ears. > > Darren > > > On Tue, Mar 1, 2022 at 11:21 PM Darren Everley < > [email protected]> wrote: > > > Hey Chris, > > > > When I say two implementations; what I mean is that the KNX spec has > > two distinct 16-bit float formats, used seemingly by different > > equipment vendors (!!?!). So we need a discriminator to route to the > > appropriate decoding method. One of these is KNX specific as far as I'm > > aware. > > > > For example in the following sample of generated code, the generated > > readFloat method needs to be able to discriminate the correct > > underlying data type, one of which is like I said; KNX specific. > > > > } else if (EvaluationHelper.equals(datapointType, > > KnxDatapointType.DPT_Value_Tempa)) { // REAL > > > > // Simple FieldA (value) > > Float value = /*TODO: migrate me*/ /*TODO: migrate me*/ > > readBuffer.readFloat("", 16); > > > > return new PlcREAL(value); > > } > > > > > > So I believe a the tasks required to get this done are as follows; > > > > 1. update to the XSD that generates the MSpec (is that correct?). > > XSD is not really my forte, so perhaps you could help here? > > > > 2. update needs to be made to the parseFloat method of > > ReadBufferByteBased to handle the additional KNX format. This smells > > bad, as this is KNX implementation details leaking into common code. > > So any thoughts you have on how to tackle this would be helpful? > > Perhaps this type of issue has been encountered on other protocols > > and there is an existing pattern to be replicated? I will then be > > able to go ahead and implement the necessary changes. > > > > 3. then 'finally' the Freemarker template for java code generation > > (data-io-template.java.ftlh) will need to be updated to 'route' to > > the appropriate 16-bit float format as implemented in the step > > above. I will take care of this also. > > > > > > I hope all that makes sense for a relatively late night brain dump! > > > > All the best > > > > Darren > > > > > > > > > > > > On Tue, Mar 1, 2022 at 11:00 PM Christofer Dutz > > <[email protected]> > > wrote: > > > >> 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 > >> > >> > > > > > > > > -- > *Darren Everley - Director* > > *Email: *[email protected] *| Mobile:* 07891405262 *| > Website:* www.xeropoint.co.uk > *Company: *Xeropoint Ltd. Registered in England and Wales. 11101907 > *Address:* Henleaze House, Harbury Road, Bristol, BS9 4PN >
