[knx] DPT 5.010 values are converted to floating point numbers

[peti69]

I am currently migrating from openHAB 1.8 to the openHAB 2.4.0 image from dockerhub.

When receiving a DPT 5.010 value with the knx2 binding I see in my 2.4.0 events.log

2019-02-10 18:28:52.159 [ome.event.ItemCommandEvent] - Item 'FBH_Modus' received command 1
2019-02-10 18:28:52.227 [vent.ItemStateChangedEvent] - FBH_Modus changed from 2.0 to 1.0

The received number is not stored as an integer but as floting point number. In consequence my sitemap entry from 1.8

Selection item=FBH_Modus mappings=[1=Heizen, 2=Aus, 3=Auto, 4=Eco, 5=Absenken]

does not work anymore (no value is shown and in the drop down menu no value is preselected). I need to change it to

Selection item=FBH_Modus mappings=[1.0=Heizen, 2.0=Aus, 3.0=Auto, 4.0=Eco, 5.0=Absenken]

On openHAB 1.8 the events.log looks like this:

2019-02-10 09:45:00 - FBH_Modus received command 2
2019-02-10 09:45:00 - FBH_Modus state updated to 2

I expect that the knx2 binding works similar to the knx1 binding and provides an integer for the item in case the group address has the type DPT 5.010.

[lewie]

I also know the effect, I also had to adjust some.

But you're right, it would be correct if all 1 byte values like DPT 5.010 (and 5.004, 5.005, 5.006, ...) ideally should be output as integers.

As I see, openHAB doesn't yet distinguish these cases. But the information as what a value of an item was stored or should be output (decimal or integer) does not exist.

A similar case often occurs with PercentType, which is often seen as a decimal value rather than an integer.

Internally all values are stored as Bigdecimal in the Decimaltype/PercentType and can be output without decimal places (intValue(), longValue()) or with decimal places (doubleValue(), floatValue()).

Directly in the KNX binding this behavior cannot be adapted.

What do the architects think about this topic?

[miclederer]

I had the exact same issue and I like to believe this once worked correctly in openHAB 2.X with a knx1 binding (2.3? Didn't touch my installation for a while and lived with this behaviour.)

In the channel definitions one can specify the DPT. Maybe this can serve as a basis for the value handling (integer, float, etc.)? There are also some issues with percentage types (0.67 vs. 67[%]), but I can't recall the respecitve DPT right now.

[hotzen]

thx for reporting this, have exactly the same problems, also related to the HVAC-mode that is now broken after migrating to knx2 from knx1. so with knx1 it was definitely stored or at least represented as an integer 1 instead of decimal 1.0

[hotzen]

we are talking about 5.005 here though which has the general semantics "Decimalfactor 0-255" instead of 5.010 which has the semantics "Impulses" (still being in the range 0-255 though)

[mpattera]

I can confirm that this worked on openhab2 with knx1, I used many times Number items with DPT 5.xxx instead of the unsupported 20.102/20.105 for HVAC mode and they returned integers.

Now we have floating point, but changing mappings on Selection control from 1, 2, 3, ... to 1.0, 2.0, 3.0, .. only help for showing actual values because when trying to input through Selection control, items with DPT 5.xxx won't accept floating point. My workaround is using Dimmer items with DPT 5.004.. ugly.

1) Why mappings like 1, 2, 3 can't match values like 1.0, 2.0, 3.0? This would have not raised the issue. 2) Why an item can return floating point read from knx bus but can only accept integers for writing to the bus?

[hmerk]

closed due to inactivity