Bus Coupler Power Up

Hi

I am having trouble getting a reliable outcome from a 5104BCL when power is restored after a power failure.

Channel 1 of the bus coupler takes an input from an access control keypad to trigger a C-Bus relay which opens the garage door (via an OSC input to the door controller).

Channel 2 of the bus coupler takes an input (clean contact) from a smoke detector interface to turn a 'panic' group address on when the detectors are triggered.

All channels on the bus coupler are set to restore to preset levels at 0%.

At 2am this morning, the client had a brief power failure and the panic lighting came on and the garage door opened! When I arrived at site the client had already used a C-Bus switch to operate the garage door but the Panic group was still on. Obviously they turned on at powered up.

The key functions on input 1 are programmed as:

SP - On Key
SR - Off Key
LP - On Key
LR - Off Key

The key functions on input 2 are programmed as:

SP - Toggle
SR - Retrigger Timer
LP - Idle
LR - Retrigger Timer
Timer Expiry - Off Key

There is only a single group associated with each channel and and those groups do appear in output units.

The bus coupler Firmware is 1.2.67.

Any ideas on what is going wrong here would be greatly appreciated.

Cheers

Matt

 

When there is both a bus coupler and a relay sharing the same group there are really only 2 ways that the relay channel can turn on at power-up:

• If the relay unit is configured to have the group address On at power-up
• If the bus coupler is configured to broadcast it's values at power-up

In your application the power-up state of the relevant relay channels should be configured to always power-up in the Off state, rather than N/C (no change). I would also configure the bus coupler this way, i.e. on the Power Failure tab set the Restore to Preset Levels option and configure the channels to power-up in the off state.

If the option for the bus coupler to broadcast it's levels at power-up is NOT set, then the power-up state of the group associated with that relay channel will dominate over the power-up settings in the bus coupler. Even when the Broadcast Values on Power-Up option is set, there's still no guarantee that it will beat the relay unit to setting the state of the group. This option in the Bus Coupler is really there to handle state changes in it's inputs that have occurred whilst the bus coupler has been without power.

Keen to know what the current configuration settings are.

 

Hi guys, thanks for the detailed replies.

Both relay outputs are set to power up in the OFF state and the bus coupler is configured the same way.

"Broadcast Values on Power Up" was ticked on the bus coupler when the problem occured.

I'm pretty confused as neither of the inputs to the bus coupler would have been on at power up either!

Cheers

Matt

 

I suggest that you disable the "Broadcast on Power-Up" option. In your case there's not much value in having it.

If the problem re-occurs you'll need to log the network traffic at power-up (which can be a little tricky) to see which unit is sending out the message to turn the group on.

 

Something doesn't quite add up here.
V 1.2.67 Bus couplers follow a strict power-up sequence which ensures that the controlled group states are set to OFF before any input switch states are even looked at. If the switch states are open, and the 'Broadcast Values on Power Up' options are not selected, then the Bus Coupler will not take any further action.
If there is a group state conflict between input (Bus coupler in this case) and output (Relay in this case) units, then the Bus coupler will change its state to agree with that of the relay (without sending any messages on the bus). If there are multiple output units (relay or dimmer), and their states don't agree (one is OFF, another is ON), then and only then will the bus coupler transmit a message to define the state of the group (to match the state in the bus coupler).

I wonder, do you know the group states, or just the sates of the relay outputs?

Relays have 'remote override' inputs which may be involved in your problem. Normally these inputs are not used, and are left 'floating', but if the remote 'ON' input is pulled to the C-Bus negative line, it will turn ON all relay channels. If this happens, your symptoms could have been seen. These inputs are high impedance, and it is possible that condensation could have bridged the gap after the units (which normally run a few degrees above ambient) cooled down. I would expect that the 'panic' relay would have reset itself by the time you arrived on the scene if this was the case, so this is not likely, but might be worth consideration.

How long is the timer for the 'panic' group? Would you have expected it to have timed out by the time you arrived?

 

Hi Don, thanks for the great explanation on the power up process - it's always been a mystery to me!

When I arrived at site (around 6-hrs after the "lights came on") the 'panic' group was definitely on.

When the symptoms were reported over the phone I initially suspected the remote override too but when I got to site I found it was only about half-a-dozen lighting groups and they are on a number of different relays and dimmers.

I eventually twigged to the 'panic' group - it's in the relay/dimmer logic as an 'AND'. I connected Toolkit and turned the group OFF and everything returned to normal.

The timer on the 'panic' group is only set to 5-minutes and there's no other input programmed with that group.

On double checking, most of the outputs with the 'panic' group in the logic are set to power up N/C but the garage door output is definitely set to power up OFF.

 

I forgot to mention one thing in the power-up sequence (it doesn't affect your situation but for completeness, here it is):
If the bus coupler is set to 'no change' of group state on power-up, then the last state prior to the loss of power is applied to the bus coupler state after the initial OFF state has been set. This happens without any messaging on the bus. After this, the bus coupler state is compared to output unit states (via the MMI mechanism), and behaviour is as previously described.

It sounds very much like the problem in this installation is not the bus coupler, but could be related to the power recovery settings of the 'panic' group. This should have resolved itself after power-up, so it's still a bit of a mystery. I've lived with C-Bus controlling my lights for a long time, and have never seen this sort of thing. I'll keep thinking.

Logs would be nice, but it sounds like this is a very rare event.

In the mean time, if this installation has a PAC or C-Touch that can at least run schedules, I suggest that it might be appropriate to include something to turn off the 'panic' group periodically, and if possible, log any panic event so that if this ever happens again the customer isn't left distressed for long, and you might be able to gain some clues as to how this comes about.

 

Ok, so now for the embarrassing reveal...

I've just had a call from my tech on site and both the access control keypad and the smoke detector isolation units were connected to the bus coupler via their normally closed outputs.

So, even though the bus coupler was set to 'power up off' would the fact that the 'broadcast levels' box was ticked have caused an 'ON' for those groups to be sent over the bus, given that the inputs were ON at power up?

I guess that explains why the timer in the 'panic' input never expired - the bus-coupler never saw a short or long release.

I'm sorry for wasting everyone's time but it was a very good lesson in the way a bus-coupler behaves at power up!

Thanks again.

Matt

 

Yes, that definitely would have been the case. The bus coupler would have powered up in the Off state, looked at it's inputs, seen that they were closed, and then broadcast an On command on C-Bus when it came time to perform the "Broadcast on Power-Up" function. Without the "release" event, there would have been no key event to start the timer.

Thanks a lot for reporting that you actually found the root cause of the problem. These sorts of things being left un-solved, or not having the courage to report that the mistake was a wiring fault, can have us going down all kinds of "rabbit holes" and wasting lots of time. Thanks again.

 

Cheers, appreciate the help.

Matt

 

Thanks for following this up.
It's good to see the reason for the unexpected behaviour.
Hopefully this will help others if they come across it in future.

The best fix would be for you to use normally open contacts. Are you able to do this for both channels?

 

Yep, there are N/O contacts on both devices...which were the ones I thought we'd connected in the first place!

Until there's another power failure, looks like this one's sorted.

Cheers

Matt