KNX2 binding and dpt 5.x (1 byte number items) failing

Add-ons Bindings
1

I’m having a bit of trouble receiving 1 byte number items of the dpt family 5.x with the new KNX2 binding (OH2.3).

Here’s my channel-definition:

        Type number     : WS_Azimut "Sonne Azimut"   [ga = "<5.003:12/1/3"]
        Type number     : WS_Elevation "Sonne Elevation"     [ga = "<5.003:12/1/4"]

This is for my KNX weather device. Other channels for switch items or certain 2 byte number items (9.001) under the same thing work fine.

I’m also trying to set some items for the weather device (such as the required ambient light level to begin pulling down the shades. The weather device also expects a 1 byte number for this giving the illuminance in 1.000 Lux units.

My channel definition for a control channel to achieve this looks like this:

        Type number-control : WS_GWSonneBeschattung   "Helligkeitsvorgabe Beschattungsstart" [ga = "5.010:12/1/20"]

The other two items above, i can see calimero receiving the data packets, the binding is just not reacting to it and fails silently. (using set:log TRACE for both calimero and org.openhab.binding.knx). This looks like this:

2018-08-02 08:23:16.145 [DEBUG] [calimero.link.224.0.23.12:3671      ] - indication 1.0.10->12/1/3 L_Data.ind, low priority hop count 5, tpdu 00 80 41
2018-08-02 08:23:16.145 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.10' to '12/1/3'
2018-08-02 08:23:16.176 [DEBUG] [calimero.link.224.0.23.12:3671      ] - indication 1.0.10->12/1/4 L_Data.ind, low priority hop count 5, tpdu 00 80 11
2018-08-02 08:23:16.176 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.10' to '12/1/4'

It also fails with dpt type 9.005:

        Type number     : WS_Wind     "Windgeschwindigkeit"  [ga = "<9.005:12/1/5"]

2018-08-02 08:25:19.430 [DEBUG] [calimero.link.224.0.23.12:3671      ] - indication 1.0.10->12/1/5 L_Data.ind, low priority hop count 5, tpdu 00 80 00 8c
2018-08-02 08:25:19.430 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.10' to '12/1/5'

A good update for a number item with default dpt 9.001 looks like this:

Channel:

Type number     : WS_Temp_uncorr     "Aussentemperatur WS (unkorrigiert)" [ga = "<12/1/12"]

Log:

2018-08-02 08:32:20.656 [DEBUG] [calimero.link.224.0.23.12:3671      ] - indication 1.0.10->12/1/12 L_Data.ind, low priority hop count 5, tpdu 00 40 06 a0
2018-08-02 08:32:20.657 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Read Response telegram from '1.0.10' to '12/1/12'
**2018-08-02 08:32:20.657 [DEBUG] [.internal.handler.DeviceThingHandler] - Thing 'knx:device:bridge:Wetterstation' received a Group Write telegram from '1.0.10' for destination '12/1/12'**

Any ideas?

2

There seems to be a documentation or implementation error with the position of the dpt definition.

See here or here.

Please try

      Type number     : WS_Azimut "Sonne Azimut"   [ga = "5.003:<12/1/3"]
      Type number     : WS_Elevation "Sonne Elevation"     [ga = "5.003:<12/1/4"]

and

       Type number     : WS_Wind     "Windgeschwindigkeit"  [ga = "9.005:<12/1/5"]
3

It’s not that. putting the ‘<’ behind the dpt does not change the behaviour.

4

Could you please try another thing? I have read somewhere, that the knx2 parser doesn’t like spaces at some places. Please remove the spaces before and after the ‘=’.

      Type number     : WS_Azimut "Sonne Azimut"   [ga="5.003:<12/1/3"]
      Type number     : WS_Elevation "Sonne Elevation"     [ga="5.003:<12/1/4"]

      Type number     : WS_Wind     "Windgeschwindigkeit"  [ga="9.005:<12/1/5"]
5

no change, both for “<(dpt):mainGA” or “(dpt):<mainGA”.

6

Could you solve your problem? I’m facing this as well and am not able to send or read this thing
Type number : LueftungStufe "Lüftungsstufe" [ ga="5.010:1/4/100+<5.010:3/4/100" ]

Would be nice to get a solution. Thanks!

I also tried this
Type number : LueftungStufe "Lüftungsstufe" [ ga="5.010:1/4/100+<3/4/100" ]

7

Nope, not working. Also not in OH2.4

8

Same problem here - no way of reading/sending 1 byte values

9

After all DPT types are defined accordingly (e.g. [ ga="5.001:<7/0/1" ], see ETS for correct types) and restarting openhab everything works as expected in my case.

1 Like