Category Archives: KNX

PIR Sensors for Lighting Control in the Outbuildings

Posted on by
Reply

The house has PIR sensors to control lighting in the hallways / landings and bathrooms. These are Danlers PIR Occupancy Switches; model CEFL PIR in dry locations and CEFL PIR SEALED in bathrooms. These take a 230V live input and switch that with a relay for the output. They’re intended to directly switch 230V lighting (and are rated for 6A of resistive load) but they’re wired to a KNX ‘Binary Input’ bank which senses the switched 230V and is configured to control the relevant (DALI-dimmable) lights.

A key reason for adopting this approach was the limit of 20 KNX devices within an installation imposed by the (relatively) affordable KNX ‘ETS Lite’ software license used to program the home automation system – there’s only one KNX device (the Binary Input sensor), whereas there would have been 12 if these had been native KNX presence sensors. The Danlers sensors are about £45 each, whereas native KNX presence sensors are getting on for double that.

In the Ground Floor Hallway, which is relatively long and thin and is typically approached from the Front Door / Living Room (at one end) or the Kitchen / Family Room (at the other end) there are two sensors – about 1/4 the way from each end. These effectively operate ‘in parallel’ and the first one to trigger switches the lights on. This configuration works well.

While they function as intended, slight niggles with using the 230V Danlers PIR switches include:

  • Despite the Danlers units being a well-regarded, British-made product (with a 5-year warranty) roughly 1/3 of them have failed. Two were repaired under warranty – but failed again (and were then replaced under warranty) and two more failed outside warranty.
  • They operate with a very distinct ‘click’ from the 230V relay, which in some cases is A Good Thing – e.g. visitors using the windowless downstairs bathroom hear the ‘click’ as soon as they open the door, while they’re looking for the light switch – but it can be annoying in other rooms.
  • Since there’s no manual switch to choose to press (or not), the sensors always trigger when they sense movement – whether or not that’s intended or desirable
    • In en-suite bathrooms it’s annoying to have the lights come on at full brightness in the middle of the night – but they need to be bright at other times of day
    • The basic sensors can’t do anything different at night, so there’s an Automation rule in Home Assistant which reacts to the Binary Input sensor and does different things depending on whether it’s considered ‘night’ or not – which means some of the lighting is reliant on Home Assistant working correctly and is hence less robust than native KNX operation would be

For the Outbuildings, there’s a rather more modest requirement for automated lighting control than in the House – just the Shower Room and the Plant Room, both of which receive no natural light and which have Switched (rather than Dimmable) lights. Now the KNX device limit is higher (up to 64 devices in a single installation, using the ‘ETS Home’ license tier), using native KNX presence sensors seemed a better way to go – avoiding the need for a ‘Binary Input’ module (which have a high cost-per-input in small sizes). Since the Shower Room sensor needs to operate in a humid environment that needs to be ‘sealed’ to some extent, which limits the choice of MDT-brand sensors to pretty much just the MDT SCN-P360L2.03 which provides 360-degree coverage with two PIR sensors and is IP44-rated. (The Plant Room sensor is identical, even though it doesn’t need the IP44 rating.)

These sensors offer a range of additional flexibility:

  • They can take an input to specify Day versus Night, and do different things depending on the setting, without needing to rely on an Automation rule in Home Assistant
  • They can be adjusted in terms of their sensitivity threshold for presence / occupancy
  • They can provide logic to maintain overall lighting levels, taking advantage of natural light where that is available (and running artificial lighting at reduced brightness) then adding more artificial light when the natural light level reduces
  • They can provide an output to a HVAC system, with different configuration settings from the lighting outputs
    • For example, in the Shower Room, this could be used to change the fan speed on the MVHR system – either via a switched output or a ‘dimmable’ 0-10V controller

It remains to be seen how well the KNX PIR sensors operate in practice but so far I’m impressed by their specification, their small size, and the configuration options available. While it would be difficult to retro-fit these into the House (since the existing sensors use 230V Twin&Earth cabling, which would need replacing with KNX Bus cabling) I’d be inclined to use native KNX sensors in the House if starting again.

KNX IP Interface Upgraded to KNX IP Router Secure

Posted on by
3

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:

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.

The configuration screen for KNX Secure Tunneling in Home Assistant – note the help text under each field

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.