This post documents my learning curve around the difference, in the KNX world, between a KNX/IP Interface, and a KNX/IP Router.

KNX terminology in this context is very important to understand. In part because this is a case of words (really) mattering, and in part because not only do the words matter, but their meaning also differs substantially from the meaning of those works in the pure TCP/IP networking context.

We will start with something that took me multiple product purchases and many hours of head-scratching to appreciate:

A KNX/IP Router is also a KNX/IP Interface

A KNX/IP Interface is not also a KNX/IP router

What is a KNX/IP ‘Interface’?

A KNX/IP ‘interface’ is any device that ETS5 can use to program your KNX devices over your local TCP/IP network from a Windows PC and/or that can allow KNX twisted-pair (TP) device access and control with apps/touchscreens/etc from the local TCP/IP LAN.

However, if a KNX/IP product does not explicitly use the word ‘Router’ in the product name, it is not (also) a router and will not provide KNX/IP routing.

What is a KNX/IP ‘Router’?

In KNX parlance, what a KNX/IP ‘router’ actually provides is the functionality of a KNX ‘area coupler’ or ‘line coupler’, using a TCP/IP network as the linking medium.

An area coupler or a line coupler is a packet forwarding bridge (with built in packet filtering) that moves KNX telegrams (packets) between KNX physical network segments.

The distinction between an ‘area’ coupler and a ‘line’ coupler is simply based on whether you are inserting the coupler (‘router’) to connect distinct areas (first number in the Individual Address is different) or just between distinct ‘lines’ (where the area number is the same but the ‘middle’ number differs).

In either designation, appropriate KNX ‘telegrams’ (packets) get forwarded to the other network segment if they need to be, and they are ‘filtered’ (not forwarded) if they don’t need to be.

Normally this process is automatic, provided you have given the KNX/IP router the appropriate form of Individual Address (IA) to tell it how it is supposed to act (more on this later).

In writing this down, I will say that it is no wonder this is confusing to people already steeped in the terminology and operation of TCP/IP networks (as I am).

It turns out that a KNX/IP ‘router’ is not really a ‘layer 3’ router at all. It is ‘merely’ a layer 2 media bridge. The fact that there is a routing-capable TCP/IP protocol stack inside every IP enabled KNX device doesn’t magically make all those devices into KNX ‘routers’.

One thing that would love ETS5 to feature (and it certainly doesn’t, today) is the addition of a dialog box to warn you about the absence of any configured-in area or line couplers in your setup, any time that you try to construct a group address that spans areas or lines in your project. It seems to me that a simple warning (“No configured area or line couplers are available to forward this telegram”) would save a heap of future grief for others.

Time to look at some real world product examples.

Here are some devices in my home KNX network:

Per the discussion above – only one of these three (the one on the left) is a KNX/IP router, despite all three boxes having more than enough technical ‘grunt’ to be capable of ‘routing’ (and for all I know, they might well all be running identical underlying hardware).

If you don’t have the KNX/IP router there (and at first, I didn’t), then the twisted pair segment concerned is an island. It doesn’t matter how grunty or wonderful your KNX/IP interface products are (the X1 and S1 are both highly capable things)… neither of those is going to route a group telegram between the TP and IP networks for you, no matter how much you try to convince it to do so.

It was the Gira S1 that drove my initial confusion, ironically because it is such a cool and capable device in other ways. Based on my historical TCP/IP experience, I’d thought that because the S1 is a remote-access VPN and local area TCP/IP node, it would also be a KNX twisted pair router – I mean.. why not? Well… no, it doesn’t do that.

One confusing thing is that even if your device isn’t a router, ETS5 will still let you manually define a filter table for it, when there is absolutely no (obvious) point! That is how ETS5 helped to cement my (mistaken) belief that my Gira S1 was a KNX/IP router, when it wasn’t.

I wasted a good day fiddling about, trying to work out why the thing wouldn’t send packets over the network, adding in manually added filter table entries for the group telegrams I wanted to forward and it just … wouldn’t. No error message, no sign of problems, just no packet forwarding. It is obvious now, but it surely wasn’t obvious to me up front.

How to buy the wrong product without really trying

Here are three more KNX devices, all of which are KNX/IP interfaces:

The unit on the left in the photo above is a USB-KNX interface, allowing ETS5 programming without any IP components in the system. The other two units are different brands of KNX/IP interface, and they are functionally identical. They can be used for programming KNX devices in your project over your local TCP/IP network, and/or for facilitating access to KNX TP devices from other TCP/IP applications.

I bought the right hand unit (the MDT one) after I realised the Weinzierl product (installed many years ago, with my underfloor heating system) was not a router. When I did buy the MDT unit to replace it (so I could start doing KNX/IP routing), I mis-ordered it.

MDT make two products with a one digit difference in product ID code:

I purchased a 000.03 and I should have purchased a 100.03. The extreme similarity (in specification and visual appearance) underscores that they are most likely the very same physical box, sold at two different price points, where the lower cost one has simply got the KNX/IP ‘router’ functionality switched off.

Your choice of KNX/IP router Physical Address controls the functionality of the device!

This was a huge part of my learning curve, and not fully understanding this drove a lot of confusion for me in the first instance. In a TCP/IP network, the IP address is irrelevant to the functionality of a device. In a KNX/IP network, the Physical Address you chose has a dramatic impact on what your device will actually do.

The table (below) – or a variant of it – is a familiar component of the setup instructions for any KNX/IP router (this one is extracted from the startup document for a Gira KNX/IP router):

If you do not assign a ‘.0’ as the last part of the IA for your router, then it will not operate as a router at all. If you chose to use an address ending in ‘not 0’, then your KNX/IP ‘router’ will only function as a KNX Interface and will not forward (route) KNX telegrams!

This is in fact a very good design decision in the KNX architecture.

If only a device ending in ‘.0’ can act as an area or line coupler, then you can never have more than one active KNX/IP router per physical twisted pair network segment. This is a good thing, as it ‘naturally’ avoids all sorts of complexities that occur in the TCP/IP context (including the need to implement a network routing table, versus a bridge filtering list).

Just to labour that point slightly – the absence of a layer 3 routing table in KNX is why what KNX does, in my view, is really layer 2 bridging, not ‘routing’. I think these really should have called these things KNX/IP bridges or even better, KNX/IP ‘couplers’ (but… ‘too late now’ 🙂 ).

As another aside: The use of IP Multicast to carry KNX telegrams on the IP side of this process is a smart one. This nicely leverages the merits of IP multicast to ensure carriage of those telegrams (‘packets’) to any other KNX/IP routers that need to hear them, without any explicit configuration work being needed on the TCP/IP ‘side’ of the equation.

Clues to help you to realise your KNX/IP device is not really a router after all

ETS5 is slightly maddening at times, in that it ‘knows’ things about your devices that it doesn’t bother to mention to you – assuming you just ‘already know’. A key one here being whether the thing you (wrongly!) believe to be a KNX/IP router is really just a KNX/IP interface after all.

In other words, ETS5 ‘knew’ full well that I bought the wrong MDT device (see above), and it kinda-sorta tried to tell me this, in ways that were too subtle for me to notice them at the time.

So – to save you the same angst here are the clues to help you know when your KNX/IP router is really not a router after all (i.e. when you ordered the wrong product):

Clue: ETS5 refuses to let you assign a .0 address to your device

This is a dead giveaway (in hindsight). ETS5 ‘knows’ full well its not a router, so when you try to set the last byte to ‘0’, it renumbers it to ‘1’, despite your best efforts to talk it into the ‘0’ at the end.

Annoyingly, not error message – ETS5 ‘should’ (in my view) pop up a message to tell you that ‘Only KNX/IP routers can be assigned an address ending in 0’. Instead, the address box turns red, and then turns black again after ETS5 silently ‘fixes your mistake’ (instead of telling you about it).

Clue: The ETS5 right-click menu on your device doesn’t contain ‘Preview Filter Table’

I finally figured this one out… if you right-click on a device and the pop-up menu contains “Preview Filter Table” then you are looking at a properly confgured-in-to-your-project KNX/IP router (i.e. area or line coupler):

If you think you have got your router configured in properly but that “Preview Filter Table” entry is mysteriously missing when you right-click on it, then… you haven’t actually got it in there properly after all.

It would be really nice if KNX flagged a validly configured KNX/IP router more clearly on the device display. Displaying the device name in green or… something.

Clue: You can check if a KNX device is really a router before you buy it

ETS5 knows whether a device is a router or not. And it knows this based on the product catalogue, not based on your real physical device.

This is a subtle but important point.

You can select any device in ETS5 out of the global KNX product catalog, load it into your project, and use the earlier subtle clues (above) to assure yourself that it really is a router, and that it really will route… and then you can go buy it.

I wish I’d appreciated that before I started buying things!