Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Noam]

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.

[ErikP]

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

[Noam]

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

[ErikP]

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?

[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?

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.

[ErikP]

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.

[Noam]

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.

[Dan Lawrence]

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.
 

[Noam]

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

[ErikP]

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.

[Dan Lawrence]

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.

[StanL]

 
  * 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!!!

[Noam]

 
  * 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?

[Tuicemen]

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!

[Noam]

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