How to improve W800RF performance with HCA

kwilcox

Active Member
Now I know most everybody here uses something different, but there have been a few questions from other HCA (Home Control Assistant) users regarding mysteriously dropped W800RF inputs which manifest themselves as sensor trips not activating their associated triggers.

Well, I'm happy to say that I've solved this issue. The problem occurs because HCA has a built in "debounce" for W800RF input. It does this to eliminate the duplicate commands that most X10 sensors send (hawkeyes, for example, send 5-6 repeats). HCA typically sets this debounce to 300 milliseconds. This means that when several sensors are tripped simultaneously, only the first one will be recognized by HCA.

So, how to fix this? Well, you have to do two things: Eliminate the debounce setting and then manually debounce the W800RF programatically. The first part is easy. HCA maintains the debounce setting in the registry here:

HKEY_LOCAL_MACHINE/SOFTWARE/AdvancedQuonsetTechnology/HCA/Advanced/WirelessDebounce

You need to completely exit out of HCA before modifying this value or it won't be recoginzed. Change this value from 300 to 10.

Now for the programming part. You need to set up a program whose trigger is the wireless sensor you're debouncing. In advanced settings set the program to ignore subsequent triggers from the device. Program logic is simple, consisting of only two programming blocks. Use the "On" program block to activate the original program or device that was triggered by the sensor, then use the "Delay" program block to simply wait for 2 seconds. This way, the first received trigger will activate the original operation and subsequent triggers will be dropped for the 2 second delay period.

Note: there's a bug in HCA that you need to know about: If you use the "On" program block to activate a program, make sure that original program has a trigger. The dropdown list in the On program block won't show the program unless this is the case. After you've selected it, you can go back to the original program and remove the dummy trigger. I'll send this into HCA for a bugfix, but the workaround isn't a big deal since the original program, if triggered by the wireless sensor, would show up correctly in the dropdown box.

Caveat:

If you are bridging an X10 wireless keypad directly to lighting then you may end up putting more traffic on the powerline. In practice, I've not seen any issues with this however. Also, if you have a large wireless sensor network, I'd recommend turning off logging for received events. It'll save big time on Disk IO's.

Enjoy the fix! It completely eliminates the "dropped sensor" issue and dramatically improves the reliability of large sensor based implemenations.
 
I just received a reply from the folks that make HCA (you just gotta love companies whose technical support staff respond to questions on Sundays btw ;)). The program dropdown behavior in the "On" block properties that I described as a bug is actually known behavior. Programs only appear there if they have a trigger defined. In any event, the workaround applies.

Also:

Subsequent testing with wireless keypads directly controlling lighting (in this case, HCA is bridging an entire housecode) shows that this increases powerline traffic a lot. If you are only using HCA to bridge housecodes, then the default debounce logic works great and I wouldn't implement the above technique. In my case, I turned off housecode bridging for my keypad housecode and then plugged in one of my modified keypad base receivers (I've extended the range by directly coupling the antenna to the circuit via a 22pF ceramic cap) to handle my wireless keypads.
 
Back
Top