Start and Re Trigger Commands

Hi All

We have a custom solution that listens to the C-Gate output, which works well.

We have some buttons configured as Retrigger Timer for a group (timer set for 60 minutes) however when pressed they appear to just send the standard 'lighting on' command to the network - nothing that indicates that there is a timer running etc.

Is this correct, or am I missing something?

 

That is correct. The key unit sets the state of the group. The timer functionality is internal to the key unit.

 

...But is there a deeper level of cleverness?

Newman, that's what I thought but I suspect there's something clever going on too.

When I set up a bathroom with a PIR sensor I programmed a 2 minute ramp to off command for the timer expiry.

As the PIR doesn't see the toilet very well if the client is (ahem) taking longer than 2 minutes, the lights fade to off. I've installed a button within arm's reach of the loo (tr. Dunny) that sets the lighting group back on for a further 2 minutes.

All works well.

I had expected though that, were one to press the button before the PIR had sent its offramp command , the lights would still go out in response to the off command from the PIR. What I observe is that the button press results in the lights staying on for 2minutes from button press regardless of how long it has been since the PIR has last seen movement. I'm pretty sure that the physical motion of pressing the button is not retriggering the PIR timer.

All of this is exactly what I wanted to achieve (so well done clipsal), but it would be nice to know how it's done.

Stair/corridor type timers are clearly one application of all this.

Phil

 

The rules of timers in C-Bus are:
1) Any unit can implement a timer internally to control a group at a time after some initiating event.
2) Any unit running an internal timer will stop timing and will not issue the timer expiry command if it receives any command from any other unit over the C-Bus network affecting the group it was controlling. This ensures that there can only ever be one unit actively timing any one group, and system behaviour is predictable.
3) When starting a timer in a unit that was not the most recent unit to control a group, that unit will generally transmit a ramp-to-level command with level = current level, and ramp rate = 0. This transmission ensures that all other units controlling the same group will always have their timers stopped (see item 2).
4) Any unit that was the last unit to control a group may start an internal timer without any command appearing on the bus. This is important to prevent sensor units from flooding the bus with unnecessary traffic.
5) where many sensors are used to control a common group, there is likely to be a lot of bus commands due to different sensors 'taking over control' when they see new motion in their field-of-view. To keep bus traffic in such situations under control, PIR sensors include an extra hold-off timer (shorter duration than the timer to control the group) to prevent issuing excessive commands (I call this a crowd tolerance feature).


As you can see, these rules don't require any special commands on the bus to manage timer behaviour, and should explain what you are seeing.
A lot of thought went into these rules, and I'm glad that they are achieving the results you intended.

 

Indeed, there is a deeper level of cleverness.

In your case, Phil, pressing the button on the switch is sending a bus command that sets the lights to 100%, even though they're already On, and this is cancelling the timer that is running in the PIR.

If the PIR was to detect motion again, it would send a command on the bus to set the lights to 100% and this would cancel the timer that is running in the switch.

Because the lights are already on, these extra commands do not result in the light changing state, but they allow the currently active timer to be exchanged between the units.

 

Thanks for the explanation.