All groups switch off on one group ramp to zero

We've seen a situation on a at least 3 networks that we don't have a solution for.

When a specific group (group number is not the same across the faulty networks) is ramped down to zero, ALL groups on the network switches off!

This can be repeated, i.e. the same group will do this. It will turn off all groups as it reaches zero. You can turn groups on again via input units.

Currently we just don't use the 'weird' group number (invariably it's the one controlling the hot water cylinders!) But it's not a healthy situation.

Anyone seen this and have advise on this?

 

Can you confirm that on all your output units that this group is not the group assigned to "Area".

Mick

 

Also suspected that, but mostly the Area is set to unused. We did set the area to a unused group number just to make sure.

But nowhere was the area the same number as the group number triggering the problem.

 

Need to do that, just need a quiet slot when the customer is not around. Because it happens only at 3 (of many) sites and the group number is random, we've not been able to duplicate it on test network.

I've wondered about a specific firmware rev on a specific unit not maybe causing the problem but have not found any commonalities yet (although it must be there)

 

I'll be very suprised if you find some hitherto unknown C-Bus defect that causes this.. given that you've got 3 of your own sites that its happening on its almost a dead certainty that you're programming is at fault. Logic, misused area addresses etc..

 

Duncan, while I appreciate your comment, we're not new kids on the block when it comes to C-Bus. We've been doing this for many years and have done numerous, large projects with C-Bus. This problem has been around for quite a long time and it's only now that I bring it to the forum.

One of the 3 sites I mentioned was actually done by another C-Bus installer. (also one of top 3 C-Bus installers in this province). We did the Crestron systems in that particular project and noticed the same problem there.

We don't use any C-bus logic, BTW, all logic is done at a higher level.

Can you expand on the 'misused area addresses' statement please? How can one end up 'misusing' an area address? What are the do nots with areas? We don't use the area function at all, so we normally set the address to unused. Is this wrong?

 

Perfect..

Run up the Diagnostic Software or the Application Log in C-Bus Toolkit.. I bet you nail the problem quickly.

 

Maybe I did not give enough info on this problem. It seems that the terminals (on a relay for example) switch off at a hardware level, so I'm not sure if I'll see something on the bus.

Let's say the offending group is group '1'.

I ramp '1' down, via a keypad or any other input unit. As it reaches 0, all the relays will switch off, irrespective of their assigned group numbers. If I now query the groups assigned to the relays, I get a C-Bus response indicating the original levels, i.e. if the group was on it still indicates on. But the terminal is switched off.

Jut as if someone had pushed the override button on the front of the relay, i.e. the terminal and group are now out of sync. Issuing a software off and on restores sync between the input and output units.

So it seems a group command (ramp to zero) triggers a terminal response shutting the terminals on the relay down.

Toggling the offending group between on and off does not produce this, only a ramp.

It's like the units get swamped by the ramp command and then promptly switch its terminals off. The interresting fact is that it is just a specific group that will do this, but not the same group across the different, faulty networks.

 

PCI in all cases

In 1 installation there are two networks bridged, the other 2 are single networks.

Nope, just Clipsal C-Bus2 units, relays, dimmers and Neo and Saturn keypads + some DLT's

All set to factory default.

All set to default.

No, must still do this.

Will do. I don't think an off command is transmitted though, as other units with the same group assigned won't go down to zero, the keypads will still show the groups as on, for example.

If we read the group levels, they're still at their previous levels, so no legit C-Bus group commands were transmitted. The Crestron interface (via PCI) also shows no feedback received that the groups changed, only the one that was ramped to zero.

It's more like the relays perform an internal shutdown, (just as if the override buttons on the front of the relays were switched off), when it sees the ramp to zero command.

So basically, a legit ramp to zero command on a specific group will shut the relays down. Note only a ramp will do this. Setting the group off won't trigger it.

 

I think you might be missing the point that if the problem was caused by a legit command on the bus, all units with one of the affected groups would have reacted to it. This is not the case. Only the output units switch off. Input units still have the last known level of the group.

Can you elaborate on the 'dodgy Crestron driver' statement please? Which drivers are these? What commands can one issue via the PCI or C-Gate that will cause odd things?

We've done many Crestron / C-Bus systems and have only seen this problem on 3 of the installations.

 

Will do.

I'm quite concerned that if a manufacturer publishes an interface into their system (C-Bus, in this case) and you use this interface, it can cause 'strange things'. Does not sound like a solid integration point to me.

Again, I'd like to ask; what commands can I issue over a PCI (using the published commands) that can cause 'strange things' to happen.

Surely if you publish an interface, the interface can handle the commands you isue. Even if these commands are non-sensical, the interface should handle this and not do 'strange things' like switching off all the terminals on all output units when you issue a ramp command.

I suspect this is a bug in either the PCI or the output units.

 

The one way to get to the bottom of where the problem lies is, as NickD suggested, to connect the C-Bus Diagnostic utility to a PC Interface connected to the network. Then, capture the C-Bus messages that are being issued when all the lights turn off unintentionally.

A problem like this can be due to any number of variables so it's best to eliminate them one by one. 9 times out of 10 using the diagnostic utility shows up some other unit on the network generating messages due to the way it's been programmed, an oversight in logic or area address programming, some left-over code that's still running in a Logic Engine, a C-Touch spitting out a Scene, third party devices sending mal-formed commands, etc, etc.