Why we keep a backup of your C-Bus programming

When we hand over a finished C-Bus system, one of the questions we get asked most is, “So where does all the clever stuff actually live?” It’s a fair question. You flick a switch labelled “Kitchen Downlights”, a scene called “Movie Night” dims half the house, the verandah lights come on at sunset — and it all feels like it’s somehow baked into the walls. It isn’t. The brains of your system live in a project file, and keeping a safe, current copy of that file is one of the quietest but most important things our team does for you.

This article explains what that project file is, why we keep a backup of yours off-site, and what would happen if we didn’t.

Your system is a project file, not just the switches

Every C-Bus installation is described by a single project that’s built and managed in C-Bus Toolkit, the Clipsal commissioning software our team uses. That project holds everything that makes your system yours:

• Every unit on the network — your output units (the relays and dimmers in the switchboard, e.g. an L5504D2U dimmer), your input units (Saturn, Saturn Zen, Neo and DLT/eDLT wall switches), the system power supply and the network interface.
• Every Group Address — the logical “channels” that tie a switch button to the right lighting circuit on the Lighting application (56).
• Your tags and labels — the human-readable names like “Master Bed Bedside” or “Alfresco” that turn a sea of numbers into something we (and you) can actually read.
• Your scenes, schedules and logic — the ramp rates, the levels (0–255), the triggers and the timed events that make the system behave the way you asked.

The wall switches and output units do store their own working configuration, which is why your lights keep working even when nobody’s plugged a laptop in for years. But the switches don’t store the whole picture, and they certainly don’t store the friendly names and the design intent behind it all. That lives in the project. Lose the project and you’ve lost the map, even if the territory is still standing.

How Toolkit backs a project up

Toolkit deals with two file types you might hear us mention, and it’s worth knowing the difference.

• A .cb3 file is the live project file — it’s what we open and edit when we’re working on your system in Toolkit.
• A .cbz file is a compressed backup archive that Toolkit creates from a project. It bundles the project up into a single, portable file that’s easy to store and easy to restore from. Think of the .cbz as the sealed, dated snapshot we put in the vault.

When we commission or change your system, we export a .cbz, and when we ever need to rebuild, we restore the project back into Toolkit from that file. It’s a clean round trip: the configuration we read off your network goes into the archive, and the archive comes back out exactly as designed.

Why we keep your backup off-site

Here’s the part that matters to you as the homeowner. We hold a current copy of your project file off-site, away from your house, so that whatever happens to the hardware, the design survives.

Nine times out of ten when a customer rings us in a panic, it’s one of three things:

• A fault or failure. An output unit gives up, or a network interface dies. We swap the hardware, restore your project, and the new unit picks up its old identity, group addresses and levels.
• A lightning strike or surge. Melbourne summers do this more than people expect. A nearby strike can scramble or kill units on a network. With your backup in hand, we’re rebuilding from a known-good design rather than guessing.
• A switchboard change. Sometimes a board gets upgraded, expanded or rebuilt and units come out and go back in. Restoring from the backup means everything lands back exactly where it belongs.

In every one of those cases, having your project file turns a potential nightmare into a routine service call.

What happens if there’s no backup

We get called out to systems installed by others where no project file exists anywhere — not on a laptop, not in an email, nowhere. When a controller or network interface fails on one of those, the options get grim fast.

Without a project, rebuilding means starting from a blank Toolkit project and reverse-engineering the entire system: scanning the network to find what units are present, working out which group address drives which circuit, re-creating every scene and schedule, and — the slow killer — re-typing every single tag and label by hand because there’s no record of what anything was called. On a decent-sized home that’s not minutes, it’s hours, and hours are billable. You end up paying to recreate something you’d already paid to have built.

It’s also rarely a perfect rebuild. Subtle things — a particular ramp rate, a scene level someone fine-tuned over a year of living in the house — are gone, and we’re left asking you to remember exactly how “Movie Night” used to feel. A backup removes all of that pain.

Your room and circuit names survive too

People underrate this one. The tags in your project — “Pantry”, “Stair Wall Washer”, “Pool Pump” — aren’t just labels for us; they’re the documentation of your whole system. After a repair, restoring the backup means your rooms and circuits come back with their proper names, so the next time anyone (us or another sparky) needs to work on it, the system reads like a book instead of a puzzle. If you’ve ever inherited an undocumented system, you’ll know how much that’s worth.

If you’d like to understand more about how tags and group addresses fit together, we cover that in our C-Bus programming articles, and there’s helpful background on the network side in our C-Bus network section.

We keep the backup matched to your live system

A backup is only useful if it reflects reality. So our rule is simple: whenever we make a change to your system — add a circuit, re-tag a room, tweak a scene, expand the board — we update the held copy at the same time. That way the .cbz we have on file always matches what’s actually running on your network. A stale backup that restores last year’s house isn’t a backup, it’s a trap, and we don’t keep those.

This is also why we ask you to let us know if anyone else has been into the system. If another integrator makes a change and we’re not told, our copy drifts out of date. Keeping one team across the programming keeps the backup trustworthy.

For technicians: good housekeeping

If you’re a fellow integrator, the same discipline applies. Export a fresh .cbz after every commissioning session, store it off the commissioning laptop, and version it by date and site so you can prove which snapshot is current. Read the network back before you archive so the file reflects the live units, not just your intended design. And keep the tags clean in Toolkit — future-you, restoring under pressure after a callout, will be grateful. Clipsal’s own documentation on Toolkit project management is a good reference; you’ll find it via the Clipsal C-Bus pages.

The short version

Your C-Bus system is defined by a project file, not by the switches on the wall. Toolkit lets us archive that project as a .cbz and restore it from a .cb3 when we need to. We keep a current copy off-site, we update it every time we touch your system, and that single habit is the difference between a quick repair and an expensive rebuild after a fault, surge or board change.

Thanks for reading — looking after the boring-but-vital stuff like backups is part of how we look after our customers properly. If you’re a Melbourne C-Bus owner and you’re not certain a current backup of your system exists, drop us a line via our contact page and we’ll sort it out for you. Cheers, Adam and the DUKE team.