← Journal
Security & Safety · 2 November 2026

Holiday mode on KNX: a house that looks lived in, not a house on a timer

Holiday mode on KNX: a house that looks lived in, not a house on a timer

Every December the same advice does the rounds. Put the lights on a timer, tell the neighbours, switch on the alarm. The advice is fine as far as it goes. Insurers and security companies in South Africa repeat it every year, and one of them (Dotsure) specifically recommends alarms, motion-sensor lights and timers for holiday trips.

What the advice never says is how the timer should behave. And that is the whole job.

A plug-in timer that switches the lounge lamp on at 18:00 and off at 22:00 does one thing well. It proves, after about two evenings of watching, that nobody is making the decision. Real people don’t turn lights on at the same minute every night. They come home late, they watch something, they go to bed early because of a headache. A house that behaves identically for twelve days in a row is not simulating presence. It is advertising an absence with extra steps.

I want to walk through what a proper KNX holiday mode looks like, what the options really are, and where the honest limits sit.

What presence simulation actually has to fake

Think about what someone walking past your gate can see or notice:

  • Which windows are lit, and when the lights come on
  • Whether the curtains or blinds move through the day
  • Whether the pattern changes from one day to the next
  • Whether the lights follow a route through the house, or just sit in one room
  • Whether the sun has set when the lights come on (Johannesburg sunset is around 18:30 in December and around 17:20 in June, so a fixed 18:00 start is wrong either way)

Notice what’s not on the list: noise, TV glow, cars. KNX can’t do those. What it can do is lights, blinds and gates, and those are enough to make a house look attended, as long as they don’t repeat.

The three ways to do it

From reading the KNX user forum threads on this topic and the product documentation, there are really three approaches.

1. Record and replay. The device watches the bus for a week, remembers which lights and blinds moved when, then plays the pattern back while you’re away. This is the one clients ask for first, because it is the most believable: it is literally how the house behaves when you live there. The classic hardware for this was the Siemens N345 DIN-rail module, which a forum poster describes as recording telegrams in the background for a week and replaying them. That same thread says it is no longer available, and that MDT told the poster none of their devices can record telegrams. Gira’s Homeserver is mentioned as doing continuous background recording. Gira’s X1, in the same thread, needs the recording started manually from the app. So record and replay exists, but it now mostly lives in servers and visualisation platforms, not in a cheap DIN-rail box.

2. Random switching inside a device. Some presence detectors have a simulation function built in. The forum thread names the B.E.G. PD11 DX, and a retailer listing for the PD2N-KNX RF detector also lists “presence simulation” as a feature. The catch, as that same thread points out, is that these switch randomly. They don’t replay what you do. Random is better than a fixed timer, but a random light that switches on in the guest bathroom at 03:00 is not a pattern any human produces. I could not find the settings for either product, so I can’t tell you what the random window is or which outputs it controls. Confirm that with the supplier before you spec one.

3. Build it from scheduling and logic. Astro timers for dusk, a handful of scenes, and a random delay on each step. The forum suggestion is a good example: a street-facing kitchen blind comes down to about 40% at dusk with the light on, plus an entrance light. Astro-based switching also follows the seasons for free, which matters for the sunset point above. The cost is programming effort. The MDT logic module gets a mention in the thread as a workable base for this, described as “ganz okay” by someone who has used it.

Of those three, I build number 3 for most clients, and I’ll explain why.

Why I lean on astro timers and logic, not a recorder

A recording captures how you lived last week. That is a strength and a weakness. If last week was a quiet week of homework and early nights, the playback is a quiet week of homework and early nights. If you were at your sister’s all weekend, the recording has a hole in it.

Designed behaviour gives me control. I decide which rooms take part, in what order, and what the limits are. A sensible holiday mode in a typical double-storey house looks something like this:

  • Dusk (astro, so it follows the sun): entrance light and one lounge scene on, with a random offset of 5 to 25 minutes so it moves each night
  • A second scene in the kitchen or study, later, again with a random offset
  • Upstairs bedroom light on, then off, at a believable hour
  • Everything off by a late cut-off with its own random window, with a few quiet nights where nothing upstairs happens
  • Blinds: the street-facing ones follow a daylight pattern, not all at the same minute, and not every day

Randomness alone isn’t enough. A random generator that treats 03:00 the same as 21:00 will eventually do something silly. So the window matters more than the randomness: random inside a believable band.

There’s a published example worth knowing about for the logic route. A HomeLYnk/SpaceLYnk community script does record-and-play with a random delay of up to 30 minutes on each replayed write, and modes for a single day, a weekday, a week or “always”. I’d treat that as an illustration of the method rather than something to install: it dates from 2017, the thread has no confirmation that it was tested, and the code as posted appears to contain logic errors. If a script like that goes on a client site, someone has to read and test it first.

The commissioning details that make or break it

These are the bits nobody tells you about until the first holiday.

One switch for the mode, with feedback. A single “Away” object, set from a keypad by the front door, from a phone or from a schedule. It needs visible status. If the family leaves on Saturday and the mode never started, nobody will know until a neighbour mentions it. A keypad LED that shows “holiday mode active” fixes that.

Don’t let the mode fight the people. If a house-sitter or a domestic worker is on site, the simulation must not switch lights off on them. Sort that before you leave: either a presence override or a mode that only touches the rooms nobody uses.

Power cuts reset things. In South Africa this isn’t theoretical. After a power cut, the actuators come back to whatever their power-return behaviour says. If the dusk scene was meant to be running and the logic module restarts with no memory of the mode, you can come back to a house that sat dark for ten days. The mode state should be stored, or restored on power return, and you should test that by pulling the supply, not by reading the parameter list. (This is the same lesson as the 2am power return post: the restart is part of the design.)

Keep it to the rooms a burglar can see. The back bathroom with no window adds nothing. Spend the effort on the street side.

Test it before you leave. Run the mode for one evening while you’re home, from the road, and look at the house. Then check it again from a phone. A holiday mode that you have never watched is a guess.

What it won’t do

It won’t replace an alarm, a response service or a neighbour. It’s one layer. It also only controls what’s on the bus. A house with a few Wi-Fi lamps in the lounge and KNX everywhere else will have a hole in the simulation exactly where the lamps are.

And I’ll say plainly: I’ve not found a current, mass-market KNX DIN-rail device that records and replays telegrams, and the forum evidence suggests the old ones have gone. If your client insists on true record and replay, expect a server or visualisation platform doing the work, and price that in.

The takeaway

A holiday mode is a design job, not a feature you tick on. The difference between a house that looks occupied and one that looks scheduled is a few random windows, a sunset-based start, a couple of blinds, and a fixed rule about what happens after a power cut.

If you’re planning a build or a renovation and want this on the schedule before the walls close, it’s cheap to plan and awkward to bolt on later. Just a conversation about what the project needs: wayne@knxlogic.co.za | 082 564 3982 | www.knxlogic.co.za

Sources