Print

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

[Dan Lawrence]

Can you post the macro here so we can see what's going on, plus a list of the modules addresses involved?

[s0urc3f0ur]

Well it's definatley a bug in the newer software versions of AHP. I reverted back to 3.204 and all works fine now. I tried to call tech support but got no answer after 45 minutes of letting the phone ring. I wonder if someone could contact the Developers and inform them of this issue.

[Brian H]

Maybe a holiday for X10 support.
Many companies used today for Christmas because it was on a Sunday.
Some even have closed for the whole week.

[Dan Lawrence]

Well it's definatley a bug in the newer software versions of AHP. I reverted back to 3.204 and all works fine now. I tried to call tech support but got no answer after 45 minutes of letting the phone ring. I wonder if someone could contact the Developers and inform them of this issue.

Have you tried AHP 3.310?  I use it with zip problems.  I have no plug-ins and only 1 soft-start wall switch in an upstairs storage room and everything works fine for me.  All other modules are all "old style" and I have working modules with X10, Motorola, RCA, Radio Shack, IBM on them and they all work fine.

[s0urc3f0ur]

No I havent. I had AHP installed on old Pc and checked the version on it and it was 3.204. I figure if it works I aint messing with it.

[Dan Lawrence]

No I havent. I had AHP installed on old Pc and checked the version on it and it was 3.204. I figure if it works I aint messing with it.

That falls squarely in the "If it ain't broke, don't fix it." department. I used 3.228 for years until 2011 when I tried a few of the 2011 AHP releases I settled on 3:310 as it caused ZERO problems.  I keep a 250MB Zip drive with virtually every version of AHP since 2005 and a backup of all my .ahx files, which I have a bunch of for the various seasons of the year.

[Noam]

Well it's definatley a bug in the newer software versions of AHP. I reverted back to 3.204 and all works fine now. I tried to call tech support but got no answer after 45 minutes of letting the phone ring. I wonder if someone could contact the Developers and inform them of this issue.

Well, I'll send them an e-mail letting them know about it, but I don't know when I might get a reply.
Let me make sure I have this correct.
You have two SoftStart LM465's on two different addresses on the same housecode.
You have a macro that turns both of them on.
Using 3.204, the macro combines the commands, so the lights come on together.
Using 3.318, the commands are kept separate, so the lights come on separately.

Do I have it right?

[s0urc3f0ur]

You have two SoftStart LM465's on two different addresses on the same housecode.
You have a macro that turns both of them on.
Using 3.204, the macro combines the commands, so the lights come on together.
Using 3.318, the commands are kept separate, so the lights come on separately.

That is correct. I remember that I updated past 3.204 several months ago and the macro worked. Unfortunatly I don't know what version it was that I updated to.  The only reason I am using 3.204 is because that's the version that I have on an old PC and I know that works.

[Brian H]

I believe 3.203 is where X10 added the Soft Start Modules in the Lamps Area and added theOld before soft starts list.
Where they defined a soft start or maybe an LM14A as that was the fix for older versions of AHP.

[Noam]

The only reason I am using 3.204 is because that's the version that I have on an old PC and I know that works.

Most of the older versions (the ones that were released, at least) are available for download.
Check out the Revision History here:
http://www.x10.com/support/rev_ahp.htm

There are links to most of the versions, and you can download and install them.

[Noam]

I don't have my "test setup" available to me right now.
Can anyone else out there with 3.318 try to duplicate this problem, so I can add it to the Bug List?
I don't generally add items to the list unless I can either confirm it myself, or get one or two other users to confirm it. Sometimes it is just a fluke in one user's system, and not a bug in the software.

Also, with additional testing, we sometimes get a workaround, or another fix for it.

Thanks.
--Noam

[Noam]

Well, I remoted into one of my systems, and I think I was able to reproduce this on 3.318.
I added two Lamp modules, calling them E1 and E2.
I created a simple macro that simply turned them both on.
When I ran it, the commands ran one at a time (based on the activity log).
Next, I changed both lamps to "Old" lamps.
The same thing happened (although the commands did change from the Extended ones to the "%Dim" ones).

That's enough proof for me. I'll add it to the list, and let the developers know that the bug is on the list.

If anyone wants to test further, and try to find a fix for this, feel free.
--Noam

[Dan Lawrence]

Not sure what you mean by calling all the addresses before I send an action. But I did re-write the macro and I sitll get the same result. I just don't get why it worked fine before the update and now it does not.. Maybe someone could test this on their end and see if it works for them? it's a simple on macro: trigger B6 on, Macro: right lamp B1 , left lamp B2 both are set to absolute on.

B1 will light first, B2 will light second, etc.  If you want both/all to go on at once they must all have the same unit code :B1.

[s0urc3f0ur]

I added two Lamp modules, calling them E1 and E2.
I created a simple macro that simply turned them both on.

That's the same macro I've been using. A simple on and off.

[Noam]

Not sure what you mean by calling all the addresses before I send an action. But I did re-write the macro and I sitll get the same result. I just don't get why it worked fine before the update and now it does not.. Maybe someone could test this on their end and see if it works for them? it's a simple on macro: trigger B6 on, Macro: right lamp B1 , left lamp B2 both are set to absolute on.

B1 will light first, B2 will light second, etc.  If you want both/all to go on at once they must all have the same unit code :B1.

It used to not be this way. In previous versions a macro that had B1 turning on followed by B2 turning on would send something like this: "B1, B2, B On". Both modules would "wake up" when their address was called, and they would both respond to the command at the same time. It is actually a lot more efficient to do it this way.
I haven't tested with earlier versions in a while, but I know that is how it used to work (it is even in the X10 protocol spec to do it this way). When I tested this in 3.318, I couldn't get it to work that way. It didn't matter if the modules were defined as "new" or "old" ones.
However, I think you can use the "advanced" functions of the SmartMacros, and send the individual addresses, followed by the command, and it should work (I think I tested that yesterday, not 100% sure).