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
>
>
