Lost C-Bus programming or needing to re-download the project

When a customer rings us saying “half my switches stopped working” or “the labels on the DLT have gone blank and the scenes do nothing”, nine times out of ten it isn’t dead hardware — it’s lost or corrupted programming in one or more units. Output units (relays and dimmers) can occasionally drop their Group Address assignments after a brownout, a botched firmware step, or someone poking around the network with a half-baked project file. The good news for a technician: if you’ve got the project, this is a quick recovery. The bad news if you haven’t: you’re rebuilding from the live network before you can do anything.

This article walks through the recovery sequence we use on site, from confirming the programming is genuinely gone, through working from the correct project file, re-downloading to the affected units, and verifying everything came back — including those fiddly DLT labels.

Step 1: Confirm it’s actually lost programming

Before you transfer anything, prove the diagnosis. A unit that’s simply offline (no clock, no power, a pulled connector) looks a lot like a unit that’s lost its programming, and the fix is completely different. Don’t reach for the project file until you’ve scanned the network.

1. Connect to the network through your PC interface (PCI 5500PC, the 5500PCU USB, or a CNI 5500CN over Ethernet) and open C-Bus Toolkit.
2. Run a full network scan. Note which units respond, their unit addresses, firmware and tag names. A unit that doesn’t appear at all is a connectivity or power problem, not lost programming — chase that first.
3. For units that do respond, read the live contents and compare them against your saved project file. You’re looking at the Group Addresses assigned to each channel, scene levels, ramp rates and DLT button programming.
4. If the live unit shows default or blank Group Addresses where your project expects assignments, you’ve confirmed lost programming on that unit.

If you’re not even getting a clean scan, sort the network first — clock, burden and interface issues all masquerade as missing programming. We cover that in our C-Bus troubleshooting and C-Bus network articles.

Step 2: Always work from the current project file

This is the rule that saves jobs: never download an old project on top of a live network you don’t fully understand. The units on site may be newer than the copy on your laptop. Maybe another tech added a couple of scenes last year, maybe the homeowner had a circuit changed. If you transfer a stale file, you’ll happily overwrite all of that and turn a one-unit fault into a whole-house rebuild.

1. Pull the latest project from the site’s documented backup location — our off-site dated backups, the customer’s handover USB, or wherever the last tech stored it.
2. Check the file date and any change notes against what you can see live on the network during your scan.
3. If the live network has tags, scenes or addresses that aren’t in your file, the file is out of date. Upload from the network to capture those changes before you push anything back (see Step 4).
4. Once you’re confident the project matches the live network — except for the unit(s) that lost programming — you’re clear to re-download.

Step 3: Re-download (transfer) the project to the affected units

With the correct, current project open, transfer it to the units that lost their programming. You can target individual units rather than the whole network, which is faster and lower-risk.

1. In Toolkit, select the affected unit(s) in the project tree. Right-click and choose to transfer/download the unit programming.
2. Confirm you’re transferring the full unit contents — Group Addresses, scene levels, ramp rates and, for DLT/eDLT switches, the button labels and group assignments.
3. Let the transfer complete without interruption. Don’t pull the interface or kill power mid-download — that’s exactly how units end up half-programmed and confusing the next person.
4. For a DLT or eDLT, the label text and icon data is part of the same transfer. If you only push the Lighting application (56) groups and skip the unit’s display data, the buttons work but the labels stay blank.

For output units, the re-download restores which Group Address each channel responds to and at what level and ramp rate. For DLT switches, it restores which button drives which group, the scene buttons, and the on-screen labels. Once the transfer finishes, the unit should rejoin the network with its full personality back.

Step 4: No project file? Rebuild from the live network first

Sometimes there’s no project file at all — an old install, a system someone else commissioned, a customer who’s lost the handover. You can’t re-download what you don’t have, so you build the project from the network before you can push anything back.

1. Scan the full network in Toolkit and let it discover every unit.
2. Upload (read) the programming from each live unit into a fresh project. This captures the Group Addresses, scenes and DLT data that are currently in the hardware.
3. Tidy and tag the project as you go — name the groups, name the units, document the network so it’s actually usable next time.
4. Save this as your new master project file. Now you have something to re-download from, and a baseline backup.

If you’re newer to building projects up from a live scan, our C-Bus programming notes walk through tagging and structuring a project cleanly.

Step 5: Verify the recovery

A transfer that reports “success” isn’t the same as a working system. Test it properly before you leave site.

• Check the labels refreshed. Walk to each DLT/eDLT and confirm the button text and icons came back. Blank or mismatched labels almost always mean the DLT display data didn’t transfer — re-download the unit’s full contents, not just the group assignments.
• Test every scene. Press each scene button and confirm the right channels go to the right levels at the right ramp rate. A scene that fires the wrong lights points to a Group Address mismatch still lurking.
• Test individual loads. Toggle each channel and confirm the correct light or load responds.
• Re-scan and confirm all units are present, clocked and error-free.

If labels stay stubborn after a full unit transfer, double-check you’re targeting the right unit address and that the project’s DLT data isn’t blank itself — an uploaded-from-network project won’t always carry full label text if the original was poorly tagged.

Step 6: Back it up off-site so this never costs you a full rebuild again

The whole reason a lost-programming fault is sometimes a nightmare is a missing backup. Once you’ve recovered, fix that for good:

1. Save the verified, current project with a clear dated filename (site name plus date).
2. Store one copy off-site — our cloud backup — and leave one with the customer.
3. Note any changes you made in the project comments so the next tech understands the history.

Do that, and the next time a unit drops its programming the job is a ten-minute re-download instead of a half-day rebuild. Clipsal’s own resources on C-Bus Toolkit and project management are worth a read too — see the Clipsal C-Bus pages for current documentation.

That’s the recovery we run on every lost-programming call: confirm it’s real, work from the current file, transfer to the affected units, verify labels and scenes, and back it up so it can’t bite twice. If you’re a Melbourne homeowner staring at dead switches and no idea where your project file lives — or a fellow integrator who’d rather we handled the switchboard side — give our team a shout via our contact page and we’ll sort it. Cheers, Adam and the DUKE team.