The project file is lost

Nobody has the file, nobody knows who installed it, and the trail has gone cold. This is the defining problem of an inherited C-Bus system, and it is worth being clear about what it does and does not mean.

What the project file actually is

When a C-Bus system is commissioned, the installer builds a file that describes it: every unit, its address, what each key does, every group and scene, and, most valuably, the names a human typed in. "Kitchen pendants" rather than an address. That file is the map. The system runs perfectly without it, in exactly the same way a city works without a street directory, and just as it is much harder to direct anyone anywhere without one.

Look properly before paying to rebuild it

An hour of searching regularly saves a four-figure exercise. In rough order of how often it works:

• The house documents. The folder of manuals and warranties left by the previous owner. A CD or USB stick in there is exactly what you are looking for.
• Any old computer from the house, including a dead one. The drive is usually fine even when the machine is not.
• The previous owner. A direct ask, by email so they can forward an attachment. Worth doing even years later, and frequently successful.
• The original installer, if any paperwork or a sticker inside a cupboard names them. Many keep project files for old jobs indefinitely.
• Your conveyancer's file or the building report, which sometimes carries handover documentation nobody read.
• Inside the enclosure. Some installers taped a disc or a printed schedule to the inside of the door. Do not open it yourself: ask whoever is doing the work to look.

What recovery involves if it is genuinely gone

Toolkit can scan a live C-Bus network and interrogate it. Every unit reports what it is, what address it holds, and how it is configured. From that scan an integrator rebuilds a working project file that accurately describes your system.

What comes back is the structure and the behaviour. What does not come back is the naming: the scan finds a unit at an address and knows it drives certain channels, but it does not know that channel four is the kitchen pendants. Recovering that means someone walking the house, operating each channel, and writing down what lit up. That walk is most of the labour in a recovery, and it is why the job is quoted in hours rather than as a fixed price.

The system keeps working

A scan is a read operation. Your lights carry on as normal throughout, and nothing is put at risk to do it.

You get a real file at the end

The output is a project file you own. Get a copy of it, and store it somewhere that is not one laptop.

It is a one-off

Once recovered, future changes start from the file rather than from a scan. Every later job is cheaper for it.

Custom logic is the exception

Logic written for a touchscreen or controller does not live in the network units and cannot be recovered by scanning. If that machine is gone, that behaviour is rebuilt from a description of what it used to do.

Worth doing even without a fault

If your system works and you simply have no file, there is a decent argument for having one made anyway. It converts an opaque system into a documented one, it means the next fault is diagnosed rather than explored, and it removes the thing that makes electricians decline the job. It also travels with the house, which is worth something when you sell.

What it does not mean

It does not mean your system is unsupportable or that replacement is the sensible option. The absence of a file is a documentation gap, not a hardware condition. Anyone quoting a rip-out on the grounds that there are no files is quoting for their own convenience: see what replacement really costs and who can actually reprogram a C-Bus system.

← Start the diagnoser again