After a power outage your C-Bus scenes or timers behave strangely

Nine times out of ten when a customer rings us the morning after a Melbourne storm saying “my C-Bus has gone haywire,” the first thing we tell them is the most reassuring: your programming is almost certainly fine. C-Bus output units \u2014 your relays and dimmers \u2014 store their settings in non-volatile memory. That means group addresses, levels, ramp rates and scene logic all survive a blackout without a battery. A flat or interrupted supply doesn’t wipe any of that.

So if scenes, timers or lights are behaving oddly after a power outage, the cause is nearly always time or state related rather than lost programming. Let’s walk through exactly what happens when the power comes back, what’s normal, and how to sort out the handful of genuine faults.

What actually happens when the power returns

When mains is restored, every C-Bus unit on the pink cable wakes up and re-announces itself on the network. The system power supply (such as a 5500PS) re-energises the network, the clock unit (or your Wiser Home Controller) starts keeping time again, and the loads settle into whatever power-up state they’re configured for. This handshake isn’t instant.

That settling period is the single most common reason for “strange” behaviour. A light flicks on for a second, a scene looks half-applied, or a timer seems to misfire \u2014 and then a minute later everything is fine. In a lot of cases there was never a fault at all; the network simply hadn’t finished re-establishing yet.

Suspect the clock first

The most frequent real culprit is the system time. Time-of-day events, and especially sunrise/sunset triggers, all rely on the network clock being correct. If a brownout or extended outage knocked the clock out, time-based events will fire at the wrong moment \u2014 the garden lights come on at 2pm, the “goodnight” scene runs at lunchtime, or nothing fires at all because the controller thinks it’s the wrong day.

Importantly, this looks like a programming fault but isn’t. The scene is perfect; it’s just being told the wrong time. Where the time lives depends on your system:

• Dedicated clock unit / DIN-rail timeswitch: these keep the network time and date for the whole C-Bus. After a long outage the time can drift or reset, and only one device should ever be the network clock to avoid clashes.
• Wiser Home Controller: the Wiser is usually the timekeeper and pulls time automatically once it’s back on your network and the internet. If your NBN gear is still rebooting, the Wiser may briefly run on an old time until it syncs.

How to check and correct the time

1. Open your controller interface. On a Wiser, log into the Wiser Home Controller web interface or app and check the displayed system time and date against your phone.
2. Confirm the time zone and daylight saving. Melbourne is AEST/AEDT \u2014 a wrong time zone or stuck daylight-saving setting will throw sunrise/sunset events out by an hour. Schneider Electric’s Clipsal support resources have the current Wiser firmware notes if yours looks out of date.
3. Let it re-sync. Once the network and internet are back, give the Wiser a few minutes to pull the correct time before forcing anything manually.
4. For a standalone clock unit, the time is set via C-Bus Toolkit or the unit’s own interface. If you’re not comfortable in Toolkit, this is exactly the kind of thing our team sorts remotely or on a quick visit.

Once the clock is right, watch your next scheduled event. If it now fires on time, you’ve found and fixed the problem \u2014 nothing was ever broken in the programming.

Lights that come on (or stay off) on their own

The second classic after a blackout: a particular light comes on by itself when power returns, or a circuit that you expected to come back on stays stubbornly dark. Again, this is usually intended behaviour, not a fault.

Every C-Bus relay and dimmer channel can be given a defined power-up state \u2014 what level it should go to when supply is first applied. Common choices are “off,” “on,” “last level,” or a specific percentage. So:

• A hallway or porch light configured to power up on is doing its job \u2014 handy for safety after an outage at night.
• A bedroom light that stays off on power-up is also doing its job, even if you’d rather it remembered the last level.
• A dimmer set to “last level” will return to whatever brightness it was at when the power dropped.

If you don’t like the default, it’s an easy change in C-Bus Toolkit on the relevant output unit (for example an L5504D2U dimmer channel). We can adjust the power-up behaviour per channel so your home behaves the way you actually want after a blackout. Have a read of our notes on C-Bus lighting and dimming for how levels and ramp rates tie into this.

When scenes are genuinely wrong, not just mistimed

So far everything has been time or state related. But occasionally a scene is truly misbehaving \u2014 the wrong lights respond, levels are off, or a button does something completely different from before. If the timing is correct but the behaviour is wrong, the C-Bus units are rarely to blame, because their programming survived the outage. Suspect the controller instead.

A Wiser Home Controller (or any logic/automation controller) is essentially a small computer. After a brownout \u2014 that nasty half-second voltage dip that’s worse than a clean blackout \u2014 a controller can fail to reboot cleanly. It may come back up with logic only partly loaded, schedules half-running, or its database in an odd state. That produces exactly the “my scenes are wrong” symptom, while the relays and dimmers behind it are perfectly healthy.

The clue is the split: simple manual switching (pressing a wall switch to toggle a light directly) usually still works, because that’s handled on the C-Bus network itself. It’s the clever stuff \u2014 scenes, schedules, conditional logic that runs through the controller \u2014 that goes strange.

A safe full power-cycle of the controller

The fix for a controller stuck after a brownout is usually a clean, deliberate power-cycle. This is different from the messy interrupted restart the outage gave it.

1. Identify the controller’s supply. On most installs the Wiser or controller is fed from a labelled circuit in the switchboard or a local DIN-rail supply. If you’re not sure which one, stop here and call us \u2014 don’t go poking around the board.
2. Isolate it cleanly. A licensed electrician (or our team) switches off the controller’s supply at the board. Leave the rest of the C-Bus and lighting on \u2014 you only need to cycle the controller.
3. Wait a good 30 to 60 seconds. This lets capacitors fully discharge so the device gets a genuine cold start rather than a half-warm reboot.
4. Restore power. Switch the supply back on and let the controller boot completely \u2014 this can take a couple of minutes for a Wiser to reload its logic and reconnect.
5. Re-test. Trigger a known scene from a wall switch and from the app. If scenes now behave correctly, the controller simply needed a clean restart.

Still odd after all that?

If you’ve corrected the clock, allowed the network to settle, confirmed power-up states are intended, and cleanly power-cycled the controller \u2014 and a scene is still wrong \u2014 then it’s worth a closer look in C-Bus Toolkit. We’d check the network clock isn’t being driven by two devices, look for a unit that didn’t rejoin the network, and verify the controller’s logic loaded its last saved version. For the deeper diagnostics, see our C-Bus troubleshooting guides, or get in touch and we’ll log in.

The big takeaway: a blackout doesn’t erase your C-Bus programming. Strange behaviour afterwards is almost always the time being wrong, loads following their configured power-up state, the network mid-handshake, or a controller that didn’t reboot cleanly \u2014 all of which are quick to sort.

If your scenes or timers are still playing up after a Melbourne outage, give us a shout. The DUKE team has cleaned up plenty of post-storm C-Bus systems and we’ll get yours behaving again \u2014 reach us any time via our contact page. Cheers, Adam and the DUKE team.