Category Archives: Home Automation

KNX Home Automation Failure – Fixed

Posted on by
Reply

5 years after installation I’ve just encountered the first significant failure of the home automation system. The KNX module that monitors the momentary-action ‘light’ switches in the bedrooms stopped responding. Upon checking the unit all of its LEDs were flashing on about a 1-second cycle, so it wasn’t completely dead, but it clearly wasn’t happy. Turning it off and on again didn’t help.

The module is a 16-Channel Binary Input Module for Potential-Free Contacts, made by MDT in Germany. Searching for reports of similar problems turned up a couple of posts (in German) on https://knx-user-forum.de/ that hinted at a firmware bug. These devices come with a generous 3-year warranty, but I confirmed the purchase date and it was May 2016. A new replacement unit would be about 200 GBP.

I contacted MDT Support who confirmed there was nothing further I could do as an end-user and suggested I send the unit back to them for repair. They expected it would just need new firmware loading.

Sadly, thanks to Brexit, sending devices for repair in the EU is much more complex than when the UK was in the Single Market. The principal consideration is avoiding the imposition of either Import Duty or VAT – either when the package is going to Germany or coming back to the UK. (These would apply to the initial purchase, but because all applicable taxes had been paid in 2016 they do not need to be paid again, since nobody is making a new purchase.) I found little useful guidance on the Royal Mail or HMRC websites but stumbled across this very useful post from Mura Car Accessories, based in Romania and followed those instructions carefully – with good results. (A key step seems to be declaring a Temporary Export for Repair Purposes on the C22 form.)

The delivery of the repaired item was delayed because of an issue recording the UK (alphanumeric) postal code in one of the German systems (some mix-up between MDT and UPS, by the look of things), but it was delivered today and simply needed re-installing and re-programming. I am grateful to MDT for not charging for either the repair or the return shipment, so I got a good-as-new device for just the 7.50 GBP outward postal charge.

While the unit was away for repair, none of the wall switches were working, which was slightly annoying but actually highlighted a strength of KNX’s modular architecture. All of the rest of the home automation system continued to work perfectly and a simple workaround was to control the bedroom lights with the openHAB iPhone app instead – which still triggered the openHAB rule that sets ‘Night Mode’ when the bedside lights are turned off.

KNX Automation Safety Interlock

Posted on by
Reply

Background

The electric roller blinds for the electrically-operated clerestory windows in the office are a relatively recent addition. The summer sun is naturally shaded by the roof overhang but in spring and autumn the mid-morning sun comes in and it’s good to have the option to keep that off the computer screens. The complication is that if the windows are open and the blinds try to close they’ll get caught in the window mechanism; similarly (though less of a problem) if the blinds are down but the windows try to open they’ll push the blinds out of the way.

If the clerestory windows in the office are open the blinds won’t close

This isn’t a huge problem when controlling everything manually but with the blind closing being automated (at sunset) there’s a significant risk of the windows being open when the blinds try to close.

Fortunately, I remembered seeing some quite comprehensive integration options for the KNX control actuators for the windows and (especially) the blinds which can automatically ‘block’ a request to move either the blind or the window if the other unit is in an incompatible position. (On balance, this seems the better way to go – rather than trying to automatically close the windows when trying to close the blinds; the windows are open for a reason.)

KNX Actuator Details

The window motors and the blind motors are electrically almost identical – they’re 230V AC devices with four-wire cabling (two switched Live connections – one for Close and another for Open – plus Neutral and Earth). In terms of KNX control these all treated as ‘Shutters’ and generally they’re either fully Open or fully Closed although it’s possible to open them to e.g. 25% or 66% (which is achieved by running the motor for the relevant portion of the time taken to fully open or fully close).

The KNX control actuators for the Blinds are MDT JAL-0810.02 units (Shutter Actuator 8-fold, 8TE MRDC, 230V AC, 10A) whereas the control actuator for the Windows is a MDT AKU-1616.01 (Universal Actuator 16-fold, 8TE MRDC, 230V AC, 16A). The only reason for these actuators being different models is that there are 5 windows which is an annoying number when the actuators come in 2-, 4- or 8-way variants. The more flexible AKU actuator allows adjacent pairs of channels to operate as Up / Down Shutter controllers (with the same functionality as a JAL actuator) which consumes 10 of the 16 ways; the other 6 ways are then available to be used as simple relay switching channels (some are connected to non-dimmable lighting circuits).

The actuators can be configured to respect a set of ‘Alarm’ inputs – for Wind, Rain and Frost (as reported by a KNX-connected weather station) and either close or open in response to those inputs – presumably to e.g. close windows if it starts raining. There’s also an option to configure automatic blind adjustment to block out direct sunlight. Those are all more complex than I’m looking for here – basically I want to stop the blinds closing unless the windows are already closed.

Control Logic Implementation

The desired logic is relatively simple:

  • For the blinds: ignore any request to close the blinds unless the window is already fully closed
  • For the windows: ignore any request to open the window unless the blind is already fully open

The ‘block’ input on the controller channel is a 1-Bit data input type so it needs to be connected to a 1-Bit output. The position of the window is reported via “Status current position” but that is a 1-Byte output showing the position as a percentage, but there’s also “Status upper Position” and “Status lower Position” which are 1-Bit values. When closed, the window is considered to be in its “upper” position.

Finding a combination of settings that worked as required took a bit of trial and error but I’m currently running the configuration shown in the screenshot from ETS (the KNX configuration software) below.

KNX ETS Group Address links for Blind 'Blocking'
KNX ETS Group Address links for Blind ‘Blocking’

In summary:

  1. There needs to be a new Group Address, in addition to the normal 5 addresses used for these shutters; I’m using the 6 address and calling that “Status Closed”
  2. The input comes from the “Status lower Position” indicator on the Window
    • The status bit gets Set when the window is fully open, which is normally the case when the windows are open for ventilation but leaves open the possibility of the blind trying to close when the window is e.g. 90% open
  3. The output goes to the “Block functions” setting on the Blind, causing the blind to ignore all commands while this bit is Set

In order for the “Block functions” item to be available, it’s necessary to enable it in the Parameter settings for the relevant Channel on the Controller. In particular, the “Advanced function” needs to be “active”.

Parameter page for “Alarm and block functions”

Then, under “Advanced block functions”, activate the Object “Block functions” and specify that this should block manual operation. On reflection, it’s probably better to block all the manual operation items.

Parameter page for “Advanced block function”