Command-Line Protocol will be enhanced to allow status queries for the following items: GPI inputs; GPI outputs; UPL resources; headset transfer; whether an IFB is being interrupted.
The format of these commands is as follows:
| Description | Query | Response |
|---|---|---|
| GPI Inputs | DIS?<list> | DIS { <value> <+/~> }* |
| GPI Outputs | RYS?<list> | RYS { <value> <+/~> }* |
| UPL Resources | URS?<list> | URS { <value> <+/~> }* |
| Headset Transfer | HS?<list> | HS { <value> <+/~> }* |
| IFB being interrupted | IFI?<list> | IFI { <value> <+/~> }* |
(A UPL resource is asserted if there is any talk or listen key turned on, which is programmed with that assignment.)
Command-Line Protocol messages can be divided into two groups: commands and queries. A command sent to the intercom receives a simple response of "OK" (if no errors were encountered). A query sent to the intercom receives a response containing the requested information. Normally, the protocol is half-duplex: a message is sent to the intercom; the intercom processes the message and generates a response; and another message can then be sent to the intercom.
Stored queries will be added to the intercom. A stored query consists of a simple query of the status of a single item (e.g. the query for the status of one talk key), prefixed by a number and a colon.
A stored query is treated as a command. The immediate response is either "OK" or an error response. However, once a query has been stored, the intercom automatically monitors the given item, and generates a response whenever it changes. These responses are generated asynchronously, i.e. without waiting for a message to be received.
The stored queries will actually be converted to UPL statements. Hence, if the intercom is configured for 256 UPL statements, then it can handle up to 256 stored queries. When a stored query is sent to the intercom, the number at the start of the command specifies the UPL statement number which will be used to store and evaluate the query.
New messages will allow the user to directly query the status of the various items being monitored via stored queries.
A stored query is defined by sending to the intercom a message in the following form:
<value>:<simple query>
<value> represents the UPL statement number in which the stored query is saved (origin-1)
<simple query> is a status query for a single item; valid queries are listed below
If there are no problems encountered in parsing and storing the saved query, an "OK" response will be generated. Note, though, that the stored query will also generate an (asynchronous) response immediately, giving the status of the item being monitored, if it is currently active.
One or more stored queries can be deleted by sending to the intercom a message in the following form:
SQD<list>
Sending a query of the form
SQ?<list>
to the intercom will cause the intercom to return any stored queries which have previously been set up. The result is a series of responses of the form:
<value>:<simple query>
If more than one stored query is requested, "NXT" can be used to return successive stored queries. Stored queries which have not been defined are omitted. If none of the stored queries in the specified list have been defined, the response is simply "OK".
A message of the form
SQS?<list>
can be sent at any time to determine the status of each stored query. The response will be of the form
SQS { <value> <+/~> }*
where <value> represents each stored query number. Each stored query number is followed by "+" if the item being monitored is asserted, "~" otherwise.
Whenever an item being monitored by a stored query changes, a Stored Query status message is automatically generated and sent, asynchronously. This will be in of the form
SQS { <value> <+/~> }*
Note that this message can be generated at any time, even when the intercom has just received another Command-Line Protocol message and is processing it. In this case, the asynchronous response may precede or follow the response to the message being processed, but the two messages will not be interleaved.
The following items can be monitored via stored queries:
| Description | Query |
|---|---|
| Talk Key | KP<value><pnl>KS?<key>T |
| Listen Key | KP<value><pnl>KS?<key>LS |
| GPI Input | DIS?<value> |
| GPI Output | RYS?<value> |
| UPL Resource | URS?<value> |
| Headset Transfer | HS?<value> |
| Crosspoint | IN<value>FI?<value> |
| Crosspoint | OU<value>FI?<value> |
| IFB Being Interrupted | IFI?<value> |
Note that the stored queries are more limited. Whereas a single Command-Line Protocol message can query the status of up to 16 talk and listen keys, a stored query can only monitor a single talk key or a single listen key.
The following table gives a sample set of command-line protocol messages and responses which might occur, to illustrate the use of stored queries.
| Command | Response | Description |
|---|---|---|
| SQ?* | Query all stored commands that have been defined | |
| OK | None yet defined | |
| 2:KP3MNKS?5T | Stored query #2: monitor talk key #5 for port #3 | |
| OK | Command was successfully stored | |
| SQS2+ | Stored query #2 asserted (port 3's talk key #5 is on) | |
| 4:DIS?17 | Stored query #4: monitor digital input #17 | |
| OK | Command was successfully stored | |
| SQ?* | List all stored queries | |
| 2:KP3MNKS?5T& | Stored query #2 ("&" shows more to come) | |
| NXT | List the next | |
| 4:DIS?17 | Stored query #4 (no "&" implies no more to come) | |
| NXT | List the next | |
| OK | No more - default response | |
| OK | Command does nothing but cause "OK" to be echoed back | |
| SQS2~ | Asynchronous response - port 3 talk key #5 turned off | |
| OK | Response to the "OK" command | |
| SQD2 | Delete stored query #2 | |
| OK | Command was successful | |
| SQS?* | List the status of all stored queries | |
| SQS4~ | Only #4 stored; digital input #17 is not currently asserted |
Individual (talk and listen key) LEDs will be controllable via command-line protocol. The format of the command is as follows:
KP<value><pnl> { LED <value> [T <value>] [LS <value>] }*
In this case, "LED <value>" specifies which key's LEDs are being set; "T <value>" and "LS <value>" specify the attributes for the talk and/or listen keys, respectively.
Further details of the implementation, including the attribute values, are covered in the UPL documentation, under the description of the "Keypanel LED Control" output action.