Command Confirmation

Status and command confirmation

SUMMARY

One of the problems with the X10 protocol is never knowing for sure when a device control command (on or off) is transmitted whether the intended device received and acted upon the command. For any device that responds to status requests it is possible to send a command and follow that with a request for status. If the returned status doesn't agree with the expected status the command can be sent again and followed up with another status request.

This protocol: command - request status - check status - send command again - send status again ... is available in HCA and can be enabled is desired.

This note describes in detail how this has been implemented in HCA, how to enable it, and some implications of its use.

For status requests, there three kinds of modules available:

Modules that don't support status requests. Examples of these are the LM465 lamp module and the AM486 appliance module.
Modules that support status requests. Examples of these are the PR511 floodlight and the outlet in the RR501 transceiver base unit.
Modules that both support status requests but can also be programmed to automatically report status if they are turned on or off via X10 and when turned on or off manually. Example of these are the LM14 lamp module and the AM14 appliance module. This automatic reporting feature must be enable by sending the device a special command.

For a device, on the Advanced properties page these options are available:

[ ] Supports status checking
[ ] Supports automatic status reporting
[ ] Enable automatic status reporting
[ ] Confirm receipt of command sent

When you first create a device, if you select one of the parts listed in the parts database, the first two options are enabled if supported by the device.

The 3rd option is grayed out if the 2nd option is not checked. The 4th option is grayed out if the 1st option is not checked.

The 4th option enables the facilities in HCA to use the status messages to ensure that a device received the command.

How these options are used

These options play a role in four different HCA areas:

First, when HCA starts up and loads a design file, every device that is marked as "supports status" is queried as to its current status. Those with "Enable automatic status reporting" checked are sent the command to turn it on.

Second, whenever you do a "Get status" from the UI, in addition to sending out the status query and showing you the result, it also sends the command to enable automatic status reporting if the device supports it and the user requested it. Since these modules lose their state when unplugged this gives you a way to get the automatic status reporting turned back on. There is another way described below.

Third, whenever you use the Test element in a program, if the device supports status checking. a status request is sent to the device. The program waits until the device replies or until a timeout timer expires. The Test element allows you to specify which path to take if the device is ON, OFF, or the timeout happened.

Fourth, when an ON or OFF command is sent to a device marked as "Confirm receipt of command sent" the ON or OFF command is sent and then what happens next depends upon if the device supports automatic status reporting.

If the device does support automatic status reporting:

	A status timer is started. This timer expires in 'n' seconds. If during that 'n' seconds a status message for this device is received and is correct (that is, an ON command is sent and an ON status received) the timer is removed and the operation is complete. Note that we are replying upon the device to send an automatic status report without our asking for it.
	If the timer expires before a status report is received or the status report is incorrect, the command is sent again. Then:
	If this is the 1st, 2nd, or 3rd retransmission, the status timer is started again.
	If this is the 4th, 5th, or 6th retransmission, a status request is also started. This sends out the status request command and waits for a reply. If it gets a reply (and is correct) then automatic status reporting is turned on for the module if appropriate (the device supports it and the user requested it). In this way, if the device lost its programming for automatic status reporting it will get reprogrammed at this time.
	After 6 retransmissions HCA gives up.

If it doesn't support automatic status reporting:

A status request is started. This request sends out a status request command and waits for a reply. If a status return is received and it is correct, the operation is done. If a status return is not received or the status is incorrect, the command is re-sent and the status request is re-sent. Six attempts are made.

A few more notes:

Each retransmission attempt is logged. An error is logged if all six retransmission attempts fail.

All this stuff about 1st, 2nd, 3rd and 6 retries is actually set in the registry. So to be completely clear, the command is retried 'n' times, where 'n' is in the registry. If the device supports automatic status reporting, status watches are performed 'n' / 2 times and status requests the remaining times.

How long is the timer set for? Since HCA works to enable all its competing parts access to the X10 interface (UI, schedule, programs, power fail watch, etc) it may be a while before a command even gets sent and the device may take a while to reply. The timer is set using the sum of some values from the HCA registry settings:

StatusSendTimeout
This is the length of time to wait until the command is sent. If other parts of HCA are using the X10 interface the command may not be transmitted until after some seconds.

StatusReplyTimeout
The is the length of time to wait for a reply after the command is sent

StatusReplyIncrement
After each retry, an additional time interval is added to lengthen the time between attempts.

As described above, when HCA is first started all devices that support status requests are queried to find out their current state. This is not done until after a few seconds so as not to conflict with other X10 commands that HCA programs or schedules may be sending. This length of time is normally 60 seconds but can be changed in the registry key StatusStartupDelay.

You should be VERY CAREFUL in using this feature. Remember that the X10 protocol does not detect or report collisions. If there are too many modules transmitting status, these asynchronous status messages may collide with other commands you are sending. This will make your home automation setup even less robust.