Skip to content
CASIENT
←  KNX notes

Why does writing a handover document take a week when the project has it all?

Your ETS project already knows the rooms. Your handover pack does not.

There is an integrator-facing version of an argument we have made to owners before. This one is about the two days you spend after the job is finished.

Note
06 / 06
Reading
5 min
Updated
September 2026
For
Integrators

The two days nobody quotes for

The job is finished. The client wants documentation. What you have is an ETS project, a switchboard photo, and a memory of decisions made across several months.

So the handover pack gets written by hand — transcribing structure that already exists, in a format nobody can read, into a format nobody will check. Or it does not get written, and you carry the house in your head instead, which works right up until the client rings about a room you last thought about in March.

What is already in there

More than most people use. A .knxproj carries, as structured data:

  • The building. Buildings, floors, rooms, distribution boards — the structure somebody already typed in during commissioning.
  • The devices, with manufacturer, order number, individual address, and which board and room each one sits in.
  • The address map, and which objects on which devices are bound to it.
  • The parameters. Every value inside every device: hold times, staircase timers, thresholds, scene tables, sun-protection settings, lock and priority behaviour. On our reference installation that is 1,403 values, resolved in full.

That last one is the interesting category, and it is the one that never makes it into a handover document written by hand.

The behaviour that is already running

Parameters are not settings. They are automation, executing on the actuator itself, with no controller involved.

A staircase timer is an automation. A presence off-delay is an automation. A scene table is a set of automations. A central-off, a sun-protection threshold, a lock behaviour — all automations, all running today, all invisible unless somebody opens the device and reads the parameter.

On the reference installation the check finds 21 behaviours already running on the devices themselves, 12 of them sensor-driven, and none of them written down anywhere. That is a normal project, not a bad one.

This matters to you commercially in two directions. It is the most impressive thing you can put in front of a client — a list of what their building does on its own, which nobody has ever shown them. And it is the thing that makes the next callback cheap, because “why does the hall light stay on for ninety seconds” has an answer with an address and a parameter name attached to it.

It also finds what is wrong

The same read surfaces the things you would rather know before the client does. The example we publish is four rooms whose detectors hold the lights for ten seconds — the detector’s own minimum — where the manufacturer’s manual says “a value below 30 seconds is not recommended in rooms where people remain stationary.”

That is not our opinion. It is the device’s parameter table read against the manufacturer’s own datasheet. It is a two-minute fix in ETS and an awkward conversation avoided, and no integrator who has not read their own parameters can be certain it is not in their project too.

Nothing of ours goes in the pack

Said plainly because it is the question worth asking of anyone offering this.

The handover document is generated from your project and issued under your name. There is no Casient branding inside it by default. If you want us named because it strengthens your position, that is a choice you make, not one we make for you — and we do not market to your clients.

Your client is your relationship. Using your credibility to reach them would be the fastest way to lose ours.

What the check does with this

Upload the project and the handover document comes back with the findings: the building structure, the device schedule room by room, the parameters resolved, and the behaviour already running in the installation.

The project then stays in your workspace. When the client rings in eighteen months about a room you have not thought about since commissioning, the answer is a search rather than an archaeology expedition — and if you have since changed the project, the revision diff tells you exactly what moved between the file you handed over and the one in front of you now.

What the check reports for this

A handover document generated from the project — building structure, device schedule, and the device-local behaviour that appears in no documentation.

Upload a .knxprojFree, permanently · no card · ≈ 60 s