[KNX] DPT 5.001 on KNX2 Binding delivers decimal instead of percentage values

[zaphood1967]

When using DPT 5.001 to read a value from my heating actuator, the binding delivers a decimal (e.g. 0.6) instead of a percentage (e.g. 60%). These values are sent correctly by the actuator to the KNX bus and have been processed correctly on the OH2 side with the KNX1 binding as well. Can somebody please have a look at this ?

Thanks a lot

Running OH2 snapshot 2.4.0~20181018164807-1 (Build #1399) on Openhabian on a RPi3b+, using a Enertex Router to Access the bus.

things

Thing device HA1MDTREG "HA1 MDT Heizungsaktor Heizkeller" @ "KNX" [ address="1.1.200", fetch=false, pingInterval=600, readInterval=0]
{
Type    number  :       Channel08         "Heizung Wohnzimmer Stellwert"      [ ga="5.001:<13/1/0" ]
}

items

Number HeizungWoZiStellwert Stellwert [%.1f %%]" { channel="knx:device:KNXRouter:HA1MDTREG:Channel08" }

[lewie]

I can not reproduce this behavior. I receive correct values.

On a MDT AKH-0400.02 Heizungsaktor(Screen ETS): Screen openHAB log:

See: In new KNX2 Binding 5.001 is mapped to PercentType: https://github.com/openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.knx/src/main/java/org/openhab/binding/knx/internal/dpt/KNXCoreTypeMapper.java#L193

Same Mapping of 5.001 to PercentType in old KNX1 Binding: https://github.com/openhab/openhab1-addons/blob/master/bundles/binding/org.openhab.binding.knx/src/main/java/org/openhab/binding/knx/internal/dpt/KNXCoreTypeMapper.java#L191

So the result should be the same in both bindings.

[zaphood1967]

Thanks for checking! I am now puzzled, why it works for you but not for me, given we are even using the same actuator… any idea what might be different?

ETS

Openhab

Edit: I have noticed, that some knx packets seem to be disappearing and do not get passed to OH2. They are sent on the knx site. Sometimes a reboot of OH2 fixes that, sometimes it doesn't. Doesn't seem to follow any pattern though...

[lewie]

Have it: Use Dimmer instead of Number Item! ;-)

Remember on your EDIT: Do you link your Enertex Router as Router or Interface? I personally prefer as ROUTER, cause I habe to test many things... Here a working bridge configuration as ROUTER:

Bridge knx:ip:bridge [ 
    type="ROUTER",
    localSourceAddr="0.0.50",
    portNumber=3671,
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60
] {
...
}

[zaphood1967]

I already checked that before, unfortunately no difference between number- and dimmer-item-definition here… :-(

I am using the router in router mode :-)

Bridge  knx:ip:KNXRouter "Enertex KNX/IP Router" @ "KNX" [
    type="ROUTER",
    portNumber=3671,
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=1,
    localSourceAddr="1.1.55" ]

[zaphood1967]

Just to be sure: Even after a Fresh start of OH2, I' still receiving decimals for the dimmer item. Other items that use decimals (dimmers or humidity) work as expected...

[lp9c]

I'm facing the same issue.. I can confirm that having a channel of type "number" in my knx.things file in combination with a Dimmer item in my .items file is working fine, although it seems a bit ugly. Having a Number item is converting the (for example) "98" (which is meant to be a percent according to the DTP 5.001) to a "0.98".

I just checked my old .items file, and with the knx1 binding it was working fine.. that is, the item was of type "Number" but it was getting set to a right value ( 98 in the example above ) as long as the DTP was specified in the { knx="..." } part. This is not happening with the knx2 binding, even though the DPT is specified in the [ ga="..." ] part of the channel definition.

Is it a bug in the knx2 binding? or somewhere in the communication between the binding and the rest of openhab( item handling )

[lewie]

Hello @lp9c and @zaphood1967, tested on a 2.4.0-SNAPSHOT Build #1401

If I want to have DTP 5.001 as percent value: KNX Thing in ./conf/things/*.thing or in PaperUI: it normally has to be Type dimmer

Type dimmer  :OG_mitte_Status_Stellwert_0_2_42  "OG mitte Status Stellwert" [ position="5.001:<0/2/42", autoupdate="true" ] //  1 byte K L - U - Prozent (0..100%)

KNX Item in ./conf/items/*.item or in PaperUI: it normally has to be Dimmer Item

Dimmer  OG_mitte_Status_Stellwert_0_2_42    "OG mitte Status Stellwert [%d %%]" (OG, gHeizaktoren, gMitte, gSQLeveryDayChange)  { channel="knx:device:bridge:knx_heataktors:OG_mitte_Status_Stellwert_0_2_42" } 

The only way I could get a decimal value is to set my Item to Number instead of Dimmer . log as Dimmer Item:

2018-10-27 08:44:11.433 [vent.ItemStateChangedEvent] - OG_mitte_Status_Stellwert_0_2_42 changed from 100 to 8

log as Number Item:

08:49:04.398 [INFO ] [smarthome.event.ItemStateChangedEvent] - OG_mitte_Status_Stellwert_0_2_42 changed from 0.08000000 to 1.00000000

When I switch my thing to Type number or Item AND Thing to number, I get no update anymore (@zaphood1967, are there your knx packets lost?) from the KNX bus. It does not matter if i have defined my thing with or without DTP definition position="5.001:<0/2/42".

This is the current basic behavior of the KNX2 binding. Whether this is a bug I do not want to judge. But it would be desirable if you could define DTP 5.001 alternatively as a number in the Things. It seems to me at least not logical because this behavior leads to confusion.

The loosing of the KNX packets is not correct. In addition, the KNX binding does not even raise a warning for this case.

[zaphood1967]

Thanks lewie,

I can now confirm that it works with a dimmer item & dimmer thing. When I testet it in the first place, I was defining only the thing and forgot to change the item accordingly, thanks for that hint.

A lot of packets get lost with number/number definion, but not all of them. (I'd estimate 50% disappear), otherwise I wouldn't have had any update on the sitemap at all, which wasn't the case.

[zaphood1967]

As my original issue was solved (at least a suitable workaround was found by lewie) I am closing this case. Guess we'd need to open a new issue to dig into the packet loss problem.

[zaphood1967]

Update: Looking at my persitence graph, I was wondering why I received only 100% for my heating valve value when using Thing/Dimmer & Item/Dimmer. It turned out, for whatever reason, I would need to use Thing/NUMBER but Item/DIMMER to receive updates again.

So

• Thing/Number & Item/Number delivers decimals
• Thing/Dimmer & Item/Dimmer delivers "100%" as fixed value, no updates at all (at least on my system)
• Thing/Number & Item/Dimmer delives the actual percentage

Hope this helps.

[lewie]

@zaphood1967,

If you have persisted a Number Item (saved as decimal/Number). And later, switching Item to type Dimmer (saved as Integer), this will not be catches or corrected in Database Tables. This can cause unexpected behavior.

Which persistence do you use? If you use JDBC Binding, we can correct eventually by hand.

[zaphood1967]

I am using rrd4j and have deleted the respective files after i switched the configuration.

[ustone]

Can somebody explain why this is closed? IMO KNX defines DPT 5.001 like this:

8-bit unsigned value | 1 Byte | DPT 5.001 | DPT 5.001 | 0...100

Values are 0..100 as you see. That means, if the ga section in things is like ga="5.001:<13.13.13", the values has to be converted in percent value or ga="5.001:<13.13.13" is invalid and must ga="<13.13.13". Why else the knx binding accept an KNX Datatype?

Additionally i wonder that knx 1 had the conversion by default and this ugly workaround switching to dimmer is accepted for KNX 2.

Have i misinterpreted the design of the knx 2 binding?

[lewie]

@ustone, zaphood1967 has closed, because the issue is solved!

Yes, DPT 5.001 always should be interpreted as 0..100. And "dimmer" channel is the logical counterpart to DPT 5.001, because it works with Integers from 0..100. DPT 5.001 is used with dimmer and so it is intended. When you use number, then you'll get a decimal number from 0,0 to 100.0 normally this is wrong. And therefore no, it is neither ugly nor a workaround!

However, there are of course use cases for which the DPT 5.001 is to be used for something else. Only rare then can it make sense to link a "number" with a DPT 5.001.

Here is a test file for you to test: https://github.com/lewie/openhab2/raw/DimmerDezimaltypeConversation/org.openhab.binding.knx-2.4.0-SNAPSHOT.jar

I would be pleased about meaningful friendly feedback. ;-)

[Sputnick85]

i'm running an ubuntu 18.04.01 with openhab 2.4.0-1 from https://openhab.jfrog.io/openhab/openhab-linuxpkg stable everything configured in Paper UI

sorry for reopening this again. I had the same "problem". My value comes from a Debug Powersupply MDT-STC-1280.01 and should be the bus load in percent. First the dpt 5.001 was interpreted as dpt 9.001 when i had configured this as number dimensionless.(in ETS the dpt is 5.001)

2019-11-19 21:31:05.101 [INFO ] [g.knx.internal.dpt.KNXCoreTypeMapper] - Translator couldn't parse data for datapoint type '9.001' (KNXIllegalArgumentException).
2019-11-19 21:31:05.102 [WARN ] [.internal.handler.DeviceThingHandler] - Ignoring KNX bus data: couldn't transform to any Type (destination='9/0/8', datapoint='command DP 9/0/8 'knx:device:2e667fdc', DPT id 9.001, low priority', data='0x02') 

I configured this manual to 5.001 by adding the dpt in the groupeaddress.

After this i finally had some values but 1% was interpreted as 0.01 and not as you said as 1.0. (bug? or problem while changed the dpt?)

2019-11-19 21:55:17.002 [vent.ItemStateChangedEvent] - KNXNetzteil10X_Buslast10X changed from 0.01 to 0.16
2019-11-19 21:55:19.003 [vent.ItemStateChangedEvent] - KNXNetzteil10X_Buslast10X changed from 0.16 to 0.11
2019-11-19 21:55:23.003 [vent.ItemStateChangedEvent] - KNXNetzteil10X_Buslast10X changed from 0.11 to 0.05

After some research i found this thread and changed the item from number to dimmer. now the values are as expected but in the UI now i have this ugly dimmer bar underneath my value(PaperUI -> Control).

I can follow your explenation but by the context this isn't a dimmer. The KNX Association describes this typ as 8 bit unsigned value. In my explanation it can be a dimmer but not has to(item perspective).

> 5.yyy = 8-bit unsigned value, like dim value (0..100%), blinds position (0..100%)

i think you are right from logical perspective but not 100% ;) from Item perspective. In my case it would be ok for me to have values as you explainde (16.0) but they are not as mentioned. Otherwise it would be okay to only display the value without the dimmercontrol underneath the value but i don't know how to configure this.

[udo1toni]

Simply use Text widget instead of Default widget.

[BlondFace]

Now I can't read the 5.001 values at all at OpenHAB (2.5) side. Simple task, I would like to monitoring several HVAC PWM value, but no matter what I do, items and things could be number or dimmer, there is no decimal or percentage results at OH side, while ETS shows the appropriate values.

[BlondFace]

Now it works. Thing created on Paper UI, type is dimmer, group addresse filled in on/off and absolute position fields. Item created textual, type is dimmer. Item value present in percentage.

[marcoavnet]

Hello, allow to give my two cents to this topic. I recently upgraded to OH 2.5.3 and for me the new KNX binding. Same observations as in this thread and I have the "Workaround" with the dimmer item.

In my opinion a number item is the correct one for percentage values. Having to use a dimmer item is a workaround. A humidity value has nothing to do with dimmer. If DPT 5.001 is used the conversion should be done automatically.

[Santonian]

Hi, same for me. I just switched from KNX 1 Binding to KNX 2 Binding with OH 2.5 and all my 5.001 Datapoints (Humidity, heating valve opening (Stellgröße), and so on) deliver wrong values. 0.01 instead of 1%

I will try to use a dimmer Item,even though this feels wrong. It should work with the number type

[udo1toni]

But 0.01 is 1% (where 100% is 1) :) so the problem is, when using a % as Unit, the Number doesn't get multiplied by 100 (just for the label)

[thinkfat]

But 0.01 is 1% (where 100% is 1) :) so the problem is, when using a % as Unit, the Number doesn't get multiplied by 100 (just for the label)

The whole idea about the DPT specification is presentation. It has no influence on the line protocol, the DPT is just to specify how the the payload shall be interpreted. Hence, "number" with DPT 5.001 must be interpreted a percentage value, not decimal fraction. I don't quite care how it's stored in the persistence layer, in fact it might be best to store it as a decimal number to make it presentation-independent, but when it's displayed in a label or in a chart, DPT hints must be obeyed.

[udo1toni]

Sure. That's the point.