OpenHAB, KNX and DPT 20.102 - a quest for understanding

Add-ons Bindings
1

Hi @ all,
I have a “it should work” problem.
I am working on implementing a HVAC control for my home.
My setup is KNX and a Raspberry-Pi based OpenHAB.

Using various search engines, I was able to figure out, that instead of using a DPT 20.102 channel a 5.010 DPT works well to map the enums to numbers, which can easily be mapped and seleced.

However … shouldn’t it also work using DPT 20.102 and “strings” for enum values, i.e. sending ‘Frost’ or ‘Comfort’ to that channel?

I created the following test-setup (simplified for brevity):

Thing:
channels:
  - id: HVACModeDPTInput
    channelTypeUID: knx:string
    label: "[82] HVACModeDPTInput(Input)"
    description: null
    configuration:
      ga: 20.102:3/3/13
  - id: HVACModeDPTReturnvalue
    channelTypeUID: knx:string
    label: "[90] KNX Status Returnvalue(Output)"
    description: null
    configuration:
      ga: 20.102:<3/3/28
  - id: CombinedHVACModeAsNumber
    channelTypeUID: knx:number
    label: "[82,90] HVAC Mode as number (In/Out)"
    description: null
    configuration:
      ga: 5.010:3/3/13+<3/3/28

Using items TestMode (number, maps to CombinedHVACModeAsNumber), and
TestModeAsStringSetter,TestModeAsStringFeedback; both as string and mapped to HVACModeDPTInput and HVACModeDPTReturnvalue, respectively.

The sitemap exceprt is as follows:

Selection item=TestMode label="HVAC by number" mappings=[2.0="Standby",1.0="Comfort",4.0="Frost",3.0="Nacht",0="Auto"]
Selection item=TestModeAsStringSetter label="HVAC by string" mappings=[auto="Auto",Comfort="Comfort",Standby="Standby",Economy="Economy",Building Protection="Building Protection"]
Text label="HVAC Feedback by number [%f]" item=TestMode
Text label="HVAC Feedback by string [%s]" item=TestModeAsStringFeedback

Using “HVAC by number” does correctly set the mode and obtains the correct feedback by number (0…4) and strings (“Auto”,“Comfort”,“Standby”,“Economy”,“Building Protection”).

Using the “HVAC by string” to set the mode updates the “TestModeAsStringSetter” item, but does not have any other effect.

Is the direction string to DPT not implemented, or do I have a mistake on my side?

I know, I have a work-around, but … my coder-brain does not want to accept, that the string to DPT is not possible.

Any hints where I have a mistake or pointers where to look for a solution?
I had a look at the source-code of that plugin and calimer, but to be honest, I was a bit lost, in terms of data-flow and interfaces.

Any help or insights would be really appreciated.

Sincerely, TLA

2

Please be aware that knx DPT 20.102 is, in general, just an unsinged 8 bit integer.
knx does not provide any real enumeration but does only send an 8bit uint.
openHAB, on the other side, does not provide any enumeration at all (shame on it…) and knx DPT are more or less useless in that deep details.
DPT is only used do decide how to present an x-bit value to number or string. The DPT model is used mainly for ETS monitoring, and of course each value 0 to 4 has a defined meaning, but in the end, it’s an 8Bit uint.

Ou course you can use a mapping file to translate from and to DPT, but I recommend to use the number instead and only transform the displayed value.

1 Like
3

Thanks.
So, in summary: While one can specify DPT 20.102 (or any other 20.x type) the mapping from the underlying 8bit is done by calimero to string. Effectively, this is a one-way street, as there is no provided mapping back from strings to the respective enum either in calimero or OpenHAB.

This feels unsatisfactory to me, but given my unfamiliarity with the involved sourcecode (OpenHAB/Calimero) and lack of spare-time, I can’t fix this.

4

No, there is just no string at all. knx DPT20 is 8 Bit uint, not String. One can do a mapping to Text, but that is not applied to the bus.
knx is a Methusalem, it’s 9600 Bit per Second, it’s designed to use optimized bandwith (i.e. as little as possible). knx is low level communication, no device needs Text to choose one of five options. In fact, three Bit would suffice :wink:
Please be aware that a knx message is much more than the data itself, it contains individual address of the transmitting device, information about the target (the GA), counters for hopping, hash and other stuff, so a knx packet is minimum 9 Bytes, so about 8 mSec per packet, but up to 23 Bytes, which is 20 mSec.

5

Thanks for your feedback.
I am aware, that KNX is very conservative in terms of bandwidth use.

However, as my setup shows: OpenHAB or Calimero does promote the bitfield to strings when setup as 20.102 and string-items. My question simply was, wether the reverse, i.e. string to bitfield in the transformation layer of OpenHAB/Calimero would happen.

As I understand: NO.

And yes. KNX is no infinibad, so bandwidth and latency are prime. :wink:

6

Ah. I wasn’t aware of that.
Maybe if using the exact String (upper/lower chars) the string will also work to control via String Item. It’s essential to use quotes if the string does include spaces, so the Widget should be like

Selection item=TestModeAsStringSetter label="HVAC by string" mappings=[Auto="Auto",Comfort="Comfort",Standby="Standby",Economy="Economy","Building Protection"="Building Protection"]
7

For me that does not work, but as I am not (yet) an expert for OpenHAB, I am not confident enough to make that a finala verdict.