KNX Gateway not online

Tags: #<Tag:0x00007f4335db55e0> #<Tag:0x00007f4335db5518> #<Tag:0x00007f4335db5428>
  • Platform information:
    • Hardware: Raspberry Pi 3B
    • OS: Linux/5.10.17-v7+ (arm)
    • Java Runtime Environment: 11.0.11 (Zulu11.48+21-CA)
    • openHAB version: 3.0.2
  • Issue of the topic: I added the KNX binding and wanted to create a thing to my KNX-IP-Gateway. In general this seems to work but i do not get the status “online”. The gateway everytim shows only status “unknown”. And when i add a KNX light as a thing it shows the message “Gateway offline”.

Configuration Code is:
UID: knx:ip:9c0fe3fae0
label: KNX/IP Gateway
thingTypeUID: knx:ip
useNAT: false
readRetriesLimit: 3
autoReconnectPeriod: 60
type: ROUTER
readingPause: 50
portNumber: 3671
responseTimeout: 10

What am I doing wrong?

Thanks a lot.

Best regards,

Does your interface support router mode? Maybe try with TUNNEL.

Btw: Welcome to the forum!

Hello Thomas,

many thanks for your fast reply and the warm welcome to the forum.

When I try IP-Gateway with TUNNEL i receive an error message: COMMUNICATION_ERROR and status of the IP-interface is “OFFLINE”

By the way: My IP-Gateway is a BuschJäger IP-interface 6186/32.

Any other ideas what i can do?

Thanks a lot for your support.

I had a quick look for the manufacturer documentation.
It is not a router so the setting should be configured as a “TUNNEL” device.

One question ahead:
Are you accessing the device with any other tool (like ATS bus monitor) in parallel?

I did not find a valid information, but probably the interface only accepts one connection at a time and this is blocked already by something different.
(For example my siemens ip gateway accepts 4 tunnel connections parallel, which allows me to access it with openHAB and change stuff via ETS software in parallel.)

Is “COMMUNICATION_ERROR” the only message or are there any details visible?

Are you able to provide some logs from your openHAB instance and set debug log level for the knx binding?

That would have been my next guess :wink:
Each of the connections will be configured in the interface with a separate IP address ( At least this is true for my Weinzierl and my MDT interfaces). So in case you already used the connection on address …100, you should figure out what additional addresses are available. ETS should give you the configuration.
As a cross check you could disable any other software that uses the .100 and try again to start the thing in OH.

1 Like

There are also some older ip devices which just support one conection at all.
ABB has one, which i had problems with for that reason.
(But ABB at least told the max connections in their technical documentation…)

1 Like

Had a quick look into the device docs, there is only one IP address mentioned, so I’d say this is the case here. The interface is a bit old (Docs mention ETS 3 only).

1 Like

Hello Thomas, hello Jerome,

thanks a lot for your help. You have been totally right.

Only one connection is allowed. I tried to access KNX via Homey some weeks ago. Even if i am not using this anymore the connection somehow stays established.

After a reboot of all KNX devices and disconnecting Homey from my network i got “online” with the IP-Interface through Openhab.

And I did set the connectiong type to “TUNNEL” before.

But unfortunately now the next issues rises:
Adding a KNX device (light) as a thing with adress 0.0.1 shows status “OFFLINE”.

UID: knx:device:90ae0272d5:dc8d3c12f1
label: Lampe Esszimmer
thingTypeUID: knx:device
pingInterval: 600
address: 0.0.1
readInterval: 0
fetch: false
bridgeUID: knx:ip:90ae0272d5
location: Esszimmer

What is here wrong with my setup?

Thanks a lot for your help.

Check out the full example on a thing definition. Here you see how to define a switch in a thing.
Besides the actor thing you need to set up the channels with the corresponding group addresses.
Does you actor really have the bus address 0.0.1 ? What is the group address for the switch object and status of your lights channel in the ETS ?
The group address is in the format x/y/z, whereas the bus addresses are like a.b.c.

Hello Thomas,

oh. I didn’t know that bus adresses are different than group adresses. I only received the *.knxproj file from my electrician. And I know the group adresses of the devices. The light in the living room is having 0/0/1 for switching and 0/0/2 for dimming.

And I also don’t know how to program the code in openHAB. I just tried to connect to the devices via the web plattform.

For what other informations do i need? And how to add things with group adresses without coding?

Thanks a lot.

Some very basic information on how things work:

knx addresses:
The bus address can be seen as the physical unique address of device (e.g. an Actor, a Sensor etc) on the knx bus.
Each knx device owns some communication objects.
The number, purpose and data types vary depending on the device type and its configuration.
Those objects are linked to group addresses.

Now how does this magic work ?
You have an actor with 4 channels that switches mains power - might be for your light or for a wall outlet or whatever. (In case you want to dim your lights special dim actors are required.)
Let´s assume you have a simple switching actor.
In ETS you can see in the device list that your actor has been assigned a physical address (bus address). Opening that actor various parameters can be set - you may e.g. disable unused channels.
For the channels you have enabled certain communication objects are shown.
For a dim actor channel typical objects are a state channel, the actual switching channel, an absolute dim value etc.

By assigning a group address to a communication object (I break this down to the very basic stuff) the device starts listening for that address value to be contained in telegrams sent on the knx bus. (You actually need to program your settings into a device after setting it up in ETS, do not forget).
Lets assume you habe set group address 1/1/1 as the address of the switching object of your Channel A (the one connected to your kitchen light bulb).

Now you add this group address to e.g. a communication object on one of your sensors (the wall switches). As this is the first address (you may assign multiple one to an object, whenever you push the corresponding segment of the wall switch, the address is written as a telegram on the bus, containing e.g. “1” for on or “0” for off. Just a simple example, there is much more.

As your actor channel object from above is listening on the bus, it receives the telegram, figures out it is addressed to himself and takes the payload to either switch on or off the light.

That is the most simple case to illustrate how things work.

What you’ve learned so far:

  • Devices have unique physical addresses, that identify them on the bus.

  • Communication objects reflecting aspects of the device functionality are linked to group addresses

  • Group address is uses for communication between devices over the bus and link them together.

What does it mean for openHAB ?

A binding is “just” a piece of code that interfaces actual hard- or software to the OH system following OHs architectural design / interfaces.
Bindings support various types of Things - you may think of a thing as a representation for something that the binding supports (e.g. a knx actor).
Some bindings support auto-discovery of things, some do not. The knx binding does not.
In OH for knx you have to define the representation (thing) of an interface/gateway (you did that above) to the bus, allowing you to read and write telegrams from/to it. So you go to the configuration, goto Things and press the big fat “Plus” sign - guess you already configured your gateway thing that way.
Select the knx binding, and you see what is supported. So besides the IP Gateway and the serial interface something called “KNX device” is available - this is a generic representation of a device on the bus. Use this as your actor.
Enter a meaningful label (I usually start with the bus address, followed by e.g. “MDT Dim Actor Model” so have a structure) - feel free to use whatever you want.
Now select the gateway you already have up and running as your bridge.
Add the bus address of your actor. do not touch anything else.
Press create to save it.

Tada! The things shows up as being online.

But up to now it is just a hull, being empty without functionality.
So we go to the tab “Channel” and add a channel. There are various types of channels supported. Simply use the “Switch” type.
Enter a Channel Identifier, e.g. “Channel_A” and a label like “Kitchen Ceiling Light”.
Add your switching group address in the field that appears at the bottom. Check the binding documentation for adding e.g. a state later - lets just keep it simple here.
Create the channnel.
Screen switches. Now expand the channel you created.

Press plus to add an “Item”. Items a the object coding and UI are linking to in OH, it is another layer of abstraction. Items may be linked to multiple channels, but we just create a single new one here.
Keep everything as it has been defaulted and press the blue “Link” button at the bottom.
You see your channel has been linked to the new item.

You now established the complete chain Physical actor - IP Gateway - OH KNX Gateway thing (Bridge) - OH knx device Thing.
The actual functionality lies within the linking of:
knx Actor Communication Object <-> OH Thing channel <-> OH Item.

Now if you change the OH item this get propagated down to the communication object of the actor using the group address chosen and triggers the linked functionality (here: Switch the channel / light)

To validate:
The easiest way: Go to the configuration, Choose “Model”, “Create Points from Model”, Choose your “knx Device” as thing, mark the channel you´ve created and say “Add to Model” (Keep all the defaults).

Now within the Model tree select the point you created.
You will see it on the right panel, a switch on top of it. Switch it, now, do it, have faith! :wink:

If everything went fine, your light bulb should now switch on and off.

For more details (this post is far too long) please take the time and read the documentations first - the RTFM approach works pretty well here. Not reading the docs will lead you nowhere.

Hope I was able to clarify things a bit for you. I know the learning curve is everything else than flat for OH. But it pays out.


1 Like