[SOLVED] OH2.3 with KNX2: Stopped receiving KNX-status-updates after upgrade from OH2.2 with KNX1

Add-ons Bindings
1

Hi!
On openHAB 2.2.0-1 (Release Build) and binding-knx1 - 1.11.0 everything worked fine except for the echos on the KNX-bus (using an Enertex KNXnet/IP Interface at 192.168.1.55).
After updating to openHAB 2.3.0-1 (Release Build) and KNX-binding 2.3.0, openHAB can still switch KNX-actors on and off, but does not receive status updates from KNX.

Here are some infos about the OH2.2 configuration:

###############################################################################
################# openHABianPi #################################### 7.05.170509
###############################################################################
##        Ip = 192.168.1.44
##   Release = Raspbian GNU/Linux 8 (jessie)
##    Kernel = Linux 4.9.35-v7+
##  Platform = Raspberry Pi 3 Model B Rev 1.2
##     Nginx = Version: 1.6.2
###############################################################################


openhab> config:list "(service.pid=org.openhab.knx)"
----------------------------------------------------------------
Pid:            org.openhab.knx
BundleLocation: mvn:org.openhab.binding/org.openhab.binding.knx/1.11.0
Properties:
   busaddr = 0.0.0
   compatibilityOH2 = true
   ignorelocalevents = true
   ip = 192.168.1.55
   localIp = 192.168.1.44
   readRetries = 1
   service.pid = org.openhab.knx
   type = TUNNEL

events.log: 

2018-06-02 14:22:51.524 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 192.168.1.55:3671 in mode TUNNEL.


Log when switching with openHAB
2018-06-02 14:34:59.815 [ome.event.ItemCommandEvent] - Item 'EG_Kueche_Licht_Decke' received command ON
2018-06-02 14:35:00.023 [vent.ItemStateChangedEvent] - EG_Kueche_Licht_Decke changed from OFF to ON

Log when switching with KNX:
2018-06-02 14:36:12.943 [ome.event.ItemCommandEvent] - Item 'EG_Kueche_Licht_Decke' received command OFF
2018-06-02 14:36:13.037 [vent.ItemStateChangedEvent] - EG_Kueche_Licht_Decke changed from ON to OFF

haus.items:
Switch 			EG_Kueche_Licht_Decke		"Küche Decke"	<light>	(EG_Kueche, EG_Kueche_Licht) { knx="2/2/21+<2/2/22" }

And here the OH2.3 data:

knx.things:
Bridge knx:ip:bridge [ 
    ipAddress="192.168.1.55", 
    portNumber=3671, 
    localIp="192.168.1.44", 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
] {
    Thing device generic [
        address="1.1.2",
        fetch=false,
        pingInterval=0,
        readInterval=1
    ] {
		Type switch        : EG_Kueche_Licht_Decke        	"EG_Kueche_Licht_Decke"       	[ ga="2/2/21+<2/2/22" ]
    }
}

haus.items:
Switch 			EG_Kueche_Licht_Decke		"Küche Decke"	<light>	(EG_Kueche, EG_Kueche_Licht) { channel="knx:device:bridge:generic:EG_Kueche_Licht_Decke" }


2018-06-02 14:51:50.884 [.ItemChannelLinkAddedEvent] - Link 'EG_Kueche_Licht_Decke-knx:device:bridge:generic:EG_Kueche_Licht_Decke' has been added.
2018-06-02 14:52:13.073 [hingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from UNINITIALIZED to INITIALIZING
2018-06-02 14:52:13.117 [hingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from INITIALIZING to UNKNOWN
2018-06-02 14:52:13.185 [hingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from UNINITIALIZED to INITIALIZING
2018-06-02 14:52:13.196 [hingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE)
2018-06-02 14:52:13.603 [hingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from UNKNOWN to ONLINE
2018-06-02 14:52:13.612 [hingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from OFFLINE (BRIDGE_OFFLINE) to UNKNOWN
2018-06-02 14:52:13.605 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred during notification about bridge status change on thing 'knx:device:bridge:generic': null
	at org.openhab.binding.knx.handler.AbstractKNXThingHandler.attachToClient(AbstractKNXThingHandler.java:184) [234:org.openhab.binding.knx:2.3.0]

	at org.openhab.binding.knx.handler.AbstractKNXThingHandler.bridgeStatusChanged(AbstractKNXThingHandler.java:119) [234:org.openhab.binding.knx:2.3.0]

Any ideas how openHAB can receive KNX-status-updates?

Greetings from Vienna, Austria
Peter

2

I also have some problems with update to 2.3. In this situaction I will check in ETS in magistral monitor is this “question” about 2/2/22 is sending to KNX.

BTW is readInterval=1 good idea ? It doesn`t kill your KNX ?

3

@bfksoql: Thanks for your reply. The ETS monitor does not show anything abnormal.
The first four lines are showing the response on the KNX bus when turning the light on and off using openHAB’s basicui (1.111 is the tunnel address); the last four lines when turned on and off using the Triton-KNX-switch:
Here for OH2.2:

32868541go.jpg1024×171

Here for OH2.3:
32868575zw.jpg1024×173

The readInterval=1 was a leftover of some attempts. It has no affect and was set to 0 now.

4

I have deleted the knx.things-file and created both the KNX-IP-gateway as well as the EG_Kueche_Licht_Decke-switch using the PaperUI-configuration - and it is working!

32879896qx.jpg1024×637

32879899iw.jpg1024×610

As I’ve got 160 KNX-devices I still want do edit them with Notepad++. I found entries regarding the PaperUI-configuration here:
openhab2-userdata\jsondb\org.eclipse.smarthome.core.thing.Thing.json:

"knx:ip:knx-ip-gateway": {
    "class": "org.eclipse.smarthome.core.thing.internal.BridgeImpl",
    "value": {
      "label": "KNX/IP Gateway",
      "channels": [],
      "configuration": {
        "properties": {
          "useNAT": false,
          "readRetriesLimit": 3,
          "ipAddress": "192.168.1.55",
          "localIp": "192.168.1.44",
          "autoReconnectPeriod": 60,
          "type": "TUNNEL",
          "localSourceAddr": "0.0.0",
          "readingPause": 50,
          "portNumber": 3671,
          "responseTimeout": 10
        }
      },
      "properties": {},
      "uid": {
        "segments": [
          "knx",
          "ip",
          "knx-ip-gateway"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "knx",
          "ip"
        ]
      },
      "location": "EG Vorzimmer"
    }
  }, 
  
  "knx:device:Triton_Kueche": {
    "class": "org.eclipse.smarthome.core.thing.internal.ThingImpl",
    "value": {
      "label": "Triton vor Eingang Kueche",
      "bridgeUID": {
        "segments": [
          "knx",
          "ip",
          "knx-ip-gateway"
        ]
      },
      "channels": [
        {
          "acceptedItemType": "Switch",
          "kind": "STATE",
          "uid": {
            "segments": [
              "knx",
              "device",
              "Triton_Kueche",
              "EG_Kueche_Licht_Decke"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "knx",
              "switch-control"
            ]
          },
          "label": "EG_Kueche_Licht_Decke",
          "configuration": {
            "properties": {
              "ga": "2/2/21+\u003c2/2/22"
            }
          },
          "properties": {},
          "defaultTags": []
        }
      ],
      "configuration": {
        "properties": {
          "pingInterval": 600,
          "address": "1.1.2",
          "readInterval": 0,
          "fetch": false
        }
      },
      "properties": {},
      "uid": {
        "segments": [
          "knx",
          "device",
          "Triton_Kueche"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "knx",
          "device"
        ]
      }
    }
  },

R:\openhab2-userdata\jsondb\org.eclipse.smarthome.core.thing.link.ItemChannelLink.json:

  "knx_device_Triton_Kueche_EG_Kueche_Licht_Decke -\u003e knx:device:Triton_Kueche:EG_Kueche_Licht_Decke": {
    "class": "org.eclipse.smarthome.core.thing.link.ItemChannelLink",
    "value": {
      "channelUID": {
        "segments": [
          "knx",
          "device",
          "Triton_Kueche",
          "EG_Kueche_Licht_Decke"
        ]
      },
      "configuration": {
        "properties": {}
      },
      "itemName": "knx_device_Triton_Kueche_EG_Kueche_Licht_Decke"
    }
  },

Can someone give me a hand in transforming these entries into a valid .things-file?

5

I have rewritten the knx.things from scratch and now everything is working! So here are my files:
knx.things

Bridge knx:ip:knx-ip-gateway "KNX/IP Gateway" @ "EG Vorzimmer" [ 
    ipAddress="192.168.1.55", 
    portNumber=3671, 
    localIp="192.168.1.44", 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
] {
    Thing device knx "KNX dummy for openHAB" [
        address="1.1.2",
        fetch=false,
        pingInterval=300,
        readInterval=0
    ] {
		Type switch        : EG_Kueche_Licht_Decke        	"EG_Kueche_Licht_Decke"       	[ ga="2/2/21+<2/2/22" ]
    }
}

haus.items

Switch 			EG_Kueche_Licht_Decke		"Küche Decke"	<light>	(EG_Kueche, EG_Kueche_Licht) { channel="knx:device:knx-ip-gateway:knx:EG_Kueche_Licht_Decke" }

Thanks for providing mental support!
Peter

6

Hi Peter,

I have some problems in understanding the knx.things file you have rewritten.

  1. Why did you replace “Bridge knx:ip:bridge” with “Bridge knx:ip:knx-ip-gateway”?

  2. And why did you replace “Thing device generic” with "Thing device knx “KNX dummy for openHAB”?

  3. And why did you use "address=“1.1.2” " for your “KNX dummy for openHAB”? Is this address the KNX Group Address of any kind of IP gateway or dummy device in your KNX network?

kind regards,
Michael

7

These are names, to uniquely identify the Thing and its channels. See how they get used in the Item binding.
‘knx’ is a bad choice for a channel name, when you are likely to have more than one!

8

As rossko57 said, 1. and 2. are just names.
As far as I know (please correct me if I’m wrong) the physical addresses are not used by openHAB (yet?), therefore I put all my KNX-items (with their group addresses, i. e. 2/2/21) into one single Thing. For this Thing I used an existing address of an actuator (1.1.2), but I think this address could be a dummy, too.