KNX1 to KNX2 Migration Steps

Well, I solved my problem! I had the old format {} from my items file instead of [] around the KNX addresses!

One more thing though, I have the following in my Things definition:

Thing device generic [ address="1.1.4", fetch=false, pingInterval=600, readInterval=0 ]

What is the address 1.1.4 ? Not sure I have that right (as I don’t know what it is referencing!)

I did get the following message in the log file:

2018-12-19 11:19:54.258 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - Polling individual address '1.1.4'

2018-12-19 11:20:01.395 [DEBUG] [nx.internal.client.AbstractKNXClient] - Could not read value for datapoint 1/2/19: timeout waiting for group read response from 1/2/19. Going to retry.

But things seem to be working ok

that’s the Individual Address [IA] (aka Physical Address) of the remote KNX Actuator. IA have a format of: x.y.z
It is optional since you can create a “virtual” Thing in OH2 with KNXv2.
If you set the IA, the binding will poll it periodically to see if it’s online.

This is a different problem. The Group Address (GA) 1/2/19 is not responding to queries (Group Read telegrams originating from OH2). Double check this. It is not a big problem, but better not to send read requests if the GA is not able to respond.

Thanks, that’s useful to know. Just re-read the docs – and I can now understand the bit about the polling to see if online.

I’ll check if that GA wasn’t responding when I was using v1 of the binding – may be something in my KNX network set wrong


1 Like

hello, I just follow your doc and did my migration but it was not fun in any ways :frowning:
in the process I did a small shell script that transform your thing file into an item file (I still don’t get why having both is an upgrade)

#! /bin/bash
while read line
 if [[ $line =~ $regexbridge ]]
#  echo "bridge: $bridge"
 if [[ $line =~ $regexthing ]]
#  echo "thing: $thing"
 if [[ $line =~ $regextype ]]
  echo "${type^}  $name $desc { channel=\"knx:device:$bridge:$thing:$name\"   }"

done < "${1:-/dev/stdin}"

also available here:

thanks for your work


1 Like

I have a small question about setting up the KNX2 vbinding and the things-file:

With knx1-binding there is no reference to the knx-actuators.

When i change the config on the knx side (for example move a light from one actuator to another), i don´t have to change anything inside openhab.

With knx2-bidning, i have to change the things-file too?

Is this a “must be” that i define a single thing-device for every actuator? Or is it also possible to only define one “big thing device”, where all my GAs are inside? (without any reference to a specific actuator)

The latter is correct. In fact, you can define as much things as you want, you don’t have to set the individual address of the thing. Of course then you can’t get additional information about your hardware.

There is one point to note, the parameter readInterval is set once per thing, so, if you want to use this feature, I recommend to group all channels which should be read frequently in one thing and leave all other channels without frequently read requests.

Ok, thanks for the clarification.

What is the best way to migrate to knx2?

My problem, i have no time to do all in one day. I think i will have to split the work. But i can not use knx1 and knx2 binding together to test the new config-files.

So i think the best would be: write all new files - make a snapshot of OH-VM (my oh runs on esxi) and then change the files and install the new binding. If there are too many errors, go back to previous snapshot and rework the config-files…

Or completely clone the OH virtual machine - use one for knx1 and one for knx2. Is this possible? Will this work, if i only start/stop the two identical virtual clones? So i could go back to knx1 when i have to stop the work and can start again the next day?

I’m running openHAB in three instances, the first is still OH1.8, the second is OH2.5 (already with knx2) and the third is to experiment a little bit… All three instances are running as VM (the latter at proxmox, the others at xen)

The downside is, as I have no urgency to migrate completely… I’m running this setup since more than one year… :wink: Maybe at some point I will start a fourth VM with OH3 :confused:

But your three instances are running at the same time?

And so you only can have rules on one of the oh-installations, for which there are the items in the same installation.

Jepp. I have to decide which OH instance shall command which channels through rules. But the point is, there is absolutely no problem to run more than one instance, even for a long time.

In fact, the roadmap for OH3 is to remove the compatibility layer and to force the people which need OH1 bindings, to configure two OH instances (and share the items through mqtt eventbus).

Is it possible, to use knx1 and knx2 in two installations at the same time - all knx items on both machines so that i can control my knx with knx1 and knx2 at the same time?

This woul be the perfect way. So i would only install a small OH2-Install with knx2 and then enter all my knx-items. When i can control the whole knx with the knx2 machine too, i can change on my main OH-Server from knx12 to knx2 in short time:

remove knx1 bidning, install knx2 binding, copy all config files from the Test-Server to the Main-Server - and that´s it…

Yes, as long as your gateway provides more than one connection :). If not, you can use knxd as a mediator.

Hi All,

maybe interesting for one or the other: I wrote a script for converting config files from knx1 to knx2 binding. It can read an ETS4 project file. The script works for me and may not work for everybody out of the box. But definitely it will be a good start to automate that migration part.
See here: for details.

All feedback is welcome

1 Like

Hi Jo and the forum,
today I used jo47011’s script to convert my OH2 KNX stuff. Jo help me out by changing some stuff in his script. It was really working like a charm.
Tutorial from Dim, Step 3 and 4 did Jo’s script, restart OH2, working.
I did not expect it to be so easy, that’s why I didn’t migrate earlier.

Thanks Jo

1 Like

Hi Dim Angelos the migration guide and the examples were very helpful for me and it works perfekt. Thanks a lot!
Has someone examples for KNX heating actors thing and item file like the examples from the top of the article?