KNX1 to KNX2 Migration Steps

to periodically collect data to graph
By default, the energy meter will not transmit any info (unless configured to do so).
This is a bit different from a status update from a Switch Actor (which will transmit the new status on the GA)

ok, this is what I was looking for. Normally I would expect to configure the KNX device (the energy meter in that case) to send periodically its information (at least the GIRA energy meter 2175/3310 can send). so, if you can’t configure the device to do so for some reason, polling would be the last resort.

Thanks for clarifying!

Hi there,

first of all, thanks for tutorial. I followed it and got it “working”, but sending commands is very, very slow. I don’t know what the root cause is, but having a look at the logs;

2018-06-01 10:48:28.013 [WARN ] [ip.KNXnet/IP Tunneling 10.0.0.2:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 1.1.100->1.1.2 L_Data.req, system priority hop count 6 repeat, tpdu 81

it seems there is an issue with “status polling” (don’t know how to put it better).

I created a Bridge knx:ip:JUNGIPS200REG "JUNG KNX/IP Gateway" and used the same parameters as in the 1.X binding (my interface is shown in PaperUI as online).

Next I added a Thing device JUNG_S2 "[S2] JUNG 2316.16REGHE" @ "KNX" [ address="1.1.2", fetch=true, pingInterval=600, readInterval=0 ], that has a Type switch : Channel_S2_12 "S2/C12" [ ga="3/1/40+<3/1/43" ] (this thing is also shown in PaperUI, but marked as “OFFLINE”)

Last, but not least I have a Switch OG_Buero_LEU_Deckenspots "Büro Spots [%s]" <light> (gOG, gOGbuero, gLicht, gLichtOG) { channel="knx:device:JUNGIPS200REG:JUNG_S2:Channel_S2_12" }

It doesn’t matter from which device I’m sending commands (tested with PC/BasicUI and openHAB for iOS)… they are somehow “recognised”, but with a latency of 5-12 seconds.

For the moment I did a rollback to a snapshot I created before upgrading.

Post you KNX.things file to check it

Did you experience timeouts before with knx1?

hi @Dim!

thanks for reply. no, no timeouts with knx1 - works/ed like a charm.

Bridge knx:ip:JUNGIPS200REG “JUNG KNX/IP Gateway” @ “KNX” [
// Network address of the KNX/IP gateway
ipAddress=“10.0.0.2”,
// Port number of the KNX/IP gateway
portNumber=3671,
// Network address of the local host to be used to set up the connection to the KNX/IP gateway
localIp=“10.0.0.14”,
// The IP connection type for connecting to the KNX bus (TUNNEL or ROUTER)
type=“TUNNEL”,
// Time in milliseconds of how long should be paused between two read requests to the bus during initialization
readingPause=50,
// Timeout in seconds to wait for a response from the KNX bus
responseTimeout=10,
// Limits the read retries while initialization from the KNX bus
readRetriesLimit=3,
// Seconds between connect retries when KNX link has been lost (0 means never)
autoReconnectPeriod=1,
// The group address for identification of this KNX/IP gateway within the KNX bus
localSourceAddr=“1.1.100”
]
{
Thing device JUNG_S2 “[S2] JUNG 2316.16REGHE” @ “KNX” [ address=“1.1.2”, fetch=true, pingInterval=600, readInterval=0 ]
{
Type switch : Channel_S2_01 “S2/C01” [ ga=“3/1/20+<3/1/23” ]
Type switch : Channel_S2_02 “S2/C02” [ ga=“3/1/25+<3/1/28” ]
Type switch : Channel_S2_03 “S2/C03” [ ga=“2/1/110+<2/1/113” ]
Type switch : Channel_S2_04 “S2/C04” [ ga=“2/1/35+<2/1/38” ]
Type switch : Channel_S2_05 “S2/C05” [ ga=“2/1/115+<2/1/118” ]
Type switch : Channel_S2_06 “S2/C06” [ ga=“2/1/30+<2/1/33” ]
Type switch : Channel_S2_07 “S2/C07” [ ga=“2/1/20+<2/1/23” ]
Type switch : Channel_S2_08 “S2/C08” [ ga=“2/1/55+<2/1/58” ]
Type switch : Channel_S2_09 “S2/C09” [ ga=“3/1/0+<3/1/3” ]
Type switch : Channel_S2_10 “S2/C10” [ ga=“2/1/95+<2/1/98” ]
Type switch : Channel_S2_11 “S2/C11” [ ga=“1/1/0+<1/1/3” ]
Type switch : Channel_S2_12 “S2/C12” [ ga=“3/1/40+<3/1/43” ]
Type switch : Channel_S2_13 “S2/C13” [ ga=“1/1/15+<1/1/18” ]
Type switch : Channel_S2_14 “S2/C14” [ ga=“3/1/15+<3/1/18” ]
Type switch : Channel_S2_15 “S2/C15” [ ga=“2/1/120+<2/1/123” ]
// Type switch : Channel_S2_16 “S2/C16” [ ga=“1/0/15+<1/2/15” ]
}
}

i don’t see anything wrong with your config…

Maybe there is an issue with KNX2… not sure.
I saw some posts from other people also experiencing timeouts on GroupRead operations with KNX2 while never had a problem with KNX1…

You can try to open up a github issue here: https://github.com/openhab/openhab2-addons/issues

Ps: Use Code Fences to post configs/logs/etc

Hi @Dim!

Thanks for your reply & sorry for not using forum-syntax. You see what’s really weird is that I can actually send commands on “Channel_S2_14” (that are my office spots), but the latency between switching and actually a reaction from my actuator is approx. 8 seconds. If I immediately want to turn them off again, that command is basically “lost” and if I wait, lets say 10 seconds, it takes again some seconds until the light goes off again.

If I perform the same task with my running OH2.2 installation (/w KNX 1.X binding), everything is very performant.

Regarding your idea with the github issue - I found https://github.com/openhab/openhab2-addons/issues/3364, the guy who opened the thread received the same errors as me. It was updated on 26th March but I’m afraid it’s still open. I’ll keep my eyes open, if I find a solution I’ll post it here of course.

1 Like

Hi

I’m also trying to migrate my KNX1.13 to KNX 2.x, but i was not able to uninstall the KNX Binding (1.x) in the PAPER UI, it stays in the list. Do i have to uninstall it in a different way?

Thanks,

Tom

Enable Legacy Bindings

Angelos,

Thanks for the response, but not the solution.

They were already included.

Do have to go to the karaf console to uninstall it?

Tom

are you using the addons.cfg file?
you could try the console but this shouldn’t happen… any entries in openhab.log when you try to uninstall it?

try uninstalling knx2 and then knx1 (then install knx2)

A simple upgrade to the latest openhab version did an update in the bindings list in the PaperUI, finally i got rid of the KNX1 version . Thanks, now let’s migrate…

1 Like

Hi all,

wanted to share an experience I made with migrating to KNX2.
I have a bunch of GAs that are not tied to a specific target device (e.g., light config for all switches in the house). With KNX1 a no-brainer, but things are needed with KNX2 binding. Intuitively, I put these GAs into a new device thinging and - as the binding help page said is optional - I left out the bus address for this device thing. Obviously because there is not “the bus address” but multiple.

What can I say… didn’t work. I was not able to send out telegrams. ETS did not see anything coming from OH. Finally, I added a fake address to the KNX device thing. And it works…

Intended? Bug?

BR,
Fuzzy

Fuzzy, what DPT are the GA’s?
I also have a bunch of GA that are not tied to any target and seem to work.
My only issue so far is with scene DPT (17.001 and 18.001), the rest so far seems to work.

See https://github.com/openhab/openhab2-addons/issues/3686

Hi,

I also want to migrate to knx2. I updated to openhab 2.3 and it seems I have both bindings installed now. What I am wondering now, is it possible to have some of my items still on knx1 and some of them already in knx2?

I have quite a huge config and will not be able to migrate all at once. So what I wanted to do is take one item of my knx1 config. Create a new items file for my knx2 config and migrate them one by one. Will this work that way?

Thanks

Did you enable legacy bindings before upgrading to OH2.3? Otherwise, openHAB should have uninstalled knx1.

I don’t know if it’s possible to to use knx1 and knx2 competitively, though there is no real reason why that shouldn’t be possible. Of course both knx1 and knx2 will need a separate communication to the knx bus, so if using a knx/IP tunneling interface, you will need at least 2 tunnels (most modern interfaces support up to 5 tunnels)
Another thing is, you will have to ensure there is no overlapping in group addresses between knx1 and knx2.

I believe that this would be a problem, since both (KNXv1 & KNXv2) use the same Service PID name space (org.openhab.knx) in the ConfigAdmin, so you wouldn’t be able to setup 2 sets of parameters.

Oh, I thought the knx1 binding was renamed to knx1 and that this renaming took place also for configuration?!?

This naming convention (knx1) applies for some areas (like for the addons.cfg)
I just checked in the console (in 2 different OH2 installations, one with knx1 and another with knx2) and both store their config on the same pid config:list "(service.pid=org.openhab.knx)"

It seems like a design/planning “mistake” :slight_smile: but most likely this is intended (because the developers don’t want to allow a parallel installation of a legacy 1.x and 2.x binding)