Closed clinique closed 2 years ago
This is a bug in the DecimalType
parsing code in openhab-core. new BigDecimal("0E+1")
returns a valid value, however the parsing code throws an exception because the parsing stops after the 0
. The returned value is nevertheless valid.
Have you filed a bug in openhab-core ? Do you want me to do it ?
No, I didn't file a bug, would be great if you could do that. I can put that on my list for things that need fixing.
Done
Can you reproduce this? Would you be willing to test a debug version that logs input/output so we can find out how this "0E+1" value is created?
Yes, I can reproduce it.
Here's the definition of the channel / item link :
I have this error when the binding comes online (usually at OH startup) - and I suspect that the channel sets it's value to 0.
Correct. The channel value is set to 0 when the exception triggers :
2022-03-29 10:49:00.674 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'SynopTRAPPES_Octa' received command REFRESH
2022-03-29 10:49:00.742 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SynopTRAPPES_Octa' changed from 12 to 0
==> /var/log/openhab/openhab.log <==
2022-03-29 10:49:00.735 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.synopanalyzer.internal.handler.SynopAnalyzerHandler@76c740a5': Invalid BigDecimal value: 0E+1
java.lang.NumberFormatException: Invalid BigDecimal value: 0E+1
at org.openhab.core.library.types.DecimalType.<init>(DecimalType.java:102) ~[bundleFile:?]
at org.openhab.core.library.types.DecimalType.<init>(DecimalType.java:86) ~[bundleFile:?]
at org.openhab.core.library.types.DecimalType.valueOf(DecimalType.java:125) ~[bundleFile:?]
at org.smarthomej.transform.math.internal.profiles.AbstractMathTransformationProfile.transformState(AbstractMathTransformationProfile.java:95) ~[?:?]
at org.smarthomej.transform.math.internal.profiles.DivideTransformationProfile.onStateUpdateFromHandler(DivideTransformationProfile.java:70) ~[?:?]
at org.openhab.core.thing.internal.CommunicationManager.lambda$11(CommunicationManager.java:534) ~[?:?]
at org.openhab.core.thing.internal.CommunicationManager.lambda$13(CommunicationManager.java:554) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
at org.openhab.core.thing.internal.CommunicationManager.handleCallFromHandler(CommunicationManager.java:550) ~[?:?]
at org.openhab.core.thing.internal.CommunicationManager.stateUpdated(CommunicationManager.java:532) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl$1.stateUpdated(ThingManagerImpl.java:176) ~[?:?]
at org.openhab.core.thing.binding.BaseThingHandler.updateState(BaseThingHandler.java:268) ~[?:?]
at org.openhab.core.thing.binding.BaseThingHandler.updateState(BaseThingHandler.java:287) ~[?:?]
at org.openhab.binding.synopanalyzer.internal.handler.SynopAnalyzerHandler.lambda$4(SynopAnalyzerHandler.java:161) ~[?:?]
I can reproduce it now, new BigDecimal("0").divide(new BigDecimal("8"))
returns 0E+1
. I still believe this is a bug in core, but I don't think the discussion will lead to anything.
Agree, if this is a valid BigDecimal and DecimalType accepts BigDecimal I do not get why an exception could exist for this given value.
Under certain circumstancies I get this exception at startup :
I think it maybe by channel being UNDEF or NULL but not sure.