Please login or register.

Login with username, password and session length

Author Topic: AHP messes up the registry so that no version will work correctly  (Read 4078 times)

AZDoug

  • Full Member
  • ***
  • Helpful Post Rating: 0
  • Posts: 29

I've been successfully using CM11s to control security and indoor lighting since the early 90s, so when I bought AHP a few months ago, I expected an easy transition.  Nothing could have been further than true and only the fact that so many folks here have tamed the beast and the fact that I don't give up easily makes me continue fighting with it. 

I'm not sure I've got all the answers yet, but I thought I'd relate my experience with AHP on my Vista 32 computers for starters.  If no version of AHP will allow creation and editing of a simple 2 or 3 module program, then it isn't surprising that anything more complex doesn't work correctly.  I've used the latest U.S. version as well as the earlier versions that are recommended.  I also installed the latest BMB European version too. 

After a lot of hand wringing and muttering under my breath, I determined that no version of AHP would operate correctly on my Vista 32 machine any longer.  This might be a strong statement for some to swallow, but after a fresh install of any one of the various versions, it was not possible to perform a simple edit to module when there are only a couple modules in the program and only the simplest of timers. 

It is possible to create a program with as many modules or timers as possible.  There's no problem saving it or downloading it to the CM15A either.  If it worked as expected, then that would be the end of story, but it didn't/doesn't/won't!

What I found, by accident, is that if I tried to change the address of a module, AHP reported that the address was already in use by a module that happened to be assigned address A1, even though there was no address conflict.  It was impossible to change the address or module type, and I don't think that deleting the module I was trying to edit and recreating it made any difference.  At first I thought maybe the .AHX file was the problem, but there were no syntax errors.  When I installed the .AHX files on a Vista 32 laptop that had a fresh OS install and a fresh install of the BMB version of AHP, then there was no problem editing any module in the program.   From comments in the forum, I learned that the X10USA program has DST hard coded in the firmware (what were they thinking).  Since we do hot have DST here in Arizona, the European versions seems like the only choice for my use.

I finally ended up removing any trace of x10 or AHP from the Program Files, Program Data and Windows directories.  After that I removed 50 or more keys from the registry that related to AHP or X10.  I haven't had the courage to try installing AHP in that machine yet, but the modules and timers I had been using with the CM11 seem to be working under the BMB program loaded on my laptop.  There is still an issue of the clock moving, but at least everything seems to work now.  I'll cover that in another topic.

Does anyone have any recommendations or thoughts on how to get AHP working again without the drastic steps I took?  The BMB program seems to be missing something as it doesn't save the timer resolution setting and the battery timer may not be functional.   I use a custom Lat Long setting and I notice that the choice of cities is no longer available (not that I care). 






Logged

Dan Lawrence

  • Hero Member
  • *****
  • Helpful Post Rating: 68
  • Posts: 3991
Re: AHP messes up the registry so that no version will work correctly
« Reply #1 on: March 18, 2010, 10:04:25 PM »

Your AHP install my have been version 3.236, which X10 has been sending out with new orders despite that the known fault is it's a buggy version.  AHP version 3.228 seems to be fine under Vista and Windows 7.   
Logged
I don't SELL this stuff... BUT I sure do ENJOY using it!!!

Knightrider

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 62
  • Posts: 1748
  • I love my WM100!
    • This Automated House
Re: AHP messes up the registry so that no version will work correctly
« Reply #2 on: March 18, 2010, 10:39:07 PM »

I'll make a simple suggestion and we'll see if we can hammer away at this a bit at a time.

Under TOOLS>>Preferences have you placed a tic by the box that allows multiple modules on the same address?
This may help the macro issue.  Also, there's some sort of macro wizard that assumes you are an idiot and will make you program macros in basic, intermediate and advanced modes. 
Been a long time since I've seen the wizard, but you can somehow dump it and all will be happy.
Logged
Remote control is cool,

but automation rules!

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: AHP messes up the registry so that no version will work correctly
« Reply #3 on: March 19, 2010, 03:28:08 AM »


Some time ago I found that editing an existing AHP program would often cause it to fail in one way or another.  Whether or not the bugs responsible for this problem have been fixed in later AHP versions, I can't say.
Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

AZDoug

  • Full Member
  • ***
  • Helpful Post Rating: 0
  • Posts: 29
Re: AHP messes up the registry so that no version will work correctly
« Reply #4 on: March 20, 2010, 12:57:02 PM »

Under TOOLS>>Preferences have you placed a tic by the box that allows multiple modules on the same address?
This may help the macro issue.  Also, there's some sort of macro wizard that assumes you are an idiot and will make you program macros in basic, intermediate and advanced modes. 
I'm sure I've tried allowing multiple modules to have the same address.  In this case, it's not that there is a conflicting address, but AHP thinks there is and there is  no way to eliminate this behavior.  You can uninstall the program, scrub out all the drivers, remove everything from the program data directories, remove the catalog directories and still the next time you install the program, create two modules with different addresses and then try to edit one of the modules, AHP gives an error when there is none. 
At that point the only thing that will solve the issue is to reinstall the OP system or scrub the registry of any hint of AHP, and X10,  and activehome. 
Merely uninstalling, rebooting and reinstalling will not solve this problem. 

I'm not sure how I got in this situation.  Naturally, the first version of AHP I installed was the one shipped with the hardware.  After that, I backed up to 204, and then upgraded to 228 as recommended here in the forum.   And then, much later after a zillion problems, I installed the BMB version.  At that point the machine was poisoned and nothing seemed to help. 

The main problem with the operation of the hardware was that timed events kept moving day by day.  I set up a chime to ring several times a day and it would move by several seconds a day, even though it may start out OK for 24 hours or so.   

I can't help buy wonder if the problem started when I imported the file used with my CM11 and edited it.  I noticed that there were several timer events that did not make the translation correctly.  I edited them, but I wonder if at that point it was already too late. 

I can't help but think I'm not the first person that has had this kind of problem.
Logged

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: AHP messes up the registry so that no version will work correctly
« Reply #5 on: March 20, 2010, 02:53:04 PM »

The main problem with the operation of the hardware was that timed events kept moving day by day.  I set up a chime to ring several times a day and it would move by several seconds a day, even though it may start out OK for 24 hours or so.   

Did the chime ring earlier (clock runs fast) or later (clock runs slow) than the programmed time?

The usual problem with a CM15A clock which runs fast is noise on the power line.  The CM15A clock keeps time by counting AC cycles and a voltage spike or pulse of noise may be improperly counted as a cycle.

Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

AZDoug

  • Full Member
  • ***
  • Helpful Post Rating: 0
  • Posts: 29
Re: AHP messes up the registry so that no version will work correctly
« Reply #6 on: March 20, 2010, 03:39:34 PM »

Did the chime ring earlier (clock runs fast) or later (clock runs slow) than the programmed time?
The usual problem with a CM15A clock which runs fast is noise on the power line.  The CM15A clock keeps time by counting AC cycles and a voltage spike or pulse of noise may be improperly counted as a cycle.

The chimes are ringing early by a minute 30+- seconds after over a week of operation.  It seems stable now.  I have the CM15 plugged into the same circuit as my refrigerator, so that is probably not the best place.  The original location may have been even worse as the timer moved daily and there was a signal path issue that really threw me.  I've got more than one issue with getting PLC signals to where the have to go, but I always managed to get the CM11 to work OK with the half dozen or so modules it controls.  I'll put the CM15 on the circuit where the CM11 spent most of it's time. 

It seems like the AHP program and .ahx file are no longer causing me any grief, so maybe I can focus on signal issues or anything else that gets in the way.  I have always liked the things the CM11 did and used them in my son's house, my mother's house and the three houses we lived in since the mid-90s.  The AHP program has tested my patience, but it's always reassuring to read the comments from those who have been there before. 
Logged
 

X10.com | About X10 | X10 Security Systems | Cameras| Package Deals
© Copyright 2014-2016 X10.com All rights reserved.