You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Darren Everley <da...@xeropoint.co.uk> on 2022/03/01 22:40:18 UTC
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
Re: KNX: DPT_Value_Temp aka that 16-bit float with 'special' encoding
Posted by Darren Everley <da...@xeropoint.co.uk>.
Hi Chris,
Sorry for being slow in responding to this.
I've just pulled the latest code from github and tried to build, but I'm
now encountering the following error, any ideas what might be wrong?
[INFO] PLC4J: Driver: KNXNet/IP ........................... FAILURE [
0.868 s]
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 01:13 min
[INFO] Finished at: 2022-06-28T22:38:57+01:00
[INFO]
------------------------------------------------------------------------
---------------------------------------------------
constituent[0]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/conf/logging/
constituent[1]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-plugin-api-3.6.3.jar
constituent[2]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-compat-3.6.3.jar
constituent[3]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-resolver-util-1.4.1.jar
constituent[4]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/plexus-component-annotations-2.1.0.jar
constituent[5]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-settings-builder-3.6.3.jar
constituent[6]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/plexus-cipher-1.7.jar
constituent[7]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/plexus-interpolation-1.25.jar
constituent[8]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-resolver-spi-1.4.1.jar
constituent[9]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/guice-4.2.1-no_aop.jar
constituent[10]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-artifact-3.6.3.jar
constituent[11]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-resolver-provider-3.6.3.jar
constituent[12]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/cdi-api-1.0.jar
constituent[13]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-slf4j-provider-3.6.3.jar
constituent[14]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/plexus-utils-3.2.1.jar
constituent[15]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/plexus-sec-dispatcher-1.4.jar
constituent[16]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-repository-metadata-3.6.3.jar
constituent[17]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/commons-cli-1.4.jar
constituent[18]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-resolver-transport-wagon-1.4.1.jar
constituent[19]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/commons-io-2.5.jar
constituent[20]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/jansi-1.17.1.jar
constituent[21]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-model-builder-3.6.3.jar
constituent[22]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-embedder-3.6.3.jar
constituent[23]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/wagon-file-3.3.4.jar
constituent[24]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/org.eclipse.sisu.inject-0.3.4.jar
constituent[25]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-resolver-connector-basic-1.4.1.jar
constituent[26]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-settings-3.6.3.jar
constituent[27]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-model-3.6.3.jar
constituent[28]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-resolver-api-1.4.1.jar
constituent[29]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/jcl-over-slf4j-1.7.29.jar
constituent[30]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/wagon-http-3.3.4-shaded.jar
constituent[31]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/org.eclipse.sisu.plexus-0.3.4.jar
constituent[32]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/slf4j-api-1.7.29.jar
constituent[33]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-builder-support-3.6.3.jar
constituent[34]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/jsoup-1.12.1.jar
constituent[35]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/wagon-provider-api-3.3.4.jar
constituent[36]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-shared-utils-3.2.1.jar
constituent[37]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-resolver-impl-1.4.1.jar
constituent[38]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/maven-core-3.6.3.jar
constituent[39]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/javax.inject-1.jar
constituent[40]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/commons-lang3-3.8.1.jar
constituent[41]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/guava-25.1-android.jar
constituent[42]:
file:/Users/darren/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3/lib/jsr250-api-1.0.jar
---------------------------------------------------
Exception in thread "main" java.lang.reflect.InvocationTargetException
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:39)
at
org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:122)
at
org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:61)
Caused by: java.lang.Error: Unresolved compilation problems:
The method orElseThrow(Supplier<? extends X>) in the type
Optional<NonSimpleTypeReference> is not applicable for the arguments ()
The method orElseThrow(Supplier<? extends X>) in the type
Optional<ComplexTypeDefinition> is not applicable for the arguments ()
The method isEmpty() is undefined for the type
Optional<DefaultTypedField>
The method isEmpty() is undefined for the type
Optional<DefaultTypedField>
The method orElseThrow(Supplier<? extends X>) in the type
Optional<List<Argument>> is not applicable for the arguments ()
The method isEmpty() is undefined for the type
Optional<DefaultTypedField>
The method isEmpty() is undefined for the type
Optional<DefaultTypedField>
The method orElseThrow(Supplier<? extends X>) in the type
Optional<DefaultTypedField> is not applicable for the arguments ()
at
org.apache.plc4x.plugins.codegenerator.language.mspec.expression.ExpressionStringListener.<init>(ExpressionStringListener.java:132)
at
org.apache.plc4x.plugins.codegenerator.language.mspec.expression.ExpressionStringParser.parse(ExpressionStringParser.java:48)
at
org.apache.plc4x.plugins.codegenerator.language.mspec.parser.MessageFormatListener.getExpressionTerm(MessageFormatListener.java:625)
at
org.apache.plc4x.plugins.codegenerator.language.mspec.parser.MessageFormatListener.enterComplexType(MessageFormatListener.java:102)
at
org.apache.plc4x.plugins.codegenerator.language.mspec.MSpecParser$ComplexTypeContext.enterRule(MSpecParser.java:291)
at
org.antlr.v4.runtime.tree.ParseTreeWalker.enterRule(ParseTreeWalker.java:50)
at
org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:33)
at
org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:36)
at
org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:36)
at
org.apache.plc4x.plugins.codegenerator.language.mspec.parser.MessageFormatParser.parse(MessageFormatParser.java:74)
at
org.apache.plc4x.plugins.codegenerator.language.mspec.parser.MessageFormatParser.parse(MessageFormatParser.java:45)
at
org.apache.plc4x.protocol.knxnetip.KnxNetIpProtocol.getTypeContext(KnxNetIpProtocol.java:44)
at
org.apache.plc4x.plugins.codegenerator.GenerateMojo.execute(GenerateMojo.java:161)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
... 7 more
On Thu, May 5, 2022 at 6:32 PM Christofer Dutz <ch...@c-ware.de>
wrote:
> 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 <sr...@apache.org>
> Sent: Montag, 7. März 2022 11:15
> To: dev@plc4x.apache.org
> 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 <
> > darren.everley@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
> > > <ch...@c-ware.de>
> > > 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 <da...@xeropoint.co.uk>
> > >> *Sent:* Tuesday, March 1, 2022 11:40:18 PM
> > >> *To:* dev@plc4x.apache.org <de...@plc4x.apache.org>; Christofer Dutz
> > >> < christofer.dutz@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.everley@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
> >
>
--
*Darren Everley - Director*
*Email: *darren.everley@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: KNX: DPT_Value_Temp aka that 16-bit float with 'special' encoding
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <sr...@apache.org>
Sent: Montag, 7. März 2022 11:15
To: dev@plc4x.apache.org
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 <
> darren.everley@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
> > <ch...@c-ware.de>
> > 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 <da...@xeropoint.co.uk>
> >> *Sent:* Tuesday, March 1, 2022 11:40:18 PM
> >> *To:* dev@plc4x.apache.org <de...@plc4x.apache.org>; Christofer Dutz
> >> < christofer.dutz@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.everley@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: KNX: DPT_Value_Temp aka that 16-bit float with 'special' encoding
Posted by Sebastian Rühl <sr...@apache.org>.
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 <
> darren.everley@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 <ch...@c-ware.de>
> > 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 <da...@xeropoint.co.uk>
> >> *Sent:* Tuesday, March 1, 2022 11:40:18 PM
> >> *To:* dev@plc4x.apache.org <de...@plc4x.apache.org>; Christofer Dutz <
> >> christofer.dutz@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.everley@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: KNX: DPT_Value_Temp aka that 16-bit float with 'special' encoding
Posted by Darren Everley <da...@xeropoint.co.uk>.
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.everley@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 <ch...@c-ware.de>
> 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 <da...@xeropoint.co.uk>
>> *Sent:* Tuesday, March 1, 2022 11:40:18 PM
>> *To:* dev@plc4x.apache.org <de...@plc4x.apache.org>; Christofer Dutz <
>> christofer.dutz@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.everley@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: KNX: DPT_Value_Temp aka that 16-bit float with 'special' encoding
Posted by Darren Everley <da...@xeropoint.co.uk>.
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 <ch...@c-ware.de>
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 <da...@xeropoint.co.uk>
> *Sent:* Tuesday, March 1, 2022 11:40:18 PM
> *To:* dev@plc4x.apache.org <de...@plc4x.apache.org>; Christofer Dutz <
> christofer.dutz@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
>
>
Re: KNX: DPT_Value_Temp aka that 16-bit float with 'special' encoding
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <da...@xeropoint.co.uk>
Sent: Tuesday, March 1, 2022 11:40:18 PM
To: dev@plc4x.apache.org <de...@plc4x.apache.org>; Christofer Dutz <ch...@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