[knx2] broken in snapshot release

@Udo_Hartmann: I reported the same problem here but I’m not using the snapshot. Perhaps those problems are related? Did you try the productive version of the binding in your setup?

Not yet. I’m pretty sure though, there will be no difference.

@Udo_Hartmann: This seems to be the same issue.

Yes, thanks, at least it brought some light in it. After changing the definition, my dimmer started working again. My perceptions so far:

  • If using more than one GA in a channel parameter, for example [ ga="1/1/1+1/1/2" ], the DPT is no longer optional but mandatory.
  • If using the read request symbol (<), this has to be after the DPT.
  • When changing settings through a knx.things file, be prepared that some of the settings won’t be updated. So at least you will have to rename the file to something else (not *.things) and change back, so openHAB will destroy all knx things and regenerate all of them.

This will work:

Bridge knx:ip:bridge "Name of your bridge" [ //the bridge will appear in Paper UI with this name
    ipAddress="ip of your bridge", 
    localIp="ip of your openHAB server", //do not use QFDN, as this will point to 127.0.1.1
    type="TUNNEL", 
    portNumber=3671, 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60,
    localSourceAddr="0.0.0"
 ]
 {
    Thing device myDevice "some channels" @ "KNX" [ 
    ] {
        Type dimmer                 : ch1 "Dimmer 1"     [ switch="3/5/20",position="5.001:3/5/22+<3/5/27" ]
        Type switch                 : ch2 "Switch 2"      [ ga="1.001:3/4/30+<3/4/34" ]
    }
}

This will not work:

// Settings of Bridge are untouched
 {
    Thing device myDevice "some channels" @ "KNX" [ 
    ] {
        Type dimmer                 : ch1 "Dimmer 1"     [ switch="3/5/20",position="3/5/22+<3/5/27" ]
        Type switch                 : ch2 "Switch 2"      [ ga="3/4/30+<3/4/34" ]
    }
//This won't work either
    Thing device myDevice "some channels" @ "KNX" [ 
    ] {
        Type dimmer                 : ch1 "Dimmer 1"     [ switch="3/5/20",position="5.001:3/5/22+<5.001:3/5/27" ]
        Type switch                 : ch2 "Switch 2"      [ ga="1.001:3/4/30+<1.001:3/4/34" ]
    }
}

With the following error:

None of the configured GAs on channel 'blah' could handle the command 'foo' of type 'bar'
1 Like

Hi Udo,
thank you very much for diving in the deep :slight_smile:

I faced an other problem with the syntax of the GAs.
A blank between the GAs and the + is not allowed.
So this is working:

"5.001:1/3/55+<1/6/55"

while this is not working:

"5.001:1/3/55 + <1/6/55"

I feared that… :wink:

@Udo_Hartmann & @Dim

I really need your help. Really in urgent case I struggle with this message:

None of the configured GAs on channel 'knx:device:71cd6426:sdsds' could handle the command 'UP' of type 'UpDownType'  

Happens with everything I want to “control” by openHAB towards KNX.
I am totally new to KNX and it is really frustrating.

I am using this config:

Can you please help as I see many incoming KNX traffic like e.g.:

19:24:31.130 DEBUG org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl[:69] - Delegating command 'OFF' for item 'KNXTestDevice_Test' to handler for channel 'knx:device:63afe2a3:Test'
19:24:31.136 DEBUG org.eclipse.smarthome.core.internal.common.InvocationHandlerSync[:55] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.knx.internal.handler.DeviceThingHandler@1fc85fa'.
19:24:31.140 DEBUG org.openhab.binding.knx.internal.handler.DeviceThingHandler[:213] - None of the configured GAs on channel 'knx:device:63afe2a3:Test' could handle the command 'OFF' of type 'OnOffType'
19:24:36.465 DEBUG calimero.link.192.168.62.205:3671[:160] - indication 1.1.8->4/0/1 L_Data.ind, low priority hop count 6, tpdu 00 80 0c c4
19:24:58.466 DEBUG calimero.link.192.168.62.205:3671[:160] - indication 1.1.8->4/0/1 L_Data.ind, low priority hop count 6, tpdu 00 80 0c c9
19:24:59.299 DEBUG org.quartz.core.QuartzSchedulerThread[:276] - batch acquisition of 0 triggers
19:25:18.466 DEBUG calimero.link.192.168.62.205:3671[:160] - indication 1.1.8->4/0/1 L_Data.ind, low priority hop count 6, tpdu 00 80 0c c4
19:25:29.098 DEBUG org.quartz.core.QuartzSchedulerThread[:276] - batch acquisition of 0 triggers
19:25:38.466 DEBUG calimero.link.192.168.62.205:3671[:160] - indication 1.1.8->4/0/1 L_Data.ind, low priority hop count 6, tpdu 00 80 0c c9
19:25:57.258 DEBUG org.quartz.core.QuartzSchedulerThread[:276] - batch acquisition of 0 triggers
19:26:25.062 DEBUG org.quartz.core.QuartzSchedulerThread[:276] - batch acquisition of 0 triggers
19:26:28.466 DEBUG calimero.link.192.168.62.205:3671[:160] - indication 1.1.8->4/0/1 L_Data.ind, low priority hop count 6, tpdu 00 80 0c c4
19:26:48.466 DEBUG calimero.link.192.168.62.205:3671[:160] - indication 1.1.8->4/0/1 L_Data.ind, low priority hop count 6, tpdu 00 80 0c c9
19:26:53.775 DEBUG org.quartz.core.QuartzSchedulerThread[:276] - batch acquisition of 0 triggers

Do you have access to the ETS project? Are the GAs’ DPTs correct?
Normally the error message appears when the GA DPT is not matched to the ga configured in openHAB! Can you please post the thing and channel configuration?

What’s your Thing configuration?

:+1:

@MARZIMA: If possible, for trouble shooting, switch over to static (text based) config to be easier to define DPTs etc.

Check out an example of flat file based config here: KNX1 to KNX2 Migration Steps

As @george.erhan mentioned: this usually happens when there is a mismatch between the DPTs.

This PaperUI based config:

would become (first part… then you define your Things under the Bridge):

Bridge	knx:ip:MYGATEWAY "MYGATEWAY" @ "KNX" [
	type="TUNNEL",
	ipAddress="192.168.62.205",
	portNumber=3671,
	localIp="192.168.62.48",
	readingPause=50,
	responseTimeout=10,
	readRetriesLimit=3,
	autoReconnectPeriod=60,
	localSourceAddr="0.0.0" ]
	{
		Thing device Actuator_1 "Switch Actuator 1" @ "KNX" [ address="x.y.z", fetch=false, pingInterval=600, readInterval=0 ]
		{
			Type	switch	:	Ch_11		"Channel 1.1"		[ ga="1.001:1/0/8+<1/2/8" ]
			Type	switch	:	Ch_12		"Channel 1.2"		[ ga="1.001:1/0/9+<1/2/9" ]
			Type	switch	:	Ch_13		"Channel 1.3"		[ ga="1.001:1/0/10+<1/2/12" ]
			Type	switch	:	Ch_14		"Channel 1.4"		[ ga="1.001:1/0/11+<1/2/11" ]
		}
		Thing device Actuator_2 "Shutter Actuator 2" @ "KNX" [ address="x.y.z", fetch=false, pingInterval=600, readInterval=0 ]
		{
			Type	rollershutter :	Ch_101		"Channel 10.1"		[ upDown="2/1/0", stopMove="2/1/1", position="2/3/10+<2/2/10" ]
			Type	rollershutter :	Ch_102		"Channel 10.2"		[ upDown="2/1/2", stopMove="2/1/3", position="2/3/12+<2/2/12" ]
			Type	rollershutter :	Ch_103		"Channel 10.3"		[ upDown="2/1/4", stopMove="2/1/5", position="2/3/14+<2/2/14" ]
			Type	rollershutter :	Ch_104		"Channel 10.4"		[ upDown="2/1/6", stopMove="2/1/7", position="2/3/16+<2/2/16" ]
		}
	}

@Udo_Hartmann @george.erhan @Dim

here is my thing:

and

image

I want to control these KNX devices:

Textual:

 "knx:ip:5e314083": {
    "class": "org.eclipse.smarthome.core.thing.internal.BridgeImpl",
    "value": {
      "label": "KNX/IP Gateway",
      "channels": [],
      "configuration": {
        "properties": {
          "useNAT": false,
          "readRetriesLimit": 3,
          "ipAddress": "192.168.62.205",
          "localIp": "192.168.62.48",
          "autoReconnectPeriod": 60,
          "type": "TUNNEL",
          "localSourceAddr": "0.0.0",
          "readingPause": 50,
          "portNumber": 3671,
          "responseTimeout": 10
        }
      },
      "properties": {},
      "uid": {
        "segments": [
          "knx",
          "ip",
          "5e314083"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "knx",
          "ip"
        ]
      }
    }
  },

  "knx:device:63afe2a3": {
    "class": "org.eclipse.smarthome.core.thing.internal.ThingImpl",
    "value": {
      "label": "KNX TestDevice",
      "bridgeUID": {
        "segments": [
          "knx",
          "ip",
          "5e314083"
        ]
      },
      "channels": [
        {
          "acceptedItemType": "Switch",
          "kind": "STATE",
          "uid": {
            "segments": [
              "knx",
              "device",
              "63afe2a3",
              "Test"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "knx",
              "switch"
            ]
          },
          "label": "Test",
          "configuration": {
            "properties": {
              "ga": "ga\u003d\"1.001:2/1/0\""
            }
          },
          "properties": {},
          "defaultTags": []
        }
      ],
      "configuration": {
        "properties": {
          "pingInterval": 600,
          "readInterval": 0,
          "fetch": false
        }
      },
      "properties": {},
      "uid": {
        "segments": [
          "knx",
          "device",
          "63afe2a3"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "knx",
          "device"
        ]
      }
    }
  },

Please delete the ga= part and the quotation marks.

1 Like

I removed it and still getting this mapping problem:

image

10:25:18.528 DEBUG org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl[:69] - Delegating command 'ON' for item 'KNXTestDevice_Test' to handler for channel 'knx:device:63afe2a3:Test'
10:25:18.531 DEBUG org.eclipse.smarthome.core.internal.common.InvocationHandlerSync[:55] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.knx.internal.handler.DeviceThingHandler@1fc85fa'.
10:25:18.537 TRACE org.openhab.binding.knx.internal.handler.DeviceThingHandler[:194] - Handling command 'ON' for channel 'knx:device:63afe2a3:Test'
10:25:18.540 DEBUG org.openhab.binding.knx.internal.client.AbstractKNXClient[:439] - Value 'ON' cannot be mapped to datapoint 'command DP 1/0/1 'knx:ip:5e314083', DPT id 1.001, low priority'

Hmm… please restart at least the knx binding (or simply restart openHAB)

Restarted didn’t change:

10:46:29.031 INFO  smarthome.event.ItemCommandEvent[:53] - Item 'KNXTestDevice_Test' received command ON
10:46:29.052 INFO  smarthome.event.ItemStatePredictedEvent[:53] - KNXTestDevice_Test predicted to become ON
10:46:29.086 DEBUG org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl[:69] - Delegating command 'ON' for item 'KNXTestDevice_Test' to handler for channel 'knx:device:63afe2a3:Test'
10:46:29.092 DEBUG org.eclipse.smarthome.core.internal.common.InvocationHandlerSync[:55] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.knx.internal.handler.DeviceThingHandler@91f20b'.
10:46:29.094 TRACE org.openhab.binding.knx.internal.handler.DeviceThingHandler[:194] - Handling command 'ON' for channel 'knx:device:63afe2a3:Test'
10:46:29.135 INFO  calimero.dptxlator.DptXlator[:374] - using osgi bundle wiring for bundle://159.0/lib/calimero-core-2.4-e9975c01.jar#tuwien/auto/calimero/dptxlator
10:46:29.137 DEBUG calimero.dptxlator.DptXlator[:378] - obtained bundle [org.openhab.binding.knx-2.3.0]
10:46:29.146 DEBUG org.openhab.binding.knx.internal.client.AbstractKNXClient[:439] - Value 'ON' cannot be mapped to datapoint 'command DP 1/0/1 'knx:ip:5e314083', DPT id 1.001, low priority'

I am not sure why the mapping fails. So I checked the code and since the mapping fails it doesn’t send the command out to KNX.

@Kai or @george.erhan any ideas. I am pretty confused.

Can you monitor the bus from ETS (don’t think you will get anything at this moment, but it worths a try)? Does openHAB report when starting as being connected to the KNX bus?
What type of KNX/IP interface (producer/model) do you have there?

Does the interface allow multiple tunelling connections, or is it a KNX/IP router that can be used as tunnel as well?
Try removing the DPT definition first from the configuration of the channel (1.001 in this case), leave only the GA, restart the binding or openHAB, check for the startup log that openHAB connects to the KNX bus in tunneling mode.

It is a GIRA KNX/IP Gateway and is already in TUNEL mode:

10:30:05.547 DEBUG org.openhab.binding.knx.internal.client.AbstractKNXClient[:176] - Bridge knx:ip:5e314083 is connecting to the KNX bus
10:30:05.548 DEBUG org.openhab.binding.knx.internal.client.IPClient[:75] - Establishing connection to KNX bus on 192.168.62.205:3671 in mode TUNNEL.
10:30:05.550 INFO  calimero.knxnetip.KNXnet/IP Tunneling 192.168.62.205:3671[:166] - establish connection from /192.168.62.48:54485 to /192.168.62.205:3671
10:30:05.551 DEBUG calimero.knxnetip.KNXnet/IP Tunneling 192.168.62.205:3671[:187] - wait for connect response from /192.168.62.205:3671 ...
10:30:05.552 INFO  smarthome.event.ThingStatusInfoChangedEvent[:53] - 'knx:device:63afe2a3' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
10:30:05.554 INFO  smarthome.event.ThingStatusInfoEvent[:53] - 'knx:device:63afe2a3' updated: OFFLINE (BRIDGE_OFFLINE)
10:30:05.555 INFO  smarthome.event.ThingStatusInfoChangedEvent[:53] - 'knx:device:63afe2a3' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE)
10:30:05.572 DEBUG calimero.knxnetip.KNXnet/IP Tunneling 192.168.62.205:3671[:282] - using server-assigned data endpoint /192.168.62.205:3671
10:30:05.574 INFO  calimero.knxnetip.KNXnet/IP Tunneling 192.168.62.205:3671[:194] - connection established (channel 29)
10:30:05.579 INFO  smarthome.event.ThingStatusInfoEvent[:53] - 'knx:ip:5e314083' updated: ONLINE
10:30:05.582 INFO  smarthome.event.ThingStatusInfoChangedEvent[:53] - 'knx:ip:5e314083' changed from UNKNOWN to ONLINE

I also receive data from the KNX Bus:

10:30:22.974 DEBUG calimero.link.192.168.62.205:3671[:160] - indication 1.1.4->4/0/0 L_Data.ind, low priority hop count 6, tpdu 00 80 0c a9
10:30:22.975 TRACE org.openhab.binding.knx.internal.client.AbstractKNXClient[:251] - Received a Group Write telegram from '1.1.4' to '4/0/0'
10:30:23.374 DEBUG calimero.link.192.168.62.205:3671[:160] - indication 1.1.8->4/0/1 L_Data.ind, low priority hop count 6, tpdu 00 80 0c a1
10:30:23.374 TRACE org.openhab.binding.knx.internal.client.AbstractKNXClient[:251] - Received a Group Write telegram from '1.1.8' to '4/0/1'
10:30:31.325 DEBUG org.eclipse.smarthome.config.core.ConfigDescriptionRegistry[:179] - No config description found for 'thing:knx:device:63afe2a3', using alias 'thing-type:knx:device' instead
10:30:31.341 DEBUG org.eclipse.smarthome.config.core.ConfigDescriptionRegistry[:179] - No config description found for 'channel:knx:device:63afe2a3:Test', using alias 'channel-type:knx:single' instead

That’s good. I am almost sure the problem lies in your openHAB configuration of the channels.
Try using the config files and not paper UI to define the ga’s (I have never used Paper UI for KNX), and I’m sure it should work from the config files.
Looking at your json files for the thing configuration it doesn’t seem that something is wrong, but still it’s worth trying to use the textual configuration. @Dim has provided a nicely structured knx.things configuration file.
In your case, define the thing with the channel like this:

Bridge	knx:ip:MYGATEWAY "MYGATEWAY" @ "KNX" [
	type="TUNNEL",
	ipAddress="192.168.62.205",
	portNumber=3671,
	localIp="192.168.62.48",
	readingPause=50,
	responseTimeout=10,
	readRetriesLimit=3,
	autoReconnectPeriod=60,
	localSourceAddr="0.0.0" ]
	{
		Thing device Actuator_1 "Switch Actuator 1" @ "KNX" [ address="1.1.2", fetch=false, pingInterval=600, readInterval=0 ]
		{
			Type	switch	:	mySwitch01		"My First Switch"		[ ga="1.001:1/0/1" ]
}
}

As @george.erhan wrote, try to delete all KNX related PaperUI based stuff and create a fresh /etc/openhab2/things/KNX.things with minimum configuration options to see if it works.

I can’t pin point the root cause of the problem that you are experiencing …

Here is a TRACE of org.openhab.binding.knx from my setup when I send ON to a Switch from OH2 to KNX:

==> events.log <==
2019-04-04 20:34:03.115 [ome.event.ItemCommandEvent] - Item 'P06_Small_LED' received command ON

==> openhab.log <==
2019-04-04 20:34:03.116 [TRACE] [.internal.handler.DeviceThingHandler] - Handling command 'ON' for channel 'knx:device:GIRA2167:GW90741_4:Ch_42'
2019-04-04 20:34:03.118 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec testing Keys '[ga]' for command 'ON'
2019-04-04 20:34:03.119 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec key 'ga' uses expectedTypeClass 'class org.eclipse.smarthome.core.library.types.OnOffType' witch isInstance for command 'ON' and dpt '1.001'
2019-04-04 20:34:03.119 [TRACE] [nx.internal.client.AbstractKNXClient] - writeToKNX groupAddress '1/0/13', commandSpec 'org.openhab.binding.knx.internal.channel.WriteSpecImpl@7902cd65'
2019-04-04 20:34:03.119 [TRACE] [nx.internal.client.AbstractKNXClient] - sendToKNX mappedValue: 'on' groupAddress: '1/0/13'
2019-04-04 20:34:03.120 [DEBUG] [nx.internal.client.AbstractKNXClient] - Wrote value 'ON' to datapoint 'command DP 1/0/13 'knx:ip:GIRA2167', DPT id 1.001, low priority' (0. attempt).
2019-04-04 20:34:03.243 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.4' to '1/2/13' with value '[1]'
2019-04-04 20:34:03.244 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:GIRA2167:GW90741_4' received a GroupValueWrite telegram from '1.1.4' for destination '1/2/13'
2019-04-04 20:34:03.244 [TRACE] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:GIRA2167:GW90741_4' processes a GroupValueWrite telegram for destination '1/2/13' for channel 'knx:device:GIRA2167:GW90741_4:Ch_42'
2019-04-04 20:34:03.245 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001

There is a small (but important) difference in the structure of the Channel identification. I have seen this before when using PaperUI and I don’t know if this is a problem or not.

Your log:

Handling command 'ON' for channel 'knx:device:63afe2a3:Test'

My log:

Handling command 'ON' for channel 'knx:device:GIRA2167:GW90741_4:Ch_42'

With text based config, I have 5 sections to fully identify the channel: (1)knx:(2)device:(3)GIRA2167:(4)GW90741_4:(5)Ch_42
With PaperUI based config, I see only 4: (1)knx:(2)device:(3)63afe2a3:(4)Test

It is: (1)knx:(2)device:(3)Bridge:(4)Thing:(5)Channel

which model?
I had trouble setting up my GIRA as a TUNNEL interface but i was successful with ROUTER type of connection (but comms seem to work ok in your setup… you seem to have just a Bridge/Thing/Channel config issue)

update (just saw this): try also to define an Individual Address (also known as Physical Address) for your Thing.
In theory, it is not required but you never know :slight_smile: