Adopting the KNX standard for the home automation solution in the House has proved to be a thoroughly good decision so there’s no question of using any alternative technology for the Outbuildings – although they only need a modest amount of ‘automation’. The KNX hardware in the House – mostly made by MDT with one specialist device made by Zennio – has proved very reliable over nearly 10 years of use. One of the Binary Input sensor modules did stop working in 2019 but was brought back to life (for free, outside warranty) by MDT, who re-installed its firmware.

The main benefits of KNX compared with other home automation options are:

• There’s no lock-in to a particular device manufacturer
  • A KNX installation can consist of any combination of devices from any certified manufacturers, with devices from different manufacturers all interacting seamlessly
  • A manufacturer-independent Windows application called ETS, provided by the KNX Association, is used to configure each device, after loading a manufacturer-supplied data file into ETS
  • If one manufacturer decides to exit the KNX market, their devices will still continue to work (including being re-configured with ETS) – and the installation can still be expanded by using devices from a different manufacturer
• It runs completely ‘on-site’, with no reliance on an Internet connection or servers in The Cloud
• There’s no single central ‘brain’ within a KNX installation
  • The various KNX devices communicate in a ‘peer-to-peer’ fashion so if one device fails the impact is limited to that one device
  • The only device that could cause complete failure of the installation is the Bus Power Supply (which powers all the devices on one bus cable) – but that’s a fairly simple and hence robust unit
  • The ETS application is only used to set-up devices and change their configuration settings (and perhaps for debugging any communication issues); it is not required for ongoing operation
• KNX is designed to cater for very large installations in hotels or office buildings so can easily support even the most demanding domestic installation

Since the Outbuildings and the House are physically separate buildings (a few metres apart) it makes sense to give each building its own mostly-separate KNX bus installation but to form them into a single KNX ‘Project’ and to allow the two halves of the ‘Project’ to interact.

The two buildings will be connected via a TCP/IP computer network link (required anyway, for other reasons) so it makes sense to use that to connect the KNX installations too, by means of a KNX IP Router device in each building. The original KNX installation in the House used a KNX IP Interface (MDT SCN-IP000.02), which is less capable than a KNX IP Router (there’s a good description of the differences here) and so needed replacing (with an MDT SCN-IP100.03). There’s a significant price premium for the Router (around €275) compared with the Interface (around €175) so most installations use an Interface unless the Routing functionality is known to be required.

At the same time, a couple of other hardware devices in the House were swapped out so that the displaced devices could be used in the Outbuildings:

• The 160mA KNX Bus power supply (MDT STV-0160.01) was swapped for a 320mA model (STV-0320.02), to free up the 160mA unit for use in the Outbuildings and to provide some extra power capacity for any further KNX devices added to the house later
  • These power supplies will happily deliver more than their rated nominal capacity for a while, but the House is showing an anticipated 264mA bus current which is asking too much of a 160mA unit – and a second unit was required for the Outbuildings (anticipated 123mA) anyway
  • The 2nd generation 320mA model is actually half the physical width of the 1st generation 160mA model – despite having double the capacity
• The 16-way dry-contact Binary Input sensor bank (MDT BE-16000.01) was swapped for a new 8-way unit (MDT BE-08000.02)
  • This constantly monitors for any of the light switch push-buttons being pressed, and with 5 of those buttons having been replaced by native KNX switches only 8 of the 16 channels were being used in the House
  • 12 switch channels are required in the Outbuildings and it was cheaper to buy a new 8-way unit for the House than a second 16-way unit for the Outbuildings (which in turn was cheaper than combining a new 8-way unit with a new 4-way unit, to cover the Outbuildings’ 12-channel requirement)

A side-effect of replacing the IP Interface with an IP Router is that the replacement device (3rd generation) supports the new-ish security features in KNX:

• IP Secure – which protects KNX traffic when it’s traversing a TCP/IP network
  • Further info at https://support.knx.org/hc/en-us/articles/360012666599-KNX-IP-Secure
• KNX Data Secure – which protects KNX traffic using any communications medium
  • Further info at https://support.knx.org/hc/en-us/articles/360012689639-KNX-Data-Secure

KNX Data Secure requires cooperation from the target KNX device on the Bus (few devices seem to support that currently) and is set on a per-Group Address basis. IT Secure is only concerned with security on the TCP/IP side. While IP Secure can be turned off if required, it seems sensible to take advantage of that for:

• Secure Commissioning – which protects the traffic between the ETS application and the device
• Secure Tunneling – which protects any access to a KNX Tunneling interface (which is typically how applications such as Home Assistant communicate with KNX devices)

Secure Tunneling in particular is a desirable feature, since it means that access to the KNX Bus is no longer available to any device able to send traffic to UDP Port 3671 on the IP interface. Previously, protecting this access was a good reason to place KNX devices on a dedicated network (V)LAN.

Non-secure KNX Tunnel connections were typically run over UDP, with an option of TCP. Secure Tunnel connections must use TCP.

It’s pleasing to find that the KNX Integration for Home Assistant has good support for Secure Tunnels and the configuration pages provide guidance on where in ETS to find the required credentials. Looks like the KNX Binding for openHAB (which I used to use) supports Secure Tunnels too.

Home Assistant also supports secure Routed connections (based on IP Multicast). Since those need to be processed by multiple IP Router devices they can’t use per-device passwords – but there’s a ‘backbone’ security key that covers that scenario.

The House has a KNX bus installation, connected to a KNX IP Interface which allows home automation ‘hub’ software like openHAB or Home Assistant to control KNX devices such as lights and roller blinds. This IP Interface connection is also required for programming KNX devices using the KNX ETS software.

The Outbuildings will also have several KNX devices. The original plan was to implement these on a completely separate KNX bus installation, because:

• There is no anticipated requirement for KNX devices in the House to interact directly with KNX devices in the Outbuildings – e.g. for a KNX wall switch in the House to control lights in the Outbuildings
• The ‘Lite’ license for the KNX ETS software only allows a maximum of 20 KNX devices in each KNX ‘Project’ (but unlimited Projects) and the House already has 19 devices configured
  • By making the two KNX installations separate, they would each have their own KNX ‘Project’ and each of those would have fewer than 20 devices
  • The next step up from the ‘Lite’ license is the ‘Home’ license, which only allows a single Project – but that can have up to 64 devices

For convenience, a single home automation ‘hub’ will be used to manage all of the KNX devices – but that means it would need to talk to two separate KNX IP Interfaces, which is not (currently) a supported configuration for the Home Assistant KNX Integration.

There are several possible options to address this:

1. Use a not-fully-supported workaround to allow Home Assistant to connect to two KNX IP Interface devices by running a second instance of the xknx software
2. Use two separate instances of Home Assistant, each with their own KNX integration, connected to each other using https://github.com/custom-components/remote_homeassistant
3. Revert to using openHAB (rather than Home Assistant), since openHAB does support connections to multiple KNX IP Interface devices
   1. Potentially using openHAB in conjunction with Home Assistant, using the openHAB <-> Home Assistant Bridge integration
4. Connect the House and the Outbuildings as different ‘lines’ (or ‘line segments’) on the same KNX ‘bus’ – although then all the KNX devices need to be in a single ‘Project’, which requires a more expensive ETS license
   1. Potentially using a KNX ‘Line Coupler’ device and a KNX cable connecting the buildings
   2. Alternatively using KNX ‘IP Router‘ devices (rather than KNX ‘IP Interface‘ devices; one per building) – which then connect the two KNX ‘lines’ via the IP network connection between the buildings
      1. In principle, this could be achieved using the https://github.com/knxd/knxd software (running on something like a Raspberry Pi) to implement the Routing, using an IP Interface device in each building talking to knxd

Other considerations:

• The existing ETS ‘Lite’ license is for ETS v5 but ETS v6 has been available for a while (and is already up to v6.3). An upgrade to ETS v6 will be required at some point anyway.
  • An upgrade from ETS v5 ‘Lite’ to ETS v6 ‘Lite’ costs €150
  • An upgrade from ETS v5 ‘Lite’ to ETS v6 ‘Home’ also costs €150
• There would be a benefit in being able to add further KNX devices to the House, above the limit of 20 imposed by the ‘Lite’ license – further KNX wall switches, for example
• The KNX ‘IP Router’ devices are relatively expensive (around £195) – and Routing KNX over IP would need two of those – whereas the KNX ‘IP Interface’ devices are cheaper (around £120)
• A KNX ‘Line Coupler’ is around £140.
  • These can be configured as a Repeater (like an Ethernet Bridge) to simply replicate all the KNX messages while electrically isolating the two cables
  • Or they can be configured as a Coupler (more like a Network Router), with rules determining which subset of messages get passed across
• A KNX installation consisting of even 64 devices is still considered ‘small’ and is well within the limits for even a single KNX line segment
  • The KNX cable runs are probably just short enough to allow this to all be cabled on one KNX line segment, but since there are separate buildings with separate mains electricity supplies (from the same grid connection and meter) it is best to keep them (electrically) separate

In the interests of keeping things simple, it seems best to consolidate everything into a single KNX Project, which means upgrading to the 64-device ‘Home’ license for ETS v6.

That leaves the question of whether to connect the buildings with a KNX cable (and a KNX Line Coupler) or whether to use an IP network connection between the buildings (which is required anyway, and will be a fibre optic cable) and two KNX IP Router devices. While KNX cable is pretty tough, and well-shielded, for an underground connection between different buildings it seems best to use something different (and less sensitive to interference) – which favours an IP connection and two KNX IP Routers.

One complication is that KNX IP Routers use a Multicast network address. This is straightforward to manage on a single LAN segment but more problematic when the traffic needs to pass through multiple IP Routers, such as are planned for the IP network connection between the two buildings.