Command |
changeGroupSchedule |
Shortcut |
cgs |
Arguments |
[group] seconds |
Availability |
when logged in |
Purpose |
To schedule automatic, unsolicited, recurring, changeGroupGets. If any changes have occurred when the periodic timer expires, the server will automatically send a change list, as if changeGroupGet has been called. While this mechanism violates the normal client/server relationship, and is not normally recommended (what if too many changes occur too quickly for the control system?), it may be useful in reducing network traffic if the control system is polling a very large number of servers and is looking for changes that need to be recognized quickly. Otherwise, reasonable real-time programming practices on the control system side make this command unnecessary. |
Notes |
The group name argument is optional, and if it is not included, a Change Group named default Change Group will be used. The schedule can be cancelled by calling changeGroupSchedule with an argument of zero. Only one Change Group can be scheduled. Note: This command is only supported over TCP connections. |
Response |
Something like this: changeGroupSchedule Balcony Speaker Overload Indicators 5 Subsequently, changeGroupGet responses will be returned when controls in the Change Group have changed. |
In this section |
See also |
The client issues:
changeGroupSchedule "Balcony Speaker Overload Indicators Change Group" 5\r
or
cgs "Balcony Speaker Overload Indicators Change Group" 5\r
RATC2 responds with the Change Group name and the number of changes that were requested.
changeGroupSchedule "Balcony Speaker Overload Indicators Change Group" 5\r\n
\aBadArgumentCount\r\n
\aOverflow\r\n
\aInvalidChangeGroup "yourBogusGroupName"\r\n