Re: KNX: DPT_Value_Temp aka that 16-bit float with 'special' encoding
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 <
darren.ever...@xeropoint.co.uk> 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
> 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
>> --
>> *From:* Darren Everley
>> *Sent:* Tuesday, March 1, 2022 11:40:18 PM
>> *To:* dev@plc4x.apache.org ; Christofer Dutz <
>> christofer.d...@c-ware.de>
>> *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: *darren.ever...@xeropoint.co.uk *| Mobile:* 07891405262 *| Website:*
www.xeropoint.co.uk
*Company: *Xeropoint Ltd. Registered in England and Wales. 11101907
*Address:* Henleaze House, Harbury Road, Bristol, BS9 4PN
Re: [DRAFT] March PLC4X board report
+1 Am Do., 3. März 2022 um 11:11 Uhr schrieb Christofer Dutz < christofer.d...@c-ware.de>: > Had to hand write this one ... seems the report generator is currently > defective, but as we reduced the numbers in the report anyway, it wasn't > too much additional work ;-) > > > > I did ad a bit mor personal part to the Community health part as I think > the board should be aware of it. > > > > If I don't see any objections, I'll submit this in a few days. > > > > > > > > > > ## Description: > > The mission of the Apache PLC4X project is creating a set of libraries for > communicating with industrial programmable logic controllers (PLCs) using a > variety of protocols but with a shared API. > > > > ## Issues: > > There are currently no issues requiring board attention. The previously > reported absence of PMC activity seems to have disappeared. I am no longer > concerned about this. > > > > ## Membership Data: > > Apache PLC4X was founded 2019-04-17 (almost 4 years ago) There are > currently 19 committers and 13 PMC members in this project. > > The Committer-to-PMC ratio is roughly 5:4. > > > > Community changes, past quarter: > > - César García was added to the PMC on 2021-10-01 > > - No new committers. Last addition was Thomas Frost on 2021-05-07. > > > > ## Project Activity: > > The project has continuously been working on adding new features, fixing > bugs, and improving existing code. Probably the most significant block of > work has been the complete re-write of our code-generation core. In > anticipation of more programming-languages coming to the project, we > refactored and rewrote most of the code-generation to make it simpler to > develop new code-generation templates. In the end all of this didn't change > a single driver, but the overall usability of our tooling has improved as > well as we lowered the entry-bar for folks coming into the project. > > > > ## Community Health: > > Project activity was low in December. In the beginning of January, I > (Chris) posted a blog post [1], where I announced that I personally would > be stopping to provide free community support for companies. This blogpost > unexpectedly went viral. Online and offline news picked it up all over the > world and reported about it in the context of the whole "sustainability of > open-source" discussion. I did see one occasion where false news was spread > (HackerNews reported Apache PLC4X was giving up free community support), > but I think I managed to correct that. Besides that, it generally brought a > lot of attention to the topic of open-source sustainability, but also to > our project. Since then, we have seen a significant increase in page views > to our website, to the github repository and we even got several new > contributors sending pull-requests, bug reports, etc. There are also > several companies willing to invest in PLC4X development. Admittedly now, I > am really happy with the activity in the project. (I would have loved to > provide numbers, but currently the board report tool seems defective) > > My general takeaway is, that it looks as if me stepping back a bit might > even have been good for the project. I am not giving up on the project, I > just switched to not instantly fix everything and rather help people > reporting bugs into fixing them themselves and contributing this back. > > > > Perhaps projects in which one or a few individuals are excessively trying > to keep all balls in flight is counter-productive with respect to > developing a healthy community. > > [1] > https://github.com/chrisdutz/blog/blob/main/plc4x/free-trial-expired.adoc >
[DRAFT] March PLC4X board report
Had to hand write this one ... seems the report generator is currently defective, but as we reduced the numbers in the report anyway, it wasn't too much additional work ;-) I did ad a bit mor personal part to the Community health part as I think the board should be aware of it. If I don't see any objections, I'll submit this in a few days. ## Description: The mission of the Apache PLC4X project is creating a set of libraries for communicating with industrial programmable logic controllers (PLCs) using a variety of protocols but with a shared API. ## Issues: There are currently no issues requiring board attention. The previously reported absence of PMC activity seems to have disappeared. I am no longer concerned about this. ## Membership Data: Apache PLC4X was founded 2019-04-17 (almost 4 years ago) There are currently 19 committers and 13 PMC members in this project. The Committer-to-PMC ratio is roughly 5:4. Community changes, past quarter: - César García was added to the PMC on 2021-10-01 - No new committers. Last addition was Thomas Frost on 2021-05-07. ## Project Activity: The project has continuously been working on adding new features, fixing bugs, and improving existing code. Probably the most significant block of work has been the complete re-write of our code-generation core. In anticipation of more programming-languages coming to the project, we refactored and rewrote most of the code-generation to make it simpler to develop new code-generation templates. In the end all of this didn't change a single driver, but the overall usability of our tooling has improved as well as we lowered the entry-bar for folks coming into the project. ## Community Health: Project activity was low in December. In the beginning of January, I (Chris) posted a blog post [1], where I announced that I personally would be stopping to provide free community support for companies. This blogpost unexpectedly went viral. Online and offline news picked it up all over the world and reported about it in the context of the whole "sustainability of open-source" discussion. I did see one occasion where false news was spread (HackerNews reported Apache PLC4X was giving up free community support), but I think I managed to correct that. Besides that, it generally brought a lot of attention to the topic of open-source sustainability, but also to our project. Since then, we have seen a significant increase in page views to our website, to the github repository and we even got several new contributors sending pull-requests, bug reports, etc. There are also several companies willing to invest in PLC4X development. Admittedly now, I am really happy with the activity in the project. (I would have loved to provide numbers, but currently the board report tool seems defective) My general takeaway is, that it looks as if me stepping back a bit might even have been good for the project. I am not giving up on the project, I just switched to not instantly fix everything and rather help people reporting bugs into fixing them themselves and contributing this back. Perhaps projects in which one or a few individuals are excessively trying to keep all balls in flight is counter-productive with respect to developing a healthy community. [1] https://github.com/chrisdutz/blog/blob/main/plc4x/free-trial-expired.adoc
