Phantom CBUS acivation

Noticed this a few times in the past few days - thought it was people turning on lights and not turning them off.

Just noticed our side alley lights are on. Odd, we didnt turn them on.

I have Comfort and CBUS working together. And via the Homeseer plugin I can monitor both systems activity.

Yes, the homeseer log shows the Outside lights came on at 7.29pm. Now I do have some logic in Comfort - if any of the side gates or french doors (x2) or back door are opened, the lights come on, on a timer. Nothing more. I've checked the config for all references to that light (in Comfort code) and ive confirmed that is the only response that touches that CBUS id.

Except none of the zones have been activated in the past 48hrs. None of them have been activated anywhere near the time the lights came on.

Where on earth can I start to debug why some zones are turning themselves on ?

Now this could be unrelated, but our kitchen lights have dimmed and then come back on twice - all in the space of half a second - not a usual dim - whislt we've been sitting in. And the lounge did this earlier.

Think they are related ? Except the Outside lights are not on the dimmer - they are on one of the relay units.

 

Maybe you have had a brown out?

 

Same thing has happen to me. Probably a dozen times in the past year. Always my garden lights and yes, I noticed have brown outs at the same time. Seems like some CBUS units are sensitive to voltage changes.

 

Check your output unit power cabling termminations are nice and firm. If it is happening across a couple of output units, are they on the same supply cct ? If so check the breaker wiring terminations...

 

I've not changed any of those settings - they are all default and appear to be set to come on on power loss.

Odd that only this light comes on tho ?

All the connections are all ok - that relay unit hasnt been touched for months - case closed !

And the two power losses ive seen on lights are on the dimmer units - not this relay unit this light is on.

AND the CBUS Network side hangs off the house UPS. So CBUS will 'never' lose power (even though the light itself will)

 

The C-Bus messages have the source address encoded in them so you can use a PCI and something like hyperterminal or fancier to log all the messages.

When your light goes on, you can see what device issued the command.

The diagnistic tool might have a simmilar feature, but I don't know.

Cheers

Rohan

 

C-Bus output units like relays and dimmers look at an unregulated internal power supply voltage derived from mains to determine the state of mains. If the unregulated voltage drops below a predetermined threshold, the unit will go into its power-up state (after storing the last levels in non-volatile memory if this option is selected). The power-up sequence waits for the mains to recover, and once it is above a threshold level (again, determined from the voltage on an unregulated, mains-derived internal supply), the stored levels are recalled and normal operation resumes. Note that all this is completely independent of the C-Bus network supply. Powering C-Bus from an UPS is a great idea for many reasons, but it won't prevent the mains dropout detection from working.

 

Apart from filtering spikes, etc??? Are there any other reasons, from what you just said, I would not be sure it was worth the expense

Grant

 

Have you got any amateur (ham) radio operators in you area? When I get on HF (100 watts PEP) the lights in my shed connected to a 4 way C-Bus relay unit tend to be a little unpredictable. I've tried clamping some ferrite cores on the C-Bus cable and 240v cables, but I still have troubles.
Any broadcast stations nearby?

 

(100 watts ) HF-RF. Don't stand next to the antenna when that puppy is transmitting if you want to have have children in the future

 

I had a client with a 8ch dimmer that had 1 channel mysteriously turn on occasionally. It was ONLY 1 channel, and I was unable to leave a laptop there running Application Log. After discussing with Tech Support, we asked the client to do 2 simple tests when the problem occurred (light on for no reason), and to check immediately without touching anything else (ie: leave the phantom light on)...

1. Check if the corresponding LED indicators on the switches (that controlled that GA) were on or not. This determined if there had been a C-Bus event that triggered the channel (in our case, the LEDs were off)

2. Check if the Over-ride LED on the Output Unit's Channel is on or off. I guess this determines if there was something inside the unit that switched the load on "manually". (in our case, the LED was off)

Since none of the status LEDs ever came on (even when the load was on), and there was absolutely no logic (no PAC or CTC) on the network, it was determined that the dimmer was acting up. Tech Support sent me another one which I programmed and exchanged, and the client gave up monitoring the new unit for faults after a few months of successful operation.

I have no idea what was wroing with the unit - I sent the unit and a proper Return Form, etc to Adelaide, but I never heard anything back from them.

Dunno if this is the same as what's happening in this case... but it's easy to test

 

Ups

Because I also have Comfort and they are linked. When Comfort detects powerloss, the logic kicks in.

Comfort has it's own battery, and the CBUS network stays alive - so Comfort tells CBUS to turn on some low level energy lights (ie the LEDs on the stairs). If it's dark (with the light sensor)

Plus it means I dont have to keep resetting the damn clock.

Why CBUS and Comfort can't have a CMOS Clock is beyond me !

 

Phanton Schedule Issues

I have also had some c-bus events occour that I can't resolve in regard to shedules.
I have a shedule to trigger a scene and several hours later a command to ramp all off (over 40 seconds)

What happens is that about 10 seconds in to the ramping off, several groups will return to on.

Another issue I have had is when a group (relay) is set to on by a schedule, If I want to then over ride the command and turn it off, it immeliately turns back on and then requires a second off command to then go off.

Any help would be appreciated.

 

Before doing anything else, use the C-Bus Diagnostic Utility to determine which unit(s) are generating the commands which cause this unexpected behaviour. Once we know that information, we can provide some useful suggestions.

 

It may be related to the toolkit errors im getting -

http://www.cbusforums.com/forums/showthread.php?t=3104

no response so far on the forums tho :-(

 

I would give the same advice as I did to Hunter yesterday. Whenever you have unexpected behaviour on C-Bus, use the C-Bus Diagnostic Utility to :
1. Check whether you have good C-Bus communications (the Traffic Analyser function)
2. Check the source of C-Bus messages - it is VERY common to find that commands are coming from a different unit than you thought
3. You can use the logging function to capture events to analyse later or to provide to tech Support for analysis.

 

I had this happen to me with my touchscreen. CIS came and looked at it and basically gave up on it. Told me NOT to use the AREA group address and to use scenes for the all off.

My problem was the touchscreen turning back on groups when the MMI was sent after the RAMPOFF command (Logged)

I use scenes now