X10 Community Forum
🖥️ActiveHome Pro => ActiveHome Pro General => Software Problems & Bugs => Topic started by: Tuicemen on January 15, 2011, 07:49:58 PM
-
This thread was started as a way to have a single list to track all current AHP bugs.
With this list, the developers have a single place to check for reports of new issues, and can ask for more detail in the thread if needed.
The moderators have complied this list, and are keeping it current. As new bugs are reported, they get added to the top of the "Outstanding Bugs" section.
When the developers report a bug that has been fixed, it gets moved to the "Reported Fixed Bugs" section.
Once users can confirm a bug has been fixed, it is moved to the "Confirmed Fixed Bugs" section at the bottom.
Please let us know if there are bugs that are not listed, or if you can confirm that any of the "Reported Fixed" bugs have been fixed in the latest release.
List of outstanding Bugs as of 3.318:
Bugs that have been reported by the users, and are waiting to be fixed by the developers:
* SDK sends multiple RF commands when used with a CM19A
(v3.318, added 5/15/2012 by Tuicemen)
*AHP fails to load after locking up. If AHP is running and and locks up, a task manager "kill" results in AHP failing to load next time. It also sometimes stops SDK-built programs from working. An "error getting X10 net interface" appears. Some have noticed this with improper PC shut downs, or with a certain Windows Update in Windows 7. Fixing this should be considered a high-priority.
(3/25/2011: Confirmed by X10 developer, but seemingly rare and hard to reproduce at the time. That developer has left X10 since then.)
* User is prompted to choose a file location and name when saving their AHX file, if they used the "browse" function during their session in AHP (such as when adding a Windows command to a macro). The folder defaults to the last-used folder, not the one from which the AHX file was loaded.
(added 2/6/2012 by Noam, but I think it has been around a long time. Confirmed still present in 3.318)
* Commands are no longer "grouped" in macros (ex: "E1, E2, E On" is now "E1, E On, E2, E On").
(v3.318, added 12/27/2011 by Noam)
* Video freezes when other X10 activity occurs.
(v3.314, added 11/2/2011 by Noam, Still reported in 3.318)
* AHP crashes with a runtime error when adding an SC546A Chime Module from the "Pro Modules" category.
(original version unknown, added 10/19/2011 by Noam)
* Macros triggered by a security sensor are run twice, while macros triggered by a normal HC/UC are run only once.
(v3.318, added 10/11/2011 by Noam)
* After upgrading to version 3.318, you can no longer downgrade to an earlier version by installing it over the top of the current one. You need to uninstall the newer one first.
(v3.318, added 10/6/2011 by Noam)
* Macros triggered by an "Off" command (ex: C9 Off) blink when the "On" command (ex: C9 On) is received, but not when the "Off" command is received. The macros still run correctly, though (this is purely cosmetic).
(added 6/26/2011 by Noam, but I think it has been around a long time. Confirmed still present in 3.318)
* After downloading to the CM15A and exiting the program, the "Download needed" indicator returns to the status bar the next time AHP is opened, even if no changes were made. Downloading again does not properly clear the flag (see next item for more).
(v3.311 added 4/18/2011 by Noam, confirmed still present in v3.318)
* When a download is needed, the "Exit without downloading?" prompt is not working properly. The user is prompted, "Are you sure you want to exit without downloading?" "Yes" correctly closes AHP without downloading. "No" currently exits without downloading, but clears the "download needed" indication - which is clearly wrong. It should either close the dialog and return to AHP, or download and exit (in which case it should be changed to "Download and Exit"). "Cancel" closes the dialog and returns to AHP. This is fine if "No" would exits WITH a download). However, if "No" is going to close the dialog and return to AHP, then "Cancel" is not needed.
(v3.311 added 4/18/2011 by Noam, confirmed still present in v3.318)
* Turning on a SoftStart module that was dimmed before being turned off results in an Extended Dim command to the previous dim state, instead of the full 100%. In AHP, the slider momentarily goes to the previous dim state, but then goes to 100%.
(v3.310 added 4/14/2011 by Noam, confirmed still present in v3.318)
* AHSDK sometimes crashes, which prevents any further SDK commands until the "debug" notice is closed.
(first noticed around v 3.305, added 4/6/2011 by Noam, confirmed still present in v3.316)
* Changing a module between "Lamps" and "Old Lamps" does not change the color of the bar at the top until you go out of the room (or AHP) and go back in.
(v 3.310, added 3/25/2011 by Noam, confirmed still present in v3.318)
(ErikP 3/25/2011: Confirmed, but low priority since it is purely cosmetic)
* "Florescent Decorator Switch" (WS13A-L) sends extended commands if defined as a "New" lamp.
(v 3.310, added 3/25/2011 by Noam, confirmed still present in v3.318)
* SDK sends extended commands for Unit codes defined as SoftStart modules in AHP. This happens when sending a specific "ON" command.
(v 3.310, added 3/25/2011 by Noam, confirmed still present in v3.318)
(ErikP 3/25/2011: Currently all commands are run through the same code path which slightly alters commands based on hardware states, so SDK commands may be converted based on module status. This isn't really ideal, so is now on the active bug list.)
* Changing a module between "Lamps" and "Old Lamps" should keep the current "module type" selection, instead of defaulting to the first item in the list.
(v 3.302, added 3/25/2011 by Noam, confirmed still present in 3.318)
(ErikP 3/25/2011: This is intended behavior because only with the "Old Lamps" and "Lamps" is it possible for the module type to exist in more than one category. I will put this in the active bug list, since it would be convenient for those who need to switch module types.)
* The CM15A sends duplicate commands from timers and macros after a reboot or restart of x10nets, until AHP is opened and closed.
(added 3/23/2011 by Noam, confirmed still present in 3.318)
(ErikP 3/29/2011: Problem CAN be duplicated in testing. This is on the list to look into.)
* Opening the Activity Monitor starts two new iexplore.exe processes, without windows. They don't stop when you close AHP.
(added 2/19/2011, confirmed still present in 3.318)
* The "Check for Update" function cannot find new versions of AHP.
(broken since v3.228 9/5/2008, confirmed still broken as of 10/04/2011 - v3.316 can't find update to 3.318)
(ErikP 3/25/2011: Confirmed. This is at the top of my regular priority work list. Its been delayed a bit due to a lot of high priority workload recently, but should be ready soon. The bug is entirely server side, so once it is fixed it will not require an AHP update to take effect.)[/color]
List of Bugs that have been REPORTED fixed as of 3.318:
Bugs reported as fixed by the developers, but not yet confirmed by the users:
* Video goes black and/or flickers in AHP.
(v3.315 added 6/16/2011 by Noam)
(reported fixed in 3.316 7/1/2011. Waiting for confirmation from users)
* The Intro Wizard crashes, when trying to go through the Timers or Macro sections.
(added 4/11/2011 by Noam, confirmed still present in v3.314)
(Reported fixed in 3.315 6/9/2011 - waiting for confirmation from the users)
* There are no Dim, bright or extended X10 messages being sent with the CM19A TM751 combination
(added 2/7/2011)
(ErikP 3/25/2011: Fixed in 3.310. Please let me know if you are seeing anything different, this is kind of important since its really the core functionality of the application.)
List of Bugs that have been CONFIRMED fixed as of 3.318:
Bugs confirmed as fixed by the users:
* Macros with time-based conditions do not work for some users. Other conditions work fine for those users.
(added 3/6/2011 by Noam, Fixed in 3.315 6/9/2011)
* Non-SoftStart lamp modules fail to turn on when a dusk on timer is used. I haven't tested the dawn setting or a off one.
(problem began with 3.302, but proper settings took care of this one)
* Module history button should return the last transactions for that device's address, not actions for all house codes.
(added 2/12/2011, corrected in 3.310)
* Dim Status of new softstart defaults to either "Off" or "100%"when the Status Report is opened or AHP is closed and reopened.
(added 1/19/2011 by Noam, corrected in 3.310)
* The CM15A does not correctly adjust for Daylight Savings Time when not connected to the PC.
(corrected in v 3.264 3/23/2010)
* The issue with installing plug-ins after AHP still causes issues.
(added 1/6/2011, fixed with new installer in v3.310)
* Installing iwatchout (video plug-in) causes AHP to fail.
(fixed with new installer in v3.310)
* AHP and the SDK still reports info received from some security sensors
In my case I get M1 SOCIALITE, c8,...... reported with the SDK and M MTCDDVD in AHP
(fixed in 3.318 10/3/2011)
Edited 5/16/2012 by Noam. Edited two items for clarity.
-
well I'm not sure whats going on! ??? ???
I decided that maybe the like at the download center was pointing to the wrong file.
So I went to http://software.x10.com/pub/applications/activehomepro/ and downloaded the file. hey third time was a charm! ::) :'
now if the link in AHP would work it would save a lot of hassle! ::) :'
-
went there, done that. still at 3.296 one one xp sp3. maybe this one needs 4 tries. win7 64bit updated first try.
-
well I'm glade it's not me! rofl
I thought I was going crazy. I'm not sure if it is the link at http://www.x10.com/support/support_soft1.htm that is in compatible with some versions or It just needs 3-4 tries ::) :'
in any case the link I posted first only took one install try, however I had tried twice before with the other link! ::) :'
-
went there, done that. still at 3.296 one one xp sp3. maybe this one needs 4 tries. win7 64bit updated first try.
Did the version listed next to the link say 3.296, or 3.304?
If the version listed on that page was not correct, you probably need to clear your browser cache and try again.
-
Version states 3.304 ;)
Or at least it did here! ::) :'
-
Version states 3.304 ;)
Or at least it did here! ::) :'
Then I'm confused. Did it download an earlier version? Since they keep overwriting the same installer with the new version, perhaps there was still a caching issue int the browser.
Now, perhaps we need a sticky post at the top, with an itemized list of the "bugs," where they status can be listed (open / in progress / fixed).
-
I thought as bugs were found or fixed I could add/remove them from the first post in this thread!
this way a programmer wouldn't have to sort threw multi posts/threads.
Seems the issue with installing plug-ins first then AHP may still be a bug as well! B:(
-
Version states 3.304 ;)
Or at least it did here! ::) :'
that is same link I used and it definitely said 3.304 for me too. It worked on an win7 32bit machine first try then immediately after that (10 minutes?) I downloaded again same link and it did not work on the xp 3 times.
-
I thought I had installed 3.301 but today it says I only have 2.96. I have no idea what is going on. I am running XP sp3. Any ideas? Also where can I get 3.3 04? The following link only takes me to 2.296.
-
Try clearing your browser cache, and downloading again.
-
I thought I had installed 3.301 but today it says I only have 2.96. I have no idea what is going on. I am running XP sp3. Any ideas? Also where can I get 3.3 04? The following link only takes me to 2.296.
Go to http://www.x10.com/support/support_soft1.htm , the first item is 3.304.
-
I just replaced two older Lamp Modules with newer SoftStart ones.
I changed the module type in AHP, saved, and re-downloaded to the CM15A.
I confirmed that the correct Extended dim code was sent at the proper time (using the timers), and that the lamps are actually dimmed to the correct level.
However, when I go into AHP, it shows those lamps are off. All of my other lights (defined either as "old" lamp modules, or as Florescent Decorator switches) store the correct on/off/dim states.
I re-set the module to the correct brightness in AHP, (even though it was already there), and closed AHP again.
When I re-opened, those two were showing as "off" again.
I'm using AHP 3.304 on Windows 7 Pro, 64-Bit.
Has anyone else see this behavior?
-
I thought I had installed 3.301 but today it says I only have 2.96. I have no idea what is going on. I am running XP sp3. Any ideas? Also where can I get 3.3 04? The following link only takes me to 2.296.
I ran into a similar problem today, downloading the new SDK at work.
It kept downloading the old version.
I wonder if there is a caching issue on the proxy server or something...
(I ended up copying the file from my home PC, using a remote session).
-
Let me give an update on the "Dim Status" problem I found, based on some tests I did this morning.
Setting the dim level using Extended Codes (as is done using the GUI if the module is defined as a "SoftStart" module, or using the AHCMD at the command line), displays correctly in the GUI. However, closing AHP, or just opening the Status Report (press F3 to open it) causes the dim level to either rise to 100%, or drop to 0% (off).
This depends on what the last "on/off" state of the module was, according to AHP. In other words, AHP is only storing the "ON" or "OFF" state, and igoring any Extended dim codes after that.
However, if I use AHCMD to send "standard" bright or dim commands, those are stored correctly.
Also, it seems that AHP is not interpreting an ExtCode 31 3f (immediate full brightness) command properly.
AHP is flipping the toggle on the switch to "ON," but leaving the brighness at the last level it was at. In other words, if I used a extended code to set the brightness to "0", then sending a "3f" flips the toggle back on, but leaves the slider at the bottom.
Without a lamp module here at work, I can't say if the SDK is sending it correctly or not, but I see what AHP shows).
I have a feeling these two are related, and the same code fix might correct both issues.
I reported it to the developers, I am waiting to hear something back.
-
I heard back from the developers, briefly, on Friday afternoon.
The answer I got back indicated that they think the two issues are related, and are tied to the way AHP stores the bright/dim levels.
They said they are going to look into it, and I'll report back what I hear.
-
I'm not sure why with each update , long time users have to jump threw hoops to get there system working again!
The latest blunder was the way Softstart modules are listed in AHP. If you a new user this isn't a issue!
However long time users had their light modules configured under Lamps. Now we have to edit each module to use Older Lamps (no softstart) B:(
It seems the new softstart modules now get the honour of being in the lamp category! ::) :'
Anyways not a bug but I did update the OP with some old bugs still present on my system!
>!
-
... However long time users had their light modules configured under Lamps. Now we have to edit each module to use Older Lamps (no softstart) B:( ...
I'm not trying to defend them, but the problem was caused by the hardware team, when they released a new module design, but kept the same model number as the old version.
If the new one were backward-compatible, that wouldn't have been an issue. But how hard would it have been to change the model number?
The new development team, having inherited this problem (they came on board AFTER it had been done), had to make a decision on how to handle it. The rationale for doing it this way (as it was explained to me) was that the SoftStart lamp modules came out a few years ago, and they sold out of the older ones soon after that. They haven't sold any non-softstart modules, so newer users (who wouldn't have any "old" modules) could get confused, and choose the wrong type.
I guess they figured there were more SoftStart lamp modules defined in AHP, overall, than there were older ones.
This problem only affects those of us with older lamp modules, and it is a one-shot deal. Once we fix it, we should never have to bother with it again.
Any new Softstat modules being added to the system would be done correctly.
--Noam
-
Hey newbie are confused as it is!
I think they just wanted us all confused ! ::) rofl
JK! >!
-
There seems to be no dim or bright control of both older and soft start modules. When using the CM19A TM751 combination.
If an old style module is chosen. The On used for 100% is issued but no dim commands follow. The Red LED does not flash when the dims commands are to be sent. With Soft Start no LED action happens at all. Use a CM15A and all combinations work as expected.
Using a Smarthome 1132CU controller as a monitor. There are no Dim, bright or extended X10 messages being sent with the CM19A TM751 combination.
I had indicated this problem a few revisions back and actually assisted a user to get dim working by reinstalling an older version of AHP. That was using the CM19A TM751 combination.
Since X10 likes to sell the real low cost AHP kit with the CM19A and TM751. The least they can do is fix this problem.
-
I want to throw in my $2 complaint. Seems silly, but shouldn't the "module history" button on the device in AHP return the last functions of said device and not just the last 5 or 10 previous x10 transactions?
i.e. module history button on A1 should return the last A1 transactions, not actions on P or C.
-
I want to throw in my $2 complaint. Seems silly, but shouldn't the "module history" button on the device in AHP return the last functions of said device and not just the last 5 or 10 previous x10 transactions?
i.e. module history button on A1 should return the last A1 transactions, not actions on P or C.
I second the motion. All in favor?
-
I just looked at this, looks like a bug that Murphy added! rofl
Originaly when the history button was added it did show last info fo that device only.
I'm not sure when that bug got introduced.
I'll add it to the list.
-
I just looked at this, looks like a bug that Murphy added! rofl
Originaly when the history button was added it did show last info fo that device only.
I'm not sure when that bug got introduced.
I'll add it to the list.
It's been that way for a very long time.
-
I installed version 3.306, which was released today.
They added support for the new Security console, but didn't fix any of the existing bugs (from what I can tell).
The SoftStart status bug is still there. Dim status still goes to either 0% or 100% (depending on last "on/off" command received) when going into the Status Report, or when exiting the program.
I did notice, however, that the activity Log now lists Extended Bring/Dim commands in a more user-readable format.
Of course, since they hide the actual command, it might make troubleshooting a bit harder for some.
-
Well the clicking on check for update still don't work.
The Activity monitor never was the best way to trouble shoot!
Using the ahcview.exe in the SDK was always a better option ::) :'
I guess someone should point the programmers to this thread! ;)
>!
-
Well the clicking on check for update still don't work.
The Activity monitor never was the best way to trouble shoot!
Using the ahcview.exe in the SDK was always a better option ::) :'
I guess someone should point the programmers to this thread! ;)
>!
Yes, that was one of the bugs listed, which isn't fixed yet.
I've pointed them to it several times. I've been told they are working these issues (which doesn't give any sort of time frame, only that they haven't fixed them yet ;-) ).
-
Here's another one:
Opening the Activity Monitor starts two new iexplore.exe processes, without windows. They don't stop when you close AHP.
Looks like a bug to me.
Link to the original post here:
http://forums.x10.com/index.php?topic=22677.0
-
Might as well throw in my issue B:(
When using a "time range" condition (If A happens between times B and C, then D), a Macro will not function. Macro will work without the "time range" condition enabled however (If A happens then D). All proper plugins are installed.
Details here: http://forums.x10.com/index.php?topic=22484.0 (http://forums.x10.com/index.php?topic=22484.0)
-
i just listed a solid simple workaround for u on ur other thread.
-
With the release of 3.310 this morning, I moved a few of the bugs that I confirmed are fixed down to the bottom of the list, and added a few more that I found:
* Changing a module between "Lamps" and "Old Lamps" does not change the color of the bar at the top until you go out of the room (or AHP) and go back in.
(v 3.310, added 3/25/2011 by Noam)
* "Florescent Decorator Switch" sends extended commands if defined as a "New" lamp.
(v 3.310, added 3/25/2011 by Noam)
* SDK sends extended commands for Unit codes defined as SoftStart modules in AHP
(v 3.310, added 3/25/2011 by Noam)
* Changing a module between "Lamps" and "Old Lamps" should keep the current "module type" selection, instead of defaulting to the first item in the list.
(v 3.302, added 3/25/2011 by Noam)
There is more detail on these bugs in the new thread for 3.310:
http://forums.x10.com/index.php?topic=23042
I can't test several of the bugs, so if anyone sees more that are fixed, please report it here, and one of us can update the bug list accordingly.
-
Based on the bugs reported here i have been doing some focused testing today. Here are the results, and any clarifications, and requests for more data where needed. Thank you everyone for your help tracking and eliminating these bugs :)
* Changing a module between "Lamps" and "Old Lamps" does not change the color of the bar at the top until you go out of the room (or AHP) and go back in.
(v 3.310, added 3/25/2011 by Noam)
Confirmed, but low priority since it is purely cosmetic
* SDK sends extended commands for Unit codes defined as SoftStart modules in AHP
(v 3.310, added 3/25/2011 by Noam)
Currently all commands are run through the same code path which slightly alters commands based on hardware states, so SDK commands may be converted based on module status. This isn't really ideal, so is now on the active bug list.
* Changing a module between "Lamps" and "Old Lamps" should keep the current "module type" selection, instead of defaulting to the first item in the list.
(v 3.302, added 3/25/2011 by Noam)
This is intended behavior because only with the "Old Lamps" and "Lamps" is it possible for the module type to exist in more than one category. I will put this in the active bug list, since it would be convenient for those who need to switch module types.
* The CM15A sends duplicate commands from timers and macros after a reboot or restart of x10nets, until AHP is opened and closed.
(added 3/23/2011 by Noam, confirmed still present in 3.310)
No Repro in testing. AHP loses connection to X10net after it is restarted and can not send any commands until connection is reset by restarting AHP. This is the expected behavior
* The CM15A does not correctly adjust for Daylight Savings Time when not connected to the PC.
(added 3/6/2011 by Noam)
No repro in testing. We ran a large number of tests the week before the DST change using build 306, and all of the hardware functioned correctly both connected and not connected to the PC. I reran several of them today and still no problems. Did any of you have problems with the recent DST change? This bug should have been fixed sometime ago. If you did have a problem please let me know what build you were using at the time and exactly what behavior you saw.
* Macros with time-based conditions do not work for some users. Other conditions work fine for those users.
(added 3/6/2011 by Noam)
No repro in testing. I have been getting intermittent reports of this from a few sources, but have never been able to reproduce it in testing. Even more odd the bug seems to disappear without any fixes from most reports i have gotten. If you don't mind sending me your ahx files containing a macro showing this bug i would be happy to try and reproduce this again using those files.
* If AHP is running and and locks up, a task manager "kill" results in AHP failing to load next time. It also stops SDK-built programs from working. An "error getting X10 net interface" appears. Some have noticed this with improper PC shut downs, as well.
Confirmed, but very rare. I have only seen it once, and have not been able to repro since in order to do any more testing. If you have this bug now or can reproduce it, please send me a copy of your x10active.xml from the broken state. By default this is located in C:\Users\All Users\X10 Settings.
* The "Check for Update" function cannot find new versions of AHP.
(broken since v3.228 9/5/2008, confirmed still broken as of 3.306)
Confirmed. This is at the top of my regular priority work list. Its been delayed a bit due to a lot of high priority workload recently, but should be ready soon. The bug is entirely server side, so once it is fixed it will not require an AHP update to take effect.
* The issue with installing plug-ins after AHP still causes issues.
(added 1/6/2011)
No Repro in testing. Ideally whatever lingering bugs there may have been around plug-in installation should have been fixed with the new installer framework this release, or at the very least transformed into newer and shinier bugs.
* Installing iwatchout (video plug-in) causes AHP to fail.
No Repro in testing.
* AHP and the SDK still reports info received from some security sensors
In my case I get M1 SOCIALITE, c8,...... reported with the SDK and M MTCDDVD in AHP
Confirmed. Still trying to fix this one, it is very persistent.
* There are no Dim, bright or extended X10 messages being sent with the CM19A TM751 combination
(added 2/7/2011)
Fixed in 310. Please let me know if you are seeing anything different, this is kind of important since its really the core functionality of the application.
In case anyone needs the clarification "No Repro" is dev speak for "not able to reproduce the bug during testing". This doesn't necessarily mean there is no bug but it means I was not able to find it with information I currently have on the bug.
Thanks again everyone for some excellent feedback! #:)
Erik
-
Based on the bugs reported here i have been doing some focused testing today. Here are the results, and any clarifications, and requests for more data where needed. Thank you everyone for your help tracking and eliminating these bugs :)
Erik -
Thanks for staying on top of this. Some of them were still listed, because I have no way to confirm they were fixed (like the DST thing - mine stayed connected to the PC, so of course it worked).
If users can confirm they are fixed, I'll move them to the "fixed bugs" list. :)
* The CM15A sends duplicate commands from timers and macros after a reboot or restart of x10nets, until AHP is opened and closed.
(added 3/23/2011 by Noam, confirmed still present in 3.310)
No Repro in testing. AHP loses connection to X10net after it is restarted and can not send any commands until connection is reset by restarting AHP. This is the expected behavior
I can reproduce this EVERY time. Here's how:
Create a macro that runs a simple command (like turning on appliance module C16, for example). Download it to the CM15A.
Close AHP, and reboot the PC.
After the PC reboots, DON'T OPEN AHP YET!
Once the Pc is up, use a remote to trigger the macro.
After it is done, open AHP, and check the Activity Monitor. You'll see doubles of the macro and the "C16 On" commands it ran.
Close AHP, and activate the macro again.
Open AHP and check the Activity Monitor again. It will only show one copy of the "C16 On" command in the macro.
With AHP closed, stop and restart the X10nets service
Trigger the macro from the remote again.
Open AHP and check the Activity Monitor. You'll see two of the "C16 On" commands inside the macro.
Close AHP, and run the macro again.
Open AHP and check the Activity Monitor one more time. You'll only see one "C16 On" command.
I hope that was clear enough.
Thanks.
--Noam
-
Perfect Noam :)
Unfortunately I followed this to the letter and I still only see one "C16 On" command in my activity monitor. Is it possible there is something in your environment transcoding the remote command a second time, or echoing the PLC command?
-
Perfect Noam :)
Unfortunately I followed this to the letter and I still only see one "C16 On" command in my activity monitor. Is it possible there is something in your environment transcoding the remote command a second time, or echoing the PLC command?
I suppose it is possible, but I saw this on three different PCs (Win7, and XP), and another user saw it, too.
And why would something repeat the PLC command ONLY until I open and close AHP. And then doit again if I stop and restart the service, ONLY unitl I open AHP?
You don't have AHP opening at startup, do you?
Before I brought a PalmPad to work, I was able to reproduce it by triggering the macro using AHSDK, too!.
I'll send you an e-mail with some more information.
-
I will keep trying to reproduce this. The error could be configuration specific, so i need to find the correct configuration and follow the steps to reproduce.
-
I will keep trying to reproduce this. The error could be configuration specific, so i need to find the correct configuration and follow the steps to reproduce.
Erik -
I had this on two XP machines, and one Win7 machine (all on 3.306). I tested on the two XP machines after upgrading to 3.310, and the problem is still there.
I only have SmartMacros and MyHouse installed, and AHP is NOT set to run at startup. I think that's the key.
Once AHP starts up, it fixes whatever the issue is. If I close AHP and then stop and restart the x10nets service, the problem comes back.
-
I'm running 3.310 with NO plug-ins and do not get what you are experiencing so could it be one of your two plug-ins that's the cause? If that is what's happening perhaps that needs investigating.
-
Erik -
You didn't mention the following two items from the Bug List:
* "Florescent Decorator Switch" (WS13A-L) sends extended commands if defined as a "New" lamp.
Does the WS13A-L respond to Extended Dim commands, since it isn't a dimming module? (I don't have one, so I can't test it, but I'm using that definition for my SmartHome relay switches (which don't respond to Extended Dim commands). Up through 3.306, AHP sent only "On" or "Off" to the WS13A-L. In 3.310, it is sending Extended Dims, unless you use the "Old Lamps - No SoftStat" category.
* Opening the Activity Monitor starts two new iexplore.exe processes, without windows. They don't stop when you close AHP.
Is there any update on the status on those?
--Noam
-
Both are still ongoing.
Unfortunately, one of our test modules had an accident, so I am waiting for replacement hardware to test the WS13A.
As for the activity monitor, the IE processes are opened because some of AHP's functions are achieved by building HTML and then asking IE to display it in a window frame. I have not found the found the exact code yet to determine if this is a bug or intended behavior. It is very likely a bug since I can think of no reason for this to be intended, but I will let you know when I am more sure.
-
Re: Activity Monitor opens starts two new iexplore.exe processes, without windows. They don't stop when you close AHP. .
I suspect it's one or more of the plug-ins for AHP are the scorce of this problem. I run 3.310 with NO plug-ins (don't need any) and no iexplore.exe processes appear when the Activity Monitor is opened.
-
* The CM15A does not correctly adjust for Daylight Savings Time when not connected to the PC.
(added 3/6/2011 by Noam)
No repro in testing. We ran a large number of tests the week before the DST change using build 306, and all of the hardware functioned correctly both connected and not connected to the PC. I reran several of them today and still no problems. Did any of you have problems with the recent DST change? This bug should have been fixed sometime ago. If you did have a problem please let me know what build you were using at the time and exactly what behavior you saw.
Long time lurker, first time poster. I can confirm that auto DST adjustment (running CM15A standalone) WORKED CORRECTLY at least as far back as version 3.285 (which I'm still running)... worked last November in the standard time reversion, and worked again correctly this March when we went back to DST. I've scoured the forums looking for anyone else reporting a confirmation of this wonderful fix, to no avail... Since the release notes never hinted at any change in DST adjustment behavior, I've been afraid to upgrade, convinced that I've experienced a genuine random miracle, and even avoided connecting my PC to the CM15A during the entire duration of standard time, just to confirm that I may indeed have gone insane (and to my utter amazement my CM15A ran perfectly with no intervention required between November and March). Can't tell you how happy I am to see confirmation that this is not a hallucination but a genuine bug fix. MANY THANKS AHP PROGRAMMERS!!!
-
* The CM15A does not correctly adjust for Daylight Savings Time when not connected to the PC.
(added 3/6/2011 by Noam)
No repro in testing. We ran a large number of tests the week before the DST change using build 306, and all of the hardware functioned correctly both connected and not connected to the PC. I reran several of them today and still no problems. Did any of you have problems with the recent DST change? This bug should have been fixed sometime ago. If you did have a problem please let me know what build you were using at the time and exactly what behavior you saw.
Long time lurker, first time poster. I can confirm that auto DST adjustment (running CM15A standalone) WORKED CORRECTLY at least as far back as version 3.285 (which I'm still running)... worked last November in the standard time reversion, and worked again correctly this March when we went back to DST. I've scoured the forums looking for anyone else reporting a confirmation of this wonderful fix, to no avail... Since the release notes never hinted at any change in DST adjustment behavior, I've been afraid to upgrade, convinced that I've experienced a genuine random miracle, and even avoided connecting my PC to the CM15A during the entire duration of standard time, just to confirm that I may indeed have gone insane (and to my utter amazement my CM15A ran perfectly with no intervention required between November and March). Can't tell you how happy I am to see confirmation that this is not a hallucination but a genuine bug fix. MANY THANKS AHP PROGRAMMERS!!!
Stan -
Thanks for confirming that this was fixed. I think a lot of us keep out CM15A's connected 24/7, which would have masked the problem, anyway.
Erik -
I updated the Bug List that this was fixed. Do you have any information as to what version fixed it?
-
If the update feature bug was fixed we wouldn't have so many reporting old issues that have been fixed.
The Update feature should be at the top of the list of to does!
It would sure save alot of time for Programmers. No more looking to reproduce an error that is non existant!
-
I updated the Bug List at the top of this thread, adding in the feedback we received from the development team.
If anyone is able to test some of the items that were supposed to have been fixed in 3.310, as well as the ones that the developers could not reproduce, it would help.
Please report your findings here.
Thanks
--Noam
-
Erik -
I updated the Bug List that this was fixed. Do you have any information as to what version fixed it?
According the code repository it was updated in Oct of 2008. I don't know what release build that change made it into, but presumably something around that time frame, maybe 3.236? If not then, then it looks like one of my predecessors fixed it but never released it. In that case the first release I worked on would have inherited the fix which was 3.264.
-
Erik -
I updated the Bug List that this was fixed. Do you have any information as to what version fixed it?
According the code repository it was updated in Oct of 2008. I don't know what release build that change made it into, but presumably something around that time frame, maybe 3.236? If not then, then it looks like one of my predecessors fixed it but never released it. In that case the first release I worked on would have inherited the fix which was 3.264.
According to my notes, 3.236 was released on 9/5/2008, so it wouldn't have made it into that version.
The next version released, 3.264, was released on 3/23/2010. Since there was no mention of the DST fix in that release, or in any release after it, it was assumed that it hadn't been fixed.
There have now been two transitions to test on (11/7/2010 and 3/13/2011). Other than one post from a user whose PC died right before the November change (and was probably on an older version of AHP), I didn't see any mention of problems with those two DST transitions. I already moved it to the "Fixed" list, but I'll add that it was fixed in 3.264.
-
Sorry, I always associate OCTober with the number 8, and I forget its actually the 10th month B:(
Using a correct numbering of months though that makes sense :)
-
Sorry, I always associate OCTober with the number 8, and I forget its actually the 10th month B:(
Using a correct numbering of months though that makes sense :)
Well, according to an article I found here:
http://wiki.answers.com/Q/Why_is_October_not_the_eighth_month
it USED to be the eighth month.
The Romans (it's always THEIR fault, right?) added the months of July and August, which shifted the rest of the months down.
SEPTember, OCTober, NOVember, and DECember used to be the 7th, 8th, 9th, and 10th months of the year. Of course, the calendar was inaccurate, so they needed to add two months to fix it. I don't know why they didn't add them AFTER December, though. B:(
-
* The "Check for Update" function cannot find new versions of AHP.
(broken since v3.228 9/5/2008, confirmed still broken as of 3.306)
(ErikP 3/25/2011: Confirmed. This is at the top of my regular priority work list. Its been delayed a bit due to a lot of high priority workload recently, but should be ready soon. The bug is entirely server side, so once it is fixed it will not require an AHP update to take effect.)
I know this issue is near and dear to some of you, so I just wanted to drop a quick Friday update. I will not be able to release this before the weekend, sorry everyone. I have an internal server rigged for testing, which is generating the correct responses to AHP to make this functionality work. Unfortunately, the dev build of AHP is crashing in the process of shutting down before it starts the installer, so this is going to take some more time than initially estimated.
-
ErikP,
Not sure if you are the Ericb@ I've had email correspondence with at x10, but I just wanted to check.
"* Macros with time-based conditions do not work for some users. Other conditions work fine for those users.
(added 3/6/2011 by Noam)
(ErikP 3/25/2011: No repro in testing. I have been getting intermittent reports of this from a few sources, but have never been able to reproduce it in testing. Even more odd the bug seems to disappear without any fixes from most reports i have gotten. If you don't mind sending me your ahx files containing a macro showing this bug i would be happy to try and reproduce this again using those files.)
"
This is my bug, and I had sent in my ahx files over 2 months ago for testing. I have yet to receive any feedback since then. Its so frustrating not getting anywhere with this situation, as im sure so many have already given up.
-
ErikP,
Not sure if you are the Ericb@ I've had email correspondence with at x10, but I just wanted to check.
Nope, they are two different people (I've dealt with both of them).
-
I added another bug to the list:
* AHSDK sometimes crashes, which prevents any further SDK commands until the "debug" notice is closed.
I think I first noticed this with v3.305 (when the newer SDK was released), but it may have started a bit earlier.
It does not happen every time, so I can't repeat it reliably.
I didn't add it to the list until another user reported the same issue. Now I know it isn't just me. ;)
-
I haven't noticed this myself but other users of my software have reported it! ::) :'
-
I added another bug:
* The Intro Wizard crashes, when trying to go through the Timers or Macro sections.
(added 4/11/2011 by Noam)
This one has been around for a very long time (since the initial release, perhaps?), but never was added to the list.
-
I'm trying to keep the Bug List current, so one again, I'm asking if everyone can test the bugs that ErikP either reported were fixed in 3.310, or couldn't reproduce.
I'd like to move as many as possible to the "Fixed" list, but I can't if nobody can confirm that they actually are fixed.
Here are the ones I'm interested in feedback on:
* Macros with time-based conditions do not work for some users. Other conditions work fine for those users.
(added 3/6/2011 by Noam)
(ErikP 3/25/2011: No repro in testing. I have been getting intermittent reports of this from a few sources, but have never been able to reproduce it in testing. Even more odd the bug seems to disappear without any fixes from most reports i have gotten. If you don't mind sending me your ahx files containing a macro showing this bug i would be happy to try and reproduce this again using those files.)
* If AHP is running and and locks up, a task manager "kill" results in AHP failing to load next time. It also stops SDK-built programs from working. An "error getting X10 net interface" appears. Some have noticed this with improper PC shut downs, as well.
(ErikP 3/25/2011: Confirmed, but very rare. I have only seen it once, and have not been able to repro since in order to do any more testing. If you have this bug now or can reproduce it, please send me a copy of your x10active.xml from the broken state. By default this is located in C:\Users\All Users\X10 Settings.)
* The issue with installing plug-ins after AHP still causes issues.
(added 1/6/2011)
(ErikP 3/25/2011: No Repro in testing. Ideally whatever lingering bugs there may have been around plug-in installation should have been fixed with the new installer framework this release, or at the very least transformed into newer and shinier bugs.)
* Installing iwatchout (video plug-in) causes AHP to fail.
(ErikP 3/25/2011: No Repro in testing.)
* There are no Dim, bright or extended X10 messages being sent with the CM19A TM751 combination
(added 2/7/2011)
(ErikP 3/25/2011: Fixed in 310. Please let me know if you are seeing anything different, this is kind of important since its really the core functionality of the application.)
Please reply here if you have any more information (good or bad) about any of these.
Thanks.
--Noam
-
I've made another change to the format of the Bug List.
I split out the bugs that the developers have reported were fixed, but I haven't gotten confirmation on from users.
They are now in the "Reported Fixed" section of the list.
-
In a new setup no other modules timers or macros.
Soft Start LM465 defined as such in AHP 3.310.
CM19A with TM751. Bright Dim and Extended commands.
Bright and Dim commands sent and it looks like level slider sends an On then a dim back down. I never saw any extended data on my 1132CU monitoring controller.
CM15A sends On Offs and Extended commands.
On thing I did notice with both interfaces. If you set the slider to a partial dim level. Turn the module off. Then turn it ON. The slider momentarily stops at the last place it was. Then jumps to 100% but the module goes to the last dim level set. Not full On.
-
On thing I did notice with both interfaces. If you set the slider to a partial dim level. Turn the module off. Then turn it ON. The slider momentarily stops at the last place it was. Then jumps to 100% but the module goes to the last dim level set. Not full On.
This is a bug. It is already on the list.
-
AHP 3.311 was released this morning.
This release is supposed to increase stability of AHP.
I was told there were no fixes to any of the bugs currently on the list, but it is possible that other issues may have crept in.
Please reply here if you find any new issues, or if you see any older issues that have been fixed.
I'm especially interested in the users who had problems installing updates before.
those issues should have been fixed with 3.310, but nobody confirmed it one way or another.
-
After updating to 3.310 I developed an issue with a dimming macro that would work
correctly every time from PC and if triggered by remote, but not from phantom module
with a timer each evening.
Think I got it handled after reading till I was cross eyed.
I found the 3.311 update. Now every time I enter the software the download to interface arrows
show in the bottom right corner even though I have NOT made any changes to be loaded.
I reverted back to 3.310 and the condition still occurs.
-
After updating to 3.310 I developed an issue with a dimming macro that would work
correctly every time from PC and if triggered by remote, but not from phantom module
with a timer each evening.
Think I got it handled after reading till I was cross eyed.
I found the 3.311 update. Now every time I enter the software the download to interface arrows
show in the bottom right corner even though I have NOT made any changes to be loaded.
I reverted back to 3.310 and the condition still occurs.
Have you actually tried downloading, to see if that makes the arrows go away?
It is possible that the "Have I downloaded?" flag in the software was reset by the update.
If that doesn't do it, I suggest clearing the CM15A, and trying to download again.
-
Since nobody reported errors with the installation itself since the introduction of the new installer in v3.310, I moved those two bugs to the "confirmed fixed" list.
I'm still waiting for someone with a CM19A/TM751 combination to confirm the Extended Codes bug is fixed.
-
Thank you Noam for ALL your efforts.
Have you actually tried downloading, to see if that makes the arrows go away?
Yes.
Last night I did the 3.311 update and the arrows where showing.
I would just download anyway (no changes) exit software, re-enter software.
They would appear after plug-in splash screen.
Cleared interface, exit software, re-enter software, they would show of course so I downloaded.
Before I retired for the evening I uninstalled AHP , re-installed 3.310. This morning there they where.
SO...
Saved AHX, again uninstalled and re-installed 3.310, put AHX back , loaded interface, restart machine, and she's a work'n. No arrows.
Weird. ?
-
Saved AHX, again uninstalled and re-installed 3.310, put AHX back , loaded interface, restart machine, and she's a work'n. No arrows.
Weird. ?
I can't explain that one (I'm not a developer, just an end-user with a lot of free time)
If you have the time, you might try upgrading to 3.311 again, and see what happens.
-
I just installed 3.311. I see no arrows. and that is without restarting AHP. It works fine with BVC too. Will know about timers and macros tomorrow. So far so good. Thanks Noam for all the hard work you put in.
IPS
-
I added this as a bug:
* AHP prompts to download to the CM15A when opening the program, even if no changes were made to the program since the last download.
(v3.311 added 4/18/2011 by Noam)
I was able to reproduce it on my WinXP system, but not on my Win7 system.
EDIT: I WAS able to reproduce it on windows 7 after switching to a different AHX file.
However, if I ignored the prompt to download on the next session, and exit AHP without downloading, I don't get the prompt on future sessions.
It definitely is a bug in the code somewhere.
-
Version 3.313 was released on 4/25/2011.
I updated the bug list to reflect everything I tested was still present (nothing was reported as fixed yet).
Please test whatever you can, and report any additional bugs, or any bugs that have not yet been verified as either present or fixed in 3.313.
-
I had thought I was a lucky one with not seeing the download to interface arrows on starting AHP.
Well that didn't last! ::) :'
Opened AHP this morrning to test the auto update( Still broken) and there they were.
Updated to new version and they are still there! B:(
-
I had thought I was a lucky one with not seeing the download to interface arrows on starting AHP.
Well that didn't last! ::) :'
Opened AHP this morrning to test the auto update( Still broken) and there they were.
Updated to new version and they are still there! B:(
Yeah, I updated that on the Bug List a few minutes ago.
It doesn't look like 3.312/3.313 fixed any of the current bugs.
-
Updated to 3.313 and the X10nets.exe (the X10 service) uses a lot more memory compared with the previous one. If I don't stop and restart the service in couple days, it reaches up to 80MB when I open Task Manager. I'm running it on Window Home Server. Why so much? Does the developer know memory management in writing this software? Or does this software has a memory leak somewhere in the code? B:(
-
Updated to 3.313 and the X10nets.exe (the X10 service) uses a lot more memory compared with the previous one. If I don't stop and restart the service in couple days, it reaches up to 80MB when I open Task Manager. I'm running it on Window Home Server. Why so much? Does the developer know memory management in writing this software? Or does this software has a memory leak somewhere in the code? B:(
I haven't noticed this myself but will pay a little more attention to it.
Are you using any tird party SDK built programs?
Is AHP running 24/7
what plug-ins do you have installed?
Supply as much info as you can as it may not be x10nets to blame but something utilizing it!
-
I haven't noticed this either, but I'll try to keep an eye on it, too.
-
I don't have any 3rd party plugins, I only have OnAlert, SmartMacro, and MyHouse Online plugins. And I'm not running AHP all the time, I download all the timers and let it runs. The CM15A is plugged to a USB port on my HP MediaSmart Server (WHS).
-
As far as I understand it, the OnAlert and MyHouse plugins require AHP to be open all the time to utilize their functionality.
Are you sure that AHP is closed, and not minimized to the System Tray?
-
Yes, because I closed it by clicking on the x button. I know that MyHouse online requires AHP running all the time but I only runs it when I needed it. The X10nets is a server process running independent of AHP so I don't see any links regarding AHP and the X10nets memory consumption.
-
In that case, I'm not sure why it would start taking up large amounts of memory.
Did this only start when you upgraded to 3.313?
What version were you using prior to the upgrade?
What was your memory usage like using the prior version?
If the previous version didn't have the memory issues, you may want to try downgrading to an earlier version, and then re-installing the upgrade. It is also possible that reinstalling the current 3.313 might also make a difference.
Another possibility is that your AHX file might be corrupted. Even with AHP closed, the x10nets service makes use of your AHX file.
-
I've been running some limited tests on this as being at the cottage I'm limited to my notebook.
the x10nets memory does increase each time AHP or a SDK created program is opened.
Closing a SDK created program does reduce the memory X10nets is using however it doesn't return to its original memory usage.
Closing AHP causes the X10nets memory usage to jump then return to the usage when AHP was open then moments later increase again without anything using it!
Opening AHP again causes the mem usage of X10nets to spike again going higher each time one open and closes AHP.
Since this occurs each time a user open/closes AHP then the memory usage would climb out of control.
Now since I have this on a note book it isn't possible to see if the X10 nets mem usage returns to original over a long period of inactivity but with the interface connected I would assume it would increase for each command received.
I'll perform a more indepth test once I return home.
Definitely something that needs to be looked at here.
A point to note is I'm using same plugins as ssnui plus iwatchout (video plug-in) No interface connected
-
I sent an e-mail to the developers, asking them to take a look at this thread, and try to replicate the issue.
I'm waiting to hear back from them before I add it to the "Bug List," since I haven't seen any other reports of the issue.
I'll let you know as soon as I hear something.
-
I sent an e-mail to the developers, asking them to take a look at this thread, and try to replicate the issue.
I'm waiting to hear back from them before I add it to the "Bug List," since I haven't seen any other reports of the issue.
I'll let you know as soon as I hear something.
I got a reply from one of the developers. He is going to look into this. He has a few ideas of where to look first, but he'll update me (us?) when he has something more concrete.
I'll pass along any more info I get.
-
Version 3.314 was just released on Tuesday night.
It wasn't a "bug fix" release, but I tested all of the existing bugs I could anyway. As expected, none of the ones I tested are fixed with this update.
There are a few I was unable to test, so if anyone can test the ones I didn't update, please do so and let me know.
I'm still waiting for someone to confirm is Extended Commands work with the CM19A/TM751 combination - it should have been fixed in 3.310, but none of the users have confirmed this for me. I'd like to take it off the "Pending Confirmation" list.
-
* AHP prompts to download to the CM15A when opening the program, even if no changes were made to the program since the last download. this looks like it is fixed but I'll give it a few days as it took a few days after last update for this to pop up on my machine.
Doing some more test with the memory leak on WIN 7 64 bit and I can recreate it here. Sending plc or recieving RF doesn't increase the memory used so it apears it is the opening and closing of AHP or SDK programs.
Funny the memory usage starts off much lower on Win 7 then XP ;)
>!
-
* AHP prompts to download to the CM15A when opening the program, even if no changes were made to the program since the last download. this looks like it is fixed but I'll give it a few days as it took a few days after last update for this to pop up on my machine.
I stopped this issue on my system, but in a strange (still buggy) way. When prompted if I still want to exit without downloading, I clicked "No." However, AHP exited anyway! When I opened it back up, I no longer had the prompt. I can re-create this every time, it seems, just my making a change (to trigger the prompt again). Still is a bug in 3.314. I just updated the list, since I was able to confirm it.
Doing some more test with the memory leak on WIN 7 64 bit and I can recreate it here. Sending plc or recieving RF doesn't increase the memory used so it apears it is the opening and closing of AHP or SDK programs.
Funny the memory usage starts off much lower on Win 7 then XP ;)
>!
I can't reproduce the issue in testing, but I've been rebooting my system a lot more lately, for other reasons.
Were you able to get the memory use up as high as the other user reported? Does using SDK programs, or using the AHCMD.exe also cause the memory issue?
-
I haven't tested the AHCMD but Programs using the SDK do cause the X10Nets memory usage to go up as well.
they don't seem to cause it to go up when closing only opening.
I haven't got the memory usage up as reported I would suspect the PC to be left running 24/7 (no reboots) and one to open and close AHP or a SDK created program alot to get that high.
One thing I Just noticed if I open a SDK Built program and open and close AHP the memory usage doesn't increase.
If only one program is using the X10nets then opening and closing effects the mem usage ???
-
I updated the Bug List for version 3.315, which was released on 6/9/2011.
I tested everything I could, and updated the list accordingly.
There were only two bugs that were reported fixed with this release:
* Macros with time-based conditions do not work for some users. Other conditions work fine for those users.
* The Intro Wizard crashes, when trying to go through the Timers or Macro sections.
There is also one that was reported fixed a while back, but none of the users ever confirmed it here on the forums that it really was fixed:
* There are no Dim, bright or extended X10 messages being sent with the CM19A TM751 combination
Please test these out if you can, and report back here.
-
I will see if I can figure out how to determine if a CM19A with TM751 uses Bright , Dim and Extended Messages.
Will also try the Intro Wizard. With the CM15A it worked OK. Will post back with CM19A/TM751 results.
-
OK attached are two text files.
B1 is a Soft Start LM465 in AHP.
B2 is an old LM465 in AHP.
Sequence was B1 On, B2 On, B1 Off, B2 Off, B1 50% and B2 50%.
Monitored by a Smarthome 1132CU and Essential Software.
I believe the CM19A/TM751 combo maybe limited by the TM751 maybe not processing extended commands but that is just my personal thoughts.
Light levels for the B1 where not extended messages with the CM19A/TM751. Where full On then Dim Down.
iexplore.exe is sometimes left running after closing AHP. I think it maybe after running the Activity Monitor, but I have not done extensive tests for a sequence that leaves it running. In my case keeping 72,908K of memory in use.
-
OK attached are two text files.
B1 is a Soft Start LM465 in AHP.
B2 is an old LM465 in AHP.
Sequence was B1 On, B2 On, B1 Off, B2 Off, B1 50% and B2 50%.
Monitored by a Smarthome 1132CU and Essential Software.
I believe the CM19A/TM751 combo maybe limited by the TM751 maybe not processing extended commands but that is just my personal thoughts.
Light levels for the B1 where not extended messages with the CM19A/TM751. Where full On then Dim Down.
iexplore.exe is sometimes left running after closing AHP. I think it maybe after running the Activity Monitor, but I have not done extensive tests for a sequence that leaves it running. In my case keeping 72,908K of memory in use.
Brian - thanks for testing. I assume this was all tested with 3.315, right?
It looks to me like the CM19A/TM751 is still not processing extended commands. That was supposed to have been fixed. I'll ask the developer to look at your post, and contact you if he needs to.
The iexplore thing is on the Bug List, and hasn't been fixed as of yet.
-
Yes 3.315.
Intro Wizard with a CM19A/TM751 minor quirk. Timer test should trigger the A1 light in 60 seconds. Was 30 seconds.
CM11A: Clear memory now OK.
Set Battery time {had batteries in CM11A}. Minor quirk or more resolution. 546:07:00. AH would set it to 500:00:00
Intro Wizard didn't work correctly but maybe trying things the CM11A can't do.
Timer Test failed. Sent extended data but the A1 SS LM465 didn't respond.
Macro Test also failed. Again extended data sent but no response from the LM465 on A1.
Didn't try RF tests as the CM11A doesn't do RF.
My tests with B1 and B2 for the CM11A Attached.
-
Well, I asked the developer to look at your post, and to get in touch with you if he needs to.
I'm reluctant to add these as true bugs, since they seem pretty minor (compared to some of the bigger things on the list), and probably won't affect as many people at this point.
I'd like to wait and see what he says first, though.
-
Sounds like a good way to go.
Not sure why X10 even added the CM11A to AHP.
Maybe there is another boat load of CM11As en route to the US.
-
Sounds like a good way to go.
Not sure why X10 even added the CM11A to AHP.
Maybe there is another boat load of CM11As en route to the US.
Seems strange to me. Serial ports are vanishing, several laptops don't even have them.
-
Has anyone tried using the CM11A with a USB-to-Serial adapter?
If there is a large inventory of leftover CM11A units, they may have updated AHP to try and sell them off.
I know there are a lot of third-party software packages, for a variety of operating systems, that use the serial port CM11A still.
-
I believe the CM11A used one of the handshakes. Ring Indicate.
That maybe why some USB to serial adapters work and others do not.
-
I added the new "Video Flicker" bug to the list.
At least two users reported it, and the steps provided to correct it did not work.
-
I added the new "Video Flicker" bug to the list.
At least two users reported it, and the steps provided to correct it did not work.
Good News: The developers found the cause, and hope to have a fix out this week for this issue (yay!)
-
Don't know if this is the right place to post this, and I can't find other posts regarding this, but I may have found another bug.
The scenario is:
I am using flag 9 as a condition in another timed macro to run IF flag 9 is NOT set, so...
1) created a dummy appliance module N9
2) created a simple macro, triggered by N9 OFF to clear flag 9
3) created another simple macro, triggered by N9 ON to set flag 9
4) module N9 gets turned off at dawn (using the timer function), that is supposed to clear flag 9. This resets flag 9 to it's "normal" condition for the next day's "test" (This is the only way I found to change the status of a flag with a time).
While I was testing the flag 9 setting/clearing, I was using a palmpad (too lazy to get a wired command console).
THIS IS WHERE THE "BUG" IS.
While watching the two macro's indicators in AHP, when I pressed the N9 "on" button on the palmpad, BOTH MACRO "INDICATORS" IN AHP LIT UP TOGETHER (flashed), and when I pressed the N9 "off" button on the palmpad, NEITHER macro "indicator" lit up.... HHMMMMMM...........
HOWEVER..........
When I did the same n9 on/off on a wired command console, the indicators acted correctly!!!
I ran a status report in all of the situations, and the flag 9 is setting and clearing like it should, so AHP is processing the macros correctly, BUT the DISPLAY for the macros are not.
The activity log shows the different commands processed (and they are different because
the palmpad sends...........
n9 on [no label on this step though]
n9 off [no label on this step though]
and the console sends
n9 (set flag 9 test)
n9 on (set flag 9 test)
and
n9 (set flag 9 test)
n9 off [no label on this step though]
Is this behavior normal or is this a known problem?
The macros seem to function correctly, just the way the activity log is reporting is different, probably due to the way the palmpad sends the combined command and the console sends the partial command separately.
I have noticed this with the wireless motion detectors also because the send the combined command.
Anyone else noticed this?
Thanks!
-
Don't know if this is the right place to post this, and I can't find other posts regarding this, but I may have found another bug.
The scenario is:
I am using flag 9 as a condition in another timed macro to run IF flag 9 is NOT set, so...
1) created a dummy appliance module N9
2) created a simple macro, triggered by N9 OFF to clear flag 9
3) created another simple macro, triggered by N9 ON to set flag 9
4) module N9 gets turned off at dawn (using the timer function), that is supposed to clear flag 9. This resets flag 9 to it's "normal" condition for the next day's "test" (This is the only way I found to change the status of a flag with a time).
While I was testing the flag 9 setting/clearing, I was using a palmpad (too lazy to get a wired command console).
THIS IS WHERE THE "BUG" IS.
While watching the two macro's indicators in AHP, when I pressed the N9 "on" button on the palmpad, BOTH MACRO "INDICATORS" IN AHP LIT UP TOGETHER (flashed), and when I pressed the N9 "off" button on the palmpad, NEITHER macro "indicator" lit up.... HHMMMMMM...........
HOWEVER..........
When I did the same n9 on/off on a wired command console, the indicators acted correctly!!!
I ran a status report in all of the situations, and the flag 9 is setting and clearing like it should, so AHP is processing the macros correctly, BUT the DISPLAY for the macros are not.
The activity log shows the different commands processed (and they are different because
the palmpad sends...........
n9 on [no label on this step though]
n9 off [no label on this step though]
and the console sends
n9 (set flag 9 test)
n9 on (set flag 9 test)
and
n9 (set flag 9 test)
n9 off [no label on this step though]
Is this behavior normal or is this a known problem?
The macros seem to function correctly, just the way the activity log is reporting is different, probably due to the way the palmpad sends the combined command and the console sends the partial command separately.
I have noticed this with the wireless motion detectors also because the send the combined command.
Anyone else noticed this?
Thanks!
1. You shouldn't need the dummy module to trigger the macro. You can set timers on a macro directly.
2. I see the same behavior on my system (macros triggered by an "off" blink when an "on" is received for that command, and not when an "off" is received.
I'm adding it to the Bug List, and I'll mention it to the developers, but it sounds like it is only cosmetic. Those bugs are given the lowest priority, as the developers concentrate on the more urgent bugs.
-
DOH!!!
Thanks Noam! I had a senior moment!
The think that threw me was that it needed a trigger (the macro) so I thought I needed a module for the trigger.
Other than that, I am glad (?) to see that I am not the only one that has seen the behavior of the on verses off.
As long as it is only cosmetic, I can live with it. It just throws me when I am trying to troubleshoot and verify!
As long as the actual command is sent correctly!
Thanks!
-
DOH!!!
Thanks Noam! I had a senior moment!
The think that threw me was that it needed a trigger (the macro) so I thought I needed a module for the trigger.
Other than that, I am glad (?) to see that I am not the only one that has seen the behavior of the on verses off.
As long as it is only cosmetic, I can live with it. It just throws me when I am trying to troubleshoot and verify!
As long as the actual command is sent correctly!
Thanks!
As far as I know, you still need to use a dummy module (of course, a real one would work, too!) to call one macro from within another macro. Unless that was fixed and I didn't notice it.
-
As far as I know, you still need to use a dummy module (of course, a real one would work, too!) to call one macro from within another macro. Unless that was fixed and I didn't notice it.
Yes I realize that, but that is different than what I am trying to do. I just wanted the macro to run at a certain time.
IF I DID want to manually run the macro also, I would need a dummy module just to trigger the macro... Hmmmm maybe I WILL do that just in case!
Thanks!
Noam edited to fix the tags around the quote
-
No -
You ONLY need the dummy if you plan to call one macro from another.
Otherwise, it isn't needed.
-
AHP version 3.316 was just released. It is supposed to fix the "video flicker" bug.
Can someone please test this and confirm?
Also, if anyone can confirm the rest of the bugs in the "Reported Fixed" list, please report back here.
-
I'm still using 3.313 running on my WHS. After a week vacation, I returned home and surprised to see memory usage over 101K. I restarted the X10nets service, it's kind of hung and I have to use Task manager to kill it to restart. Three days later I check again and memory usage is over 107K. I attached the screencapture here.
-
I'm still using 3.313 running on my WHS. After a week vacation, I returned home and surprised to see memory usage over 101K. I restarted the X10nets service, it's kind of hung and I have to use Task manager to kill it to restart. Three days later I check again and memory usage is over 107K. I attached the screencapture here.
Please only report bugs for current versions.
The memory leak was reported before and was looked into.
Current version is 3.316
>!
-
I'm still using 3.313 running on my WHS. After a week vacation, I returned home and surprised to see memory usage over 101K. I restarted the X10nets service, it's kind of hung and I have to use Task manager to kill it to restart. Three days later I check again and memory usage is over 107K. I attached the screencapture here.
Please only report bugs for current versions.
The memory leak was reported before and was looked into.
Current version is 3.316
>!
Thanks, I just download 3.316 but I don't see any notes that this has been fixed so I assume it's still there, but I'll report any new status regarding this.
-
I have been trying to find an answer to my dilemma, and haven't been able to (IF I have been asking the correct question???).
I know I have seen this before, but cannot find it now.
My problem is:
I have a macro that runs (starts) at 3:05 a.m. to turn off lights.
The macro (I have shortened it alot, but left in pieces of it):
1) turn off a light
2) close curtains (appliance module turn ON)
3) turn off all lights in a room
4) delay 10 minutes
5) dim another light
6) delay 5 minutes
7) dim another light
8) delay 5 minutes
..... you get the idea
The total time for the macro (events + delays) is 50 minutes
HOWEVER...
the WHOLE macro runs from start to finish, and REPEATS AFTER EACH DELAY!!!
meaning that ALL the modules are "commanded" at 3:05 a.m., 3:10, 3:15, 3:20, etc. (these times are my delay times for the "groups" of modules that I am controlling, NOT at the SAME time though!).
IF I start AHP and then close it, the macros seem to run correctly. IF I reboot my computer and do NOT start and close AHP, I get the same incorrect macro run.
I have to start and close AHP to "reset" the macro delays in order for them to run correctly.
I am using 3.316. This also happened with 3.315, and I started with 3.310 but don't know if that had problems as I have been adding to my macros over time, and haven't paid attention to problems until recently.
Is this a problem that has been around for a while?
Is there something that I am missing when I write my macros?
BTW... with 3.315 and 3.316, I get the famous M MTCDDVD occurring randomly, BUT new neighbors have just moved in two doors down and I noticed a Protection 1 placard in their yard, SO I need to find out if they have a wireless security system installed... bet they DO! (I don't have any wireless security sensors, my system is wired... GASP!!!!... how "yesterday"!)
-
This is a known bug. commands run twice after X10nets is started and before AHP is opened. It is already on the bug list.
No idea when the developers will fix it, though.
The simple answer is to just open AHP and close it after you log back into the PC after a reboot.
-
This is a known bug. commands run twice after X10nets is started and before AHP is opened. It is already on the bug list.
No idea when the developers will fix it, though.
The simple answer is to just open AHP and close it after you log back into the PC after a reboot.
Hello Noam and thanks for the reply!
I kinda thought this was a known bug and I know I read it SOMEWHERE, just couldn't find it so I thought I would ask AGAIN.
And yes, for now I will just have to open AHP after a reboot to keep the macro from running multiple times and insert the delays when they are supposed to happen, rather than run the WHOLE macro at EACH delay.
Hope that it does get fixed sometime though as my lights in the macro are set to dim a little at each delay and what happens is the lights all turn off, then when the macro runs again (after the delay timeout) the lights come on again! REALLY annoys my birds... rofl
Thanks for the reply! >!
-
X10 released AHP version 3.318.
The only item they list is support for the VA13A (which must be a new video adapter).
They don't list any bug fixes in the version history.
If anyone feels compelled to test any of the outstanding bugs (or the ones that were reported fixed, but I couldn't confirm myself), please let me know here, and I'll update the list.
-
It looks like the "M MTCDDVD" bug has been fixed! I got a report from one user, and confirmation from one of the developers that a fix was put into the code.
I've moved it to the "Reported fixed" list.
If anyone else can test it, please report back here, and I'll move it to the "confirmed fixed" list.
-
Confirmed!!!! The M MTCDDVD's are gone!!!! :)% :)%
Just check and I see in the log prior to the update they were there and after the update they are gone. I know that it was more of an annoyance but I am glad that the "M MTCDDVD" is fixed.
Cheers,
Nate
-
Confirmed!!!! The M MTCDDVD's are gone!!!! :)% :)%
Just check and I see in the log prior to the update they were there and after the update they are gone. I know that it was more of an annoyance but I am glad that the "M MTCDDVD" is fixed.
Cheers,
Nate
Wonderful! I've moved it to the "confirmed" list.
-
I added a new bug to the list:
* Macros triggered by a security sensor are run twice, while macros triggered by a normal HC/UC are run only once.
I would appreciate it if someone else can test and verify this. If it turns out not to be a repeatable bug (other than the one user who reported it), then I'll take it off the list, and ask the developers to work with the user directly to resolve it.
-
New bug added:
* Commands are no longer "grouped" in macros (ex: "E1, E2, E On" is now "E1, E On, E2, E On").
(v3.318, added 12/27/2011 by Noam)
Reported by user "s0urc3f0ur" in this thread:
http://forums.x10.com/index.php?topic=25852.0
-
New macro bug:
I have a macro condition - 'Not Disarmed' for a Security Armed State tied to IR sensors. It runs when the alarm system is disarmed and an IR sensor is tripped.. I had to change it to 'Exactly Armed Home' which means I have to add another macro for 'Exactly Armed Away'. It was working on the AHP previous version.
-
New macro bug:
I have a macro condition - 'Not Disarmed' for a Security Armed State tied to IR sensors. It runs when the alarm system is disarmed and an IR sensor is tripped.. I had to change it to 'Exactly Armed Home' which means I have to add another macro for 'Exactly Armed Away'. It was working on the AHP previous version.
What version were you using before?
I don't have the security plugins, so I can't test this myself. Is there a generic "armed" condition?
Are you using other conditions, or can you set it to "[Exactly Armed Home] or [Exactly Armed Away]" ?
Can anyone else out there with the security plugins duplicate this?
I try to get as much information as I can about it before adding it to the list and e-mailing the developers.
-
Hi Noam,
I'm not sure of the version number when it worked. Whichever version was the latest in 12/2010 (I just use the macros around Christmas).
The [Not Disarmed] condition is the generic armed condition while the other two covers home or away. The condition is coupled to a IR trigger in one macro and the other macro is coupled to a door sensor trigger. I couldn't figure out (or even possible) to do an OR condition for both sensors in one macro.
-
Hi Noam,
I'm not sure of the version number when it worked. Whichever version was the latest in 12/2010 (I just use the macros around Christmas).
3.296 was released 11/3/2010, and 3.301 was released on 12/20/2010.
The [Not Disarmed] condition is the generic armed condition while the other two covers home or away. The condition is coupled to a IR trigger in one macro and the other macro is coupled to a door sensor trigger. I couldn't figure out (or even possible) to do an OR condition for both sensors in one macro.
I'm not sure what you mean by "an OR condition for both sensors in one macro"
I thought your condition was the "not Disarmed".
-
What I was looking to do was:
Condition [Security Is Not Disarmed]
Trigger [Basement Door Sensor Triggered] OR [Basement Motion Sensor Motion Detected]
It appears that there is only one trigger allowed.
It looks like you can have multiple conditions, but the IR modules are unavailable for conditions.
-
What I was looking to do was:
Condition [Security Is Not Disarmed]
Trigger [Basement Door Sensor Triggered] OR [Basement Motion Sensor Motion Detected]
It appears that there is only one trigger allowed.
It looks like you can have multiple conditions, but the IR modules are unavailable for conditions.
Yes, a macro can only have one trigger (that's what kicks off the macro). You would need to create a second macro that would be triggered by the other sensor.
You can have multiple conditions (up to three, but some condition types use of two of the condition "slots") in a single macro.
If you create the macro with the one condition (not disarmed), and trigger it with the one motion sensor, does it work properly?
You MUST test it using the motion sensor (or some other device that can trigger it). clicking on the macro within AHP will ignore the conditions, and ALWAYS run the commands.
-
I did create a second macro triggered by the other sensor. I was just musing about wanting to have a single macro for both.
But - in screwing around with the macros, the [Not Disarmed] wasn't the problem. I somehow started video recoding manually apparently and thought the motion detector had triggered the recording.
I now have another problem (which may be a bug or I'm simply misunderstanding macros).
While the macros work fine when I manually trigger them from AHP, they do not work after arming my system and tripping a trigger. I can watch the activity log and see the log entry for the trigger, and the [All Lights On] [All Lights Off] log entries repeating. However, the macros do not fire.
Shouldn't the CM15A communicate with my PC and AHP to fire off the macro? Or is there something else I should be doing?
Or the 'Run from PC' not capable of doing this?
-
I did create a second macro triggered by the other sensor. I was just musing about wanting to have a single macro for both.
So you'd like to be able to assign multiple triggers to the same macro. Yeah, that might be a nice feature. (you can do it by assigning a "simple" macro to each motion sensor, that just calls a third one - using a "dummy" appliance module).
But - in screwing around with the macros, the [Not Disarmed] wasn't the problem. I somehow started video recoding manually apparently and thought the motion detector had triggered the recording.
Okay, so it isn't a bug I need to add. Thanks for confirming that.
I now have another problem (which may be a bug or I'm simply misunderstanding macros).
While the macros work fine when I manually trigger them from AHP, they do not work after arming my system and tripping a trigger. I can watch the activity log and see the log entry for the trigger, and the [All Lights On] [All Lights Off] log entries repeating. However, the macros do not fire.
That's probably not a bug. Macros ignore conditions if you trigger them from within AHP (by clicking on them). More than likely, your conditions aren't being evaluated as "true." Check them carefully, you might have an error in the conditions somewhere.
Shouldn't the CM15A communicate with my PC and AHP to fire off the macro? Or is there something else I should be doing?
Or the 'Run from PC' not capable of doing this?
That's EXACTLY what it *should* be doing, as long as the PC is on, and the cable is connected, it should run those macros when triggered by the CM15A.
-
I think I'm out of the woods, Noam. When I changed out the batteries in my two alarm remotes, they still worked fine with the security box. I had to reinstall them both in AHP though. Once done, I believe it works as it should now.
-
I think I'm out of the woods, Noam. When I changed out the batteries in my two alarm remotes, they still worked fine with the security box. I had to reinstall them both in AHP though. Once done, I believe it works as it should now.
So perhaps the problems were simply caused by weak batteries. It wouldn't be the first time we've seen that happen.
Glad to hear you got it working.
-
I added a new bug:
* User is prompted to choose a file location and name when saving their AHX file, if they used the "browse" function during their session in AHP (such as when adding a Windows command to a macro). The folder defaults to the last-used folder, not the one from which the AHX file was loaded.
(added 2/6/2012 by Noam, but I think it has been around a long time. Confirmed still present in 3.318)
-
Moved the AHP fails to load bug to the top of the list.
I don't often open AHP any more but with some users reporting this after a resent Windows 7 update.
I opened AHP and it worked. I then noticed I hadn't installed some security patches so I updated windows.
I then tested AHP again and it failed to open. Removed the XML file and reinstalled to fix the issue.
This is no Longer a rare bug as X10 programmers had reported if a windows update will cause this.
Note: This has occurred for me with all reported ways known to cause the corruption.
This time I didn't waste my time submitting a xml file.(However I did rename the corrupt file and kept it)
The last time I submitted files I submitted my whole setup(all files).
Comparing my corrupt XML file with the new good one I find some noticeable differences.
There are multiple Dusk/Dawn entries now right after the entry
<ahphwconfig command="replace">
<HWConfigData WorldTime="129732228138710000" InterfaceTime="129732048030000000" BatteryTime="0" BatteryState="7012461823655937" FirmwareRev="2" MacroMemory="446" TimerMemory="130" TransceivedHouseCodes="37029" TransHCAuto="0" TransHCMode="2" ts="129732228122480468"/>
</ahphwconfig>
<ahpduskdawn command="replace">the good XML but at the first part of the corrupt file ::) :'
note: the good file states a firmware rev = 0 ::) :'
WorldTime="0" ::) :'
InterfaceTime="0" ::) :'
ts= entry is different as well
How can a newer file report an older firmware revision?
-
Update: after adding registration codes I decided to recheck the XML file.
Seems the firmware rev is related to registration as is the dusk dawn and other entries.
but these stay at the end of the xml and are not moved to the first part of the XML.
Seems everything after the entry
(<ahphwconfig command="replace">
<HWConfigData WorldTime="......) is move to the first part of the xml in the corrupt version. ???
-
I originally posted this in smart macros - but it seems that it fits better here. This (hopefully) provides some more details on the bug that says macros run twice when triggered by security events
---
Just an FYI - what I see is not necessarily the macros being run twice, but each command in the macro executing twice in a row. i.e. macro is set to turn a light on and off 3 times and send an email when a sensor is triggered. Used to result in
transmit J7
transmit on
transmit j7
transmit off
3 times
-> and then the email was sent
now I get
transmit J7
transmit on
transmit J7
transmit on
transmit j7
transmit off
transmit j7
transmit off
3 times - the lights only flash 3 times because it is sending on - on - off - off
-> and then the email is sent twice - 1 to 4 seconds apart
Hence, if the macro itself is executing twice, it is doing it virtually simultaneously, or each macro command is being executed twice.
You would think that this bug added by the latest code revision 5+ months ago would have been able to be fixed by now - especially since there is no work around. B:(
-
You would think that this bug added by the latest code revision 5+ months ago would have been able to be fixed by now - especially since there is no work around. B:(
Saddly many of the programers X10 had working on this have left.
Those still with the company are most likely working on ICS builds for the AirPads.
Hopefully they'll get back to AHP issues soon.
-
Sadly many of the programers X10 had working on this have left
Unfortunately I see no evidence that AHP will be moving forward at all - with the last update being 5+ months ago, the CM15a gone and replaced by older less capable devices, silence from X10 in these forums - and just lip service on the facebook page - it looks to me like they have changed the company focus to just resell airpads and security systems with dismal customer support and forget about the product suite built the company. >*<
-
Sadly many of the programers X10 had working on this have left
Unfortunately I see no evidence that AHP will be moving forward at all - with the last update being 5+ months ago, the CM15a gone and replaced by older less capable devices, silence from X10 in these forums - and just lip service on the facebook page - it looks to me like they have changed the company focus to just resell airpads and security systems with dismal customer support and forget about the product suite built the company. >*<
Sorry, you are 100% wrong there is X10 Repair Depot who is an X10 employee who has a constant presence here. He keeps us posted as to what the company is doing and X10USA is fine and a new interface are coming, possibly by July.
-
You are 100% wrong there is X10 Repair Depot who is an X10 employee who has a constant presence here. He keeps us posted as to what the company is doing and X10USA is fine and a new interface are coming, possibly by July.
I hope this ends up being correct, but in all honestly just the input from one x10 employee (no offense to X10 Repair Depot) still leaves me very skeptical with zero bug fixes since October '11. I have my fingers crossed that you are correct but I will believe it when I see it.
-
You are 100% wrong there is X10 Repair Depot who is an X10 employee who has a constant presence here. He keeps us posted as to what the company is doing and X10USA is fine and a new interface are coming, possibly by July.
I hope this ends up being correct, but in all honestly just the input from one x10 employee (no offense to X10 Repair Depot) still leaves me very skeptical with zero bug fixes since October '11. I have my fingers crossed that you are correct but I will believe it when I see it.
Keep your fingers crossed but do not hold your breath. X10 is on the road to recovery but I think the "July" release date for either new hardware or software is wildly optomistic.
-
I've found X10 Repair Depot to be very truthful in his posts considering he is an X10 employee. He would be the first person to post if that July date turned out to be false.
-
I've found X10 Repair Depot to be very truthful in his posts considering he is an X10 employee. He would be the first person to post if that July date turned out to be false.
X10 Repair Depot IS very forth coming, but like he said earlier, "....X10 has had a very tough year....". And like you said..... "he is an X10 employee".
Launching a replacement for the CM15A with (assumably) new software, after what X10 has been through, is an unbelievably difficult task. I believe the July date is a "wish date". I stand by what I said; "cross your fingers, but don't hold your breath". We'll settle this in July :-*
-
See http://forums.x10.com/index.php?topic=26297.0 (http://forums.x10.com/index.php?topic=26297.0)
>>...we will be putting our resources into developing a new and better product to replace the CM15A, we hope to release the new item during the 2nd half of 2012"
2nd half statement could be up to Dec 31, 2012
-
True. July starts the second half of the year. I'm sure X10 Repair Depot will keep us posted.
-
New bug added:
SDK sends multiple RF commands when connected to a CM19.
Programs created with the SDK send out multiple RF commands. This would effect dim/bright operation
Users running a CM15A don't experiance this.
-
Bug Fixed!! In 3.318 AHP no longer crashes when you add SC546A - though the module is now in OTHER not PRO.
-----------
* AHP crashes with a runtime error when adding an SC546A Chime Module from the "Pro Modules" category.
(original version unknown, added 10/19/2011 by Noam)
-
I don't see this reported bug. By security sensor I presume motion detectors are included. I have an MS13A that triggers a macro and it only runs once. Maybe the problem is not in AHP but the particular module is sending multiple triggers.
------------
* Macros triggered by a security sensor are run twice, while macros triggered by a normal HC/UC are run only once.
(v3.318, added 10/11/2011 by Noam)
-
This one is actually slightly worse than described in that every time you open Activity monitor it starts another iexplore process so if you open it 10 times you get 11 iexplore processes that never go away.
-------------------
* Opening the Activity Monitor starts two new iexplore.exe processes, without windows. They don't stop when you close AHP.
(added 2/19/2011, confirmed still present in 3.318)
-
Bug Fixed!! In 3.318 AHP no longer crashes when you add SC546A - though the module is now in OTHER not PRO.
-----------
* AHP crashes with a runtime error when adding an SC546A Chime Module from the "Pro Modules" category.
(original version unknown, added 10/19/2011 by Noam)
I know that I added this to the list on 10/19/2011, but I couldn't find the mention of adding it in the thread. I don't know how limited it was, but usually I would try to reproduce it before adding it, and I would try to reproduce it after each revision (especially if the developers marked it as having been fixed). I didn't add "confirmed still present in v3.318," so perhaps it did go away. If anyone else can confirm this still exists (or does not exist), I would appreciate it.
I don't see this reported bug. By security sensor I presume motion detectors are included. I have an MS13A that triggers a macro and it only runs once. Maybe the problem is not in AHP but the particular module is sending multiple triggers.
------------
* Macros triggered by a security sensor are run twice, while macros triggered by a normal HC/UC are run only once.
(v3.318, added 10/11/2011 by Noam)
If I remember correctly, these were the "security" modules, not the regular motion sensors. You needed to have the security plugin installed to interface with them. Since I didn't have any of those sensors or the plugin, I couldn't test it to confirm it one way or another.
This one is actually slightly worse than described in that every time you open Activity monitor it starts another iexplore process so if you open it 10 times you get 11 iexplore processes that never go away.
-------------------
* Opening the Activity Monitor starts two new iexplore.exe processes, without windows. They don't stop when you close AHP.
(added 2/19/2011, confirmed still present in 3.318)
That was the intended point of the report. However, we haven't seen any development work on AHP since October of 2011, so I wouldn't hold your breath about these getting fixed any time soon.
-
This one is actually slightly worse than described in that every time you open Activity monitor it starts another iexplore process so if you open it 10 times you get 11 iexplore processes that never go away.
-------------------
* Opening the Activity Monitor starts two new iexplore.exe processes, without windows. They don't stop when you close AHP.
(added 2/19/2011, confirmed still present in 3.318)
That another proof 3.318 is a full buggy version.
-
This one is actually slightly worse than described in that every time you open Activity monitor it starts another iexplore process so if you open it 10 times you get 11 iexplore processes that never go away.
-------------------
* Opening the Activity Monitor starts two new iexplore.exe processes, without windows. They don't stop when you close AHP.
(added 2/19/2011, confirmed still present in 3.318)
That another proof 3.318 is a full buggy version.
Huh?
Version 3.306 was released on 2/14/2011.
I added this bug to the list on 2/19/2011.
Version 3.310 was released on 3/25/2011.
What does this have to do with 3.318?
-
This one is actually slightly worse than described in that every time you open Activity monitor it starts another iexplore process so if you open it 10 times you get 11 iexplore processes that never go away.
-------------------
* Opening the Activity Monitor starts two new iexplore.exe processes, without windows. They don't stop when you close AHP.
(added 2/19/2011, confirmed still present in 3.318)
That another proof 3.318 is a full buggy version.
Was there ever a bug-free version? Really, almost any software will have bugs - just a matter of finding them.
-
Was there ever a bug-free version? Really, almost any software will have bugs - just a matter of finding them.
Exactly! The goal is to fix more bugs than you create.
There were versions which introduced fewer bugs (and/or fixed more bugs), and there were versions with introduced more bugs (and/or fixed fewer).
You can see a partial list of what was added or fixed using the "Revision history" link in my signature. That was created much later, after the original AHP development team had left.
The "Bug List" (also linked in my signature) is another place to look for when certain bugs popped up, and when others were fixed. That also started only later on (and is therefore incomplete).
-
Why isn't the "MSVCR100.DLL is missing" problem listed. It's popular on the forum and, well, google it.
-
Why isn't the "MSVCR100.DLL is missing" problem listed. It's popular on the forum and, well, google it.
My guesses:
1. Because it isn't a true bug in AHP.
2. Because there has been no indication that they still have any developers working on AHP, so it isn't going to get fixed anyway.
-
1. Would be fixed if they include the file in their 32 bit installer.
2. I totally agree. :)