Ok… here it goes… My Lessons Learned from my recent efforts to make OpenHab talk to the the GIRA KNX/IP Router.
TL;DR: For the GIRA Router to work properly with OpenHab/KNX Binding: Don’t enable Reliable Communications and set the device in Line Coupler mode (not Line Repeater)
Having a KNX installation in my home, I wanted to play around with it as an enthusiast and I stumbled upon OpenHab for the first time in August 2016. The first thing that I saw is that I need a way to communicate to the KNX Bus over IP and in one of the wiki entries I saw that the GIRA KNX/IP Router was mentioned, so I decided to go for it (to be sure that it would work :))
I ordered it, installed it in my KNX Bus and configured it using ETS 5 as a line repeater device (Physical Address of X.Y.Z type). During the ETS configuration, I also enabled the “reliable communications” option in the Router Applications. This is recommended when using Wireless LAN from your PC running ETS to connect to the GIRA Router.
The decision to enable these 2 features (line repeater and reliable comms) caused me a lot of headache later on…
I couldn’t get the OpenHab KNX Binding to talk to the Router neither in Tunneling not in Routing mode.
Note:
In “Routing” I mean multicast (and connection-less) based communication between my device and the GIRA Router
In “Tunneling” I mean unicast (and connection-oriented) based communication between my device and the GIRA Router
For deeper dive: Read 03_08_05 Routing v01.05.01 AS.PDF (247.2 KB) and 03_08_04 Tunnelling v01.05.03 AS.PDF (297.4 KB)
When I configured the KNX Binding to work in Routing mode (set type=ROUTER in /etc/openhab2/services/knx.cfg), I was getting multiple log entries regarding “KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored”. Also, no commands where being delivered from OH2 to the KNX Bus.
When I configured the KNX Binding to work in Tunneling mode (set type=TUNNEL, set the KNX gateway ip address,and set the localIp address), I was getting log entries of “confirmation reply received” type and due to that, lots of communication errors and the tunnel was being torn down and re-established every few seconds (based on the setting of autoReconnectPeriod in the knx.cfg).
After having some discussions with both the GIRA Technical support team as well as the Calimero team, I realized that the line repeater configuration was not the proper one and I had to configure the GIRA router as a line coupler (Physical Address of X.Y.0 type). Also, I had to disable the reliable communications in order to get rid of these strange “received unknown frame, service type 0x538” messages.
These service type messages belong to the KNXnet/IP Routing address range (in hex is: from 0x530 to 0x53F) and only 2 are defined in the KNX standard: 0x530 for “ROUTING_INDICATION” and 0x531 for “ROUTING_LOST_MESSAGE". The 0x538 one is used by GIRA to exchange messages between their GIRA Router and their own GIRA G1 central operating unit.
Following the re-configuration of the GIRA Router to act as a line coupler, I had to also to modify the routing parameters of the device to allow routing of all telegrams from IP->Bus and from Bus->IP (see ETS screenshots below:)
There is an alternative way to this: Instead of routing all telegrams back and forth, you can setup a dummy application device in your ETS project and link it to the Group Addresses (GAs) that you want to access from OpenHab. In this way, the Filter Table in the Router gets automatically populated with these GAs and the router will allow those telegrams to go through.
Following these 2 changes, my OpenHab 2 installation and KNX Binding starting working properly!
The messages are being transmitted over multicast to the Router and the entire system is extremely responsive (within milliseconds from the moment that I switch an item on the web interface, the KNX endpoint reacts).
A huge thank you goes out to Boris Malinowsky from the Calimero Project who helped me a lot with debugging with his Calimero-GUI client.
Best Regards,
Angelos