Area group control

All my cbus units are in the same area. When I set that area to off, any lights I had go off. CGate (and so toolkit) still believe the groups are on.

I'm not sure whether this is a bug or not - is this like a local override, so the dimmers have responded to the area off command even though the groups the dimmer responds to are still on?

I suspect this is a feature rather than a bug. Does this mean that the only reliable way to see if a dimmer channel is on or not is to query the dimmer rather than check the status of the group controlling that channel?

 

Area addressing is not always the best solution

cueman,

Area addressing works essentially by allowing units to treat all terminals or keys, or in fact all internal entities that can be controlled by Group variables to respond to a single "Area group" . Area addressing applies to all types of units. This addressing mode was included in C-bus before the concept of "scene" control was included, and allowed the very useful feature of "All OFF", or "All ON". to be made available.

Area adressing unfortunately comes with its own set of problems, most of which can be avoided by following a set of rules. The first problem is encountered if some groups in a unit are not intended to be controlled by the area address. Rule 1: ensure that units responding to area address do not include any groups not intended to be controlled by the area. This one is pretty obvious, however it is not always easy to avoid some conflicts, especialy in key units which can control groups both in and out of the area. If the area address is applied to the key unit, then the groups out of the area may be indicated as the wrong state for a while, until the regular status reporting mechanism sets the status to the correct value (usually about 6 seconds).

Another problem is that if any input units, especially the one issuing the area address are not also given the same area address, then the displayed group status will not agree with that of the output unit(dimmer) until the error reporting mechanism set the status. Rule 2: ensure that all units with any groups represented in any output units controlled by an area address also are given the same area address, AND also have the key(s) chosen to contro Area be selected to control ALL groups in the unit, to reflect the effect of receiving the area command. Note that the status report mechanism can be used to determine the on/off status of all groups at any time, and is reported correctly immediately after any Area address command has been sent.

Another problem occurs when an OFFKEY or an ONKEY command is used to control an Area address; it may work once, but then will not work again. This is caused by the fact that in key units, in an effort to reduce unneccesary network traffic, will not transmit an ON command if the group is already in the ON state when ONKEY is chosen, and likewise will not transmit an OFF command when the group is in the OFF state when OFFKEY is chosen. The solution is to use commands which will always issue, regardless of group state, such as RECALL or RAMPOFF. Rule 3: Always control Area addresses with commands that are not dependant on group state.

Now you have come across another problem which is that the association between area addresses and groups is hidden in the programming of the individual units, and therefore simply monitoring group status will not give you an immediate picture of the actual loads controlled. The simplest way to get around this problem, if you are using NEO, Saturn, Reflection, DLT, C-Touch, or scenemaster products is to use scenes to achieve your goal. This method allows any monitoring system to update the state of the outputs immediately. I guess this brings up Rule 4: Don't use Area addressing if you want to monitor group state by looking at commands on the bus.

The last point is not really complete, however, as there are still some factors in the output units which can mask the actual load state. These are the min/max levels which can be appled to dimmers, combinational logic that can be applied to the group levels to arrive at terminal levels in dimmers and relays, and threshold switching or restart timers which can be applied to relays. The actual state/level at the load may be masked by any of these features, and in these cases, the most direct way to get the final result is to query the individual units as you suggest.

Don

 

That explains it. As I thought - it's a feature, not a bug

Thanks for the explanation.

 

recommended commands

further to that the typical recommended commands for controlling
area address should be:

upkey - will force all GA's controlled from the AA to 100% even if
already "on" at a lower level.

Rampoff - will force all GA's controlled from AA to off.

recommended that you may need to alter the ramp times to prevent long
ramping periods

AA= AREA ADDRESS
GA= GROUP ADDRESS

It has also been recommended to the "software design" guys that we could
use some additional buttons defaults on Input UI's for :
AREA ON
AREA OFF
AREA ON/OFF

to save the end user having to find it out by themselves..