KHarms
Nov 03, 2009, 10:09 AM
Things work best when HCA knows the state each of your devices. The good news is that most modern devices – Insteon and UPB – support status requests. HCA can ask them what their status is and they report back.
Unfortunately, older less capable X10 devices in general don’t report status. The HCA parts file contains information on all devices and HCA configures the device properties when you add it. For X10 devices, look on the “Options” tab and that will tell you if the device reports status requests and what form of status request they use. X10 devices are a mess in this regard with many different status reporting mechanisms.
But HCA can keep up with the state of your devices without needing to request status. UPB devices have a setting – configurable using the UPB UPStart configuration program – to have the device send a status report whenever the device is locally controlled. So if you have a switch, each time you turn it on, off, or change the light level it can report to HCA its state.
Insteon devices are not quite as simple to get status reporting. One method to use is to link the switch to HCA just like you would link another switch or module to the switch. You locally control the switch and it transmits a message telling others linked to it – including HCA – that the switch was controlled. One problem with this technique is that the message sent doesn’t include the light level so if you “tap and hold” the switch paddle to change the level, HCA will know that the level changed but not the final light level.
In addition to these passive mechanisms to have HCA kept up to date, you can also use several different active methods.
The first – simplest – is to right-click on a device that has status reporting capability and select Get Status from the popup menu. In addition to displaying the status it also updated HCA’s internal state.
Another method is to use the Visual Programmer Test element when testing a device’s state. As part of the Test, if the device has status reporting capabilities, HCA queries the device to get the state. Again, while the result is used in the test, HCA also updates its internal state for this device.
You can also use the Get Status Visual programmer element. This element can poll one or more devices, retrieve their status, and update HCA internal state. One important point about the poll element: All it does is add a status request for each device to an internal queue and then move on. This means that it may take a while for all the status requests and replies to happen. You can’t do a Get Status element and then expect that all status requests have been received by the time the next element in your program happens.
You can create a program that uses the Get Status element and then schedule this program to run periodically to make sure that HCA is up to date with the actual device states.
Another method, used when HCA starts, is to enable a status poll of all devices when HCA first loads your file. This can be configured on the Startup tab of HCA – Properties. Like the get Status element these status requests are added to an internal queue and processed over time. Also you can configure HCA to hold off sending these status requests until after HCA has been “up” for a set length of time. You may want to use this delay if you have programs that run when HCA starts and want a “clear channel” on the powerline.
The last method HCA has for keeping its internal state up to date is for devices who have the “confirm receipt of command” option enabled. As part of confirming receipt of a command, HCA actively polls the device for its status.
All of these methods work together to keep HCA up to date with the “real world”. Use them carefully as each command on the powerline removes bandwidth for your action commands - like ON and OFF.
Unfortunately, older less capable X10 devices in general don’t report status. The HCA parts file contains information on all devices and HCA configures the device properties when you add it. For X10 devices, look on the “Options” tab and that will tell you if the device reports status requests and what form of status request they use. X10 devices are a mess in this regard with many different status reporting mechanisms.
But HCA can keep up with the state of your devices without needing to request status. UPB devices have a setting – configurable using the UPB UPStart configuration program – to have the device send a status report whenever the device is locally controlled. So if you have a switch, each time you turn it on, off, or change the light level it can report to HCA its state.
Insteon devices are not quite as simple to get status reporting. One method to use is to link the switch to HCA just like you would link another switch or module to the switch. You locally control the switch and it transmits a message telling others linked to it – including HCA – that the switch was controlled. One problem with this technique is that the message sent doesn’t include the light level so if you “tap and hold” the switch paddle to change the level, HCA will know that the level changed but not the final light level.
In addition to these passive mechanisms to have HCA kept up to date, you can also use several different active methods.
The first – simplest – is to right-click on a device that has status reporting capability and select Get Status from the popup menu. In addition to displaying the status it also updated HCA’s internal state.
Another method is to use the Visual Programmer Test element when testing a device’s state. As part of the Test, if the device has status reporting capabilities, HCA queries the device to get the state. Again, while the result is used in the test, HCA also updates its internal state for this device.
You can also use the Get Status Visual programmer element. This element can poll one or more devices, retrieve their status, and update HCA internal state. One important point about the poll element: All it does is add a status request for each device to an internal queue and then move on. This means that it may take a while for all the status requests and replies to happen. You can’t do a Get Status element and then expect that all status requests have been received by the time the next element in your program happens.
You can create a program that uses the Get Status element and then schedule this program to run periodically to make sure that HCA is up to date with the actual device states.
Another method, used when HCA starts, is to enable a status poll of all devices when HCA first loads your file. This can be configured on the Startup tab of HCA – Properties. Like the get Status element these status requests are added to an internal queue and processed over time. Also you can configure HCA to hold off sending these status requests until after HCA has been “up” for a set length of time. You may want to use this delay if you have programs that run when HCA starts and want a “clear channel” on the powerline.
The last method HCA has for keeping its internal state up to date is for devices who have the “confirm receipt of command” option enabled. As part of confirming receipt of a command, HCA actively polls the device for its status.
All of these methods work together to keep HCA up to date with the “real world”. Use them carefully as each command on the powerline removes bandwidth for your action commands - like ON and OFF.