X10 Community Forum

🖥️ActiveHome Pro => ActiveHome Pro General => Help & Troubleshooting => Topic started by: lviper on April 25, 2011, 10:29:33 AM

Title: AHP sending extended codes
Post by: lviper on April 25, 2011, 10:29:33 AM
Hello all,

Have a little issue going on and I'm not sure what it is. I have this macro that turns a light on when the door is opened during nighttime hours. It has works great for a while, but recently it is only turning the light on at a very low dimmed level. I noticed in the log, when the macro runs, AHP is sending the extended codes in stead of the on command like it used to do. I'm not sure when this started happening but the only thing I've done is upgrade AHP a few times hoping that would solve the issue.

Here is my setup:
AHP 3.311 w/SmartMacros, OnAlert and MyHouseOnline installed.

Front Door has a ds12a that when opened turns oh phantom p1 and sets flag 3
When p1 is on and it's nighttime, f9 turns on. F9 is a ws467.

I have and always had AHP set to send on instead of bright. The macro is set to on. The setup used to always turn the light on and I would see the on command in the activity monitor. But now it sends the extended codes and the light only turns on very dim.

I have installed a couple updates since I've noticed this problem. I think I noticed this around version 3.309. I think that's when I tried the 3.310 upgrade to see if it would fix it. Then I tried 3.311 but still have the problem. I have done upgrades, not delete and full installs which I think is what you all are going to suggest. Oh, and I have tried unplugging the cm15a, remove the batteries and wait 5 minutes. Hooked it back up, downloaded and still have the problem.

Also, I can turn the light on at the wall but it is reset to the lowest dim after ahp sends the extended codes. So I turn the light on then press and hold till I get 100% bright. Tap to turn off and again tap to turn on and it's full bright. I use a palmpad to turn the light on and off and it works as expected. I turn the light on and off from ahp and it works normal. Only time I have the problem is when the macro turns the light on.

Now that I'm writing this, I haven't tried manually running the macro. All I've tried from ahp is turning the actual module on and off. Guess I need to try manually triggering the macro. I may even set a palmpad to HC P do I can trigger the phantom P1 and see what happens. Though I would think it would send the extended codes. I really don't see how the ds10a or ws467a could be the problem, but I've wouldn't overlook it either.
Title: Re: AHP sending extended codes
Post by: Brian H on April 25, 2011, 12:57:55 PM
Are the modules old enough to be before soft start? Where the modules ramp on and off?
AHP 3.11 and a few versions back was updated for the newer soft start modules.
If yours are the older ones there is now a separate list of Before Soft Start Modules in AHP.
Redefine them from the before soft start if they are the older ones.
Title: Re: AHP sending extended codes
Post by: Tuicemen on April 25, 2011, 01:37:22 PM
Just to clarify Brians statement.
Old non softstart light modules must be defined as "Older Lamps (No Softstart)" and not defined as "Lamps" as they were previously!
 >!
Title: Re: AHP sending extended codes
Post by: lviper on April 25, 2011, 04:33:00 PM
No, the ws467 is a soft start. Ramps up and down.

It did this once before but I forget what version ahp I was running. IIR, it was the first 3.3 version and I just cleared the cm15a, unplugged and removed the batteries. Waited several minutes and hooked it back up and downloaded. Then it started to work correctly again.
Title: Re: AHP sending extended codes
Post by: lviper on April 26, 2011, 10:32:36 AM
I spent some time last night an tried a few things.

If I turn the light on from the module in ahp, it is sending the extended codes. I checked all my ws467a modules and this is the case. Only difference, with the one giving the problem, the extended code is actually sending 0%. If I turn the light on from the palm pad, ahp sends F9 On and the light comes on fully. So I deleted the troubled module, cleared the trash and added a new module. Now the light turns on at 100% but the ahp is still sending extended codes.

Correct me if I'm wrong, but since I have smartmacros set to send ON instead of 100% bright, I shouldn't be seeing extended codes. Is that correct?
Title: Re: AHP sending extended codes
Post by: ErikP on April 26, 2011, 06:04:53 PM
Commands sent from the PC are routed through the X10net service, which automatically translates the ON command into an extended command because it is aware that the module at that address is a module expecting extended codes.  In this case, the macro ON command will be translated into an extended bright command.

Unfortunately the service is unaware of exactly which module the command is meant for so if you have multiple modules at the same address and one of them expects extended codes, all commands sent to that address will be translated.  Double check your recycle bin is clear of old deleted modules too as they are not fully removed until the bin is emptied so they can still cause translation errors.

I think what is/was happening here is that the Soft Start modules are meant to remember their bright state between on and off commands.  For this reason, if the module was dimmed to 0%, then turned off, then turned back on, it would turn on at 0% brightness.  To achieve the old behavior add a 100% brightness absolute command to your macro after the on command.  This will ensure the module is not only on, but at full brightness as well.  Alternatively if you don't plan to ever bright or dim the module just brightening it to 100% then turning it off should set the remembered state so next time you turn it on it should go to 100% bright.
Title: Re: AHP sending extended codes
Post by: Noam on April 27, 2011, 09:04:32 AM
Commands sent from the PC are routed through the X10net service, which automatically translates the ON command into an extended command because it is aware that the module at that address is a module expecting extended codes.  In this case, the macro ON command will be translated into an extended bright command.

Unfortunately the service is unaware of exactly which module the command is meant for so if you have multiple modules at the same address and one of them expects extended codes, all commands sent to that address will be translated.  Double check your recycle bin is clear of old deleted modules too as they are not fully removed until the bin is emptied so they can still cause translation errors.

I think what is/was happening here is that the Soft Start modules are meant to remember their bright state between on and off commands.  For this reason, if the module was dimmed to 0%, then turned off, then turned back on, it would turn on at 0% brightness.  To achieve the old behavior add a 100% brightness absolute command to your macro after the on command.  This will ensure the module is not only on, but at full brightness as well.  Alternatively if you don't plan to ever bright or dim the module just brightening it to 100% then turning it off should set the remembered state so next time you turn it on it should go to 100% bright.
I've seen something similar with my setup.
The problem is that AHP (or the X10nets service) is NOT sending the Extended Code for 100%, but rather for whatever dim level the light was at the last time it was on. It SHOULD not be doing that. If you tell it to turn the light on to 100%, it should do just that - send an extended command for 100%.
Title: Re: AHP sending extended codes
Post by: ErikP on April 27, 2011, 03:04:10 PM
Sending the bright level for the last state is a correct and normal behavior for the new Soft Start modules.

It is a change from the old lamp modules, so requires thinking about things slightly differently, but it is correct in this case.  The idea is that ON and OFF can exist independent of the bright level and be processed without affecting it. 

The main reason for this it is much more flexible with this model than with the old one.  If you want the module on and at a 100% with the new model you send bright absolute 100%.  With the old you send ON.  To turn a module on, but remember its dim status, you send ON with the new model...  I'm not even sure its possible to make a macro to do this with the old model, though I have not spent a lot of time pondering it.
Title: Re: AHP sending extended codes
Post by: Noam on April 27, 2011, 04:33:46 PM
Sending the bright level for the last state is a correct and normal behavior for the new Soft Start modules.

It is a change from the old lamp modules, so requires thinking about things slightly differently, but it is correct in this case.  The idea is that ON and OFF can exist independent of the bright level and be processed without affecting it. 

The main reason for this it is much more flexible with this model than with the old one.  If you want the module on and at a 100% with the new model you send bright absolute 100%.  With the old you send ON.  To turn a module on, but remember its dim status, you send ON with the new model...  I'm not even sure its possible to make a macro to do this with the old model, though I have not spent a lot of time pondering it.
Erik -
I understand your answer, and the "Resume Dim" feature can be useful, sometimes.
However, it isn't the module that is behaving differently, it is AHP and the X10nets service.
If I send an "On" from my HR12A, then the lamp comes on, at full brightness.
Here's the scenario:
I use AHP or the SDK to turn on my lamp at 50%, so I can watch a movie. (timer, macro or whatever).
I then leave the room, and turn the light off with an HR12A.
I then come back, and turn the light back on (to 100%) with an HR12A.
Another SDK function (motion sensor, timer, or whatever) then turns the light back on, expecting it to be at 100%.

If I do the following sequence, Here's what ACTUALLY happens:
1) Turn on lamp using SDK to 50% ("SendPLC C14 ExtCode 31 1F") : Lamp comes on at 50%.
2) Turn lamp off with HR12A: Lamp goes off
3) Turn lamp on with HR12A: Lamps comes on at 100%
4) Turn lamp on again using SDK ("SendPLC C14 On") : Lamp DIMS DOWN to 50%!

This sounds like an issue, since the light had been at 100%, but the SDK/X10nets didn't register that change from the HR12A. If you make X10Nets register that change, then how do you use an HR12A to get the light to full brightness?
Title: Re: AHP sending extended codes
Post by: ErikP on April 27, 2011, 05:01:48 PM
In this case there may be a bug in AHP's recording of incoming commands.  I don't believe it currently considers the ON command to affect the current bright level so it would not remember the 100% bright level unless it recorded a bright/dim command as well. 

In short its outgoing command processing is correct, but is flawed by relying on data from incorrect incoming command parsing.  At least that is my theory as to what is happening in this case.  I will look into the code some more to confirm/fix this.

This should not effect systems which are not receiving commands from outside of AHP.  AHP should always send extended commands to Soft Start modules, unless being translated for the CM19 transceiver.
Title: Re: AHP sending extended codes
Post by: Noam on April 27, 2011, 07:18:45 PM
In this case there may be a bug in AHP's recording of incoming commands.  I don't believe it currently considers the ON command to affect the current bright level so it would not remember the 100% bright level unless it recorded a bright/dim command as well. 

In short its outgoing command processing is correct, but is flawed by relying on data from incorrect incoming command parsing.  At least that is my theory as to what is happening in this case.  I will look into the code some more to confirm/fix this.

This should not effect systems which are not receiving commands from outside of AHP.  AHP should always send extended commands to Soft Start modules, unless being translated for the CM19 transceiver.

Erik -
I understand your explanation, but I'm questioning if the X10nets service should be translating the "On" command into "Bright/Dim to the last level I remember for that module" every single time.
Perhaps we need a separate SDK command for "Resume On," and leave "On" to mean "Turn on at 100%", as it always did in the past, and still does for older modules.
Title: Re: AHP sending extended codes
Post by: ErikP on April 28, 2011, 01:15:17 PM
For the SDK this is already in the works.  Its important for the SDK to have an unmodified code path so advanced users can really specify exactly what goes out from the SDK.

The current thinking right now is this will take the form of a "notranslate" flag which will prevent the translation algorithm or anything else form modifying the command away from whatever was specified to the SDK.
Title: Re: AHP sending extended codes
Post by: Noam on April 28, 2011, 08:35:39 PM
For the SDK this is already in the works.  Its important for the SDK to have an unmodified code path so advanced users can really specify exactly what goes out from the SDK.

The current thinking right now is this will take the form of a "notranslate" flag which will prevent the translation algorithm or anything else form modifying the command away from whatever was specified to the SDK.
Sounds like a good plan to me.
When the SDK is updated, would it be possible for the "web guys" to make a note of the release date of the new version on the download page? Currently, there is no way to know if the version I have is the same as the one on the download page, or if a newer one was released.
Title: Re: AHP sending extended codes
Post by: -Bill- (of wgjohns.com) on April 28, 2011, 11:08:45 PM
For the SDK this is already in the works.  Its important for the SDK to have an unmodified code path so advanced users can really specify exactly what goes out from the SDK.

The current thinking right now is this will take the form of a "notranslate" flag which will prevent the translation algorithm or anything else form modifying the command away from whatever was specified to the SDK.

By all means, make the flag "notranslate" = true by default!  Otherwise we'll all have to rewrite our software, (that wasn't broken until you changed things), anyway. B:(
Title: Re: AHP sending extended codes
Post by: Noam on April 29, 2011, 01:17:28 AM
By all means, make the flag "notranslate" = true by default!  Otherwise we'll all have to rewrite our software, (that wasn't broken until you changed things), anyway. B:(
I second that!
Title: Re: AHP sending extended codes
Post by: lviper on May 01, 2011, 10:38:30 AM
Ok, I haven't finished my coffee yet and this thread will take another reading to fully understand this morning. But, here is what I did and question.

I have ahp 3.313 installed. I turn on F9 which is a ws467 via a macro, I see the extended code being sent.
I have the "Issue 'On' inplace of 'Bright 100%'" option checked in macro preferences.

This didn't used to happen. Once I checked this option I saw the On command being sent. I also remember reading here about using this option to speed up the macro operation.

So I tried completely removing ahp, reboot and reinstall 3.313. Still have the problem.
Next I uninstalled again and reinstalled 3.296 since it was my first ever version and I knew it worked the way I remember.

Now, with 3.296 installed, and the On instead of Bright 100% option checked, it works how I remember.
I use the module icon in ahp to turn the light on and the activity log show F9 On. Not the extended code.
If I trigger the macro I again see F9 On and not the extended code.

So I guess my question is, did something change or is it a bug? Maybe v3.296 was the version with the bug and 3.3xx if working correctly? Because ever since v3.3xx I only see extended codes and it always seems to send On at 0% even though my last time I turned it on was at 100%. The macro is set to turn F9 ON, not F9 100%.
Title: Re: AHP sending extended codes
Post by: Noam on May 01, 2011, 12:02:22 PM
They changed the behavior of the X10nets a few versions back.
Version 3.302 added support for SoftStart modules and Extended Dim commands.
Version 3.310 changed the behavior of the SDK and macros to always use Extended commands for those modules that support them.
You can see the entire Bug List in this thread:
http://forums.x10.com/index.php?topic=22373.0

The developers are aware of it, and are working on a way to turn that behavior on and off.
Title: Re: AHP sending extended codes
Post by: devedsmith on August 22, 2011, 02:31:58 AM
This issue is driving me crazy. AHP Is completely disabled and unusable because it always sounds extended codes instead of ON. Should I reinstall older version?
Title: Re: AHP sending extended codes
Post by: Noam on August 22, 2011, 02:40:50 PM
This issue is driving me crazy. AHP Is completely disabled and unusable because it always sounds extended codes instead of ON. Should I reinstall older version?
If the modules are defined in AHP under the "Old Lamps - no SoftStart" category (instead of "Lamps"), then AHP should be sending the old-fashioned on/off/dim commands.
Title: Re: AHP sending extended codes
Post by: devedsmith on September 09, 2011, 11:45:57 AM
I found it. Thank you! Silly that they would need a category just for those modules instead of merely building that behavior into the module profile. Any reason why I'm no longer able to use All Lights On in a ROOM?
Title: Re: AHP sending extended codes
Post by: Noam on September 09, 2011, 04:16:29 PM
I found it. Thank you! Silly that they would need a category just for those modules instead of merely building that behavior into the module profile. Any reason why I'm no longer able to use All Lights On in a ROOM?
Back in 2008, they redesigned the lamp modules (and wall switches), but didn't change the model numbers. They needed a separate category for the older ones, since any module purchased after 208 (including any future purchases) would be the SoftStart ones, and they didn't want to confuse new users, I guess.
Title: Re: AHP sending extended codes
Post by: devedsmith on December 13, 2011, 01:29:08 PM
So what you're saying is that there are LM465's with soft start?
Title: Re: AHP sending extended codes
Post by: Noam on December 13, 2011, 02:42:26 PM
So what you're saying is that there are LM465's with soft start?
Yes. Since about 2008, all of the LM465s being manufactured are SoftStart.
Unfortunately, they didn't change the model number, and you can't tell by looking at them. You really need to test them to be sure.
Title: Re: AHP sending extended codes
Post by: Brian H on December 13, 2011, 03:42:42 PM
As Noam pointed out.
Only real way to tell is. Turn it On and Off. If it ramps On and Off at about a three second rate. You have a Soft Start LM465.
I have seen two versions of the Soft Start LM465s.
One ramped On and Off when triggered by a Security Console Alarm.
That was corrected in a later Date Code to Soft Start as expected but go On and Off instantly from a security Consoles stream of On/Off or All Lights On/All Units Off power line commands.

Users with mixed old and soft start LM465s. Frequently tag or mark LM465s as to their type.
Title: Re: AHP sending extended codes
Post by: devedsmith on December 13, 2011, 06:38:03 PM
This is so unfortunate and it's why I'm slowly converting everything to z-Wave. I know it's more expensive but it doesn't have any of these issues or blunders. I can't get AHP to work at all any more with my old modules. If I have a module setup for the old style, close and re-open AHP, it reverts to sending extended commands. It's very frustrating.
Title: Re: AHP sending extended codes
Post by: Dan Lawrence on December 13, 2011, 10:04:57 PM
Try backing up your .ahx files and uninstalling AHP and then installing AHP 3.310 which is stable version in my opinion.
Title: Re: AHP sending extended codes
Post by: Noam on December 14, 2011, 10:05:01 AM
... If I have a module setup for the old style, close and re-open AHP, it reverts to sending extended commands. ...
Are you saving the file, and re-downloading when you exit?
You might also try backing up your AHX file and creating a new one, as Dan suggested.

One other thing - make sure that you don't have both "New" and "Old" modules defined in AHP for the same HouseCode/UnitCode combination. From the testing I did, that produced unpredictable results, and I would advise you to avoid that. Same goes for mixing module types (lamps with appliances, for example) on the same HouseCode/UnitCodes within AHP. (I suppose if you wanted a lamp module to come on and off with the same timers as an appliance module, and you don't care about dimming it, you COULD define ONLY the appliance module in AHP, and just set the physical lamp module's HC/UC the same as the appliance module.)
Title: Re: AHP sending extended codes
Post by: devedsmith on December 28, 2011, 07:18:47 PM
Ok, I tried this: Using a brand new AHX file, I added an old style lamp module. Clicking the switch sends an "ON" to the lamp module. When I closed and re-opened AHP, and clicked the switch, AHP sends extended code instead of "ON". I've done this several times and I can repeat it every time. Any ideas?
Title: Re: AHP sending extended codes
Post by: Noam on December 28, 2011, 07:42:16 PM
Ok, I tried this: Using a brand new AHX file, I added an old style lamp module. Clicking the switch sends an "ON" to the lamp module. When I closed and re-opened AHP, and clicked the switch, AHP sends extended code instead of "ON". I've done this several times and I can repeat it every time. Any ideas?
Did you save the file, and download to the CM15A before closing AHP?
I tried this, and I'm unable to duplicate it.
I created a new file, and added one old style lamp module. I saved the file, and was able to turn it on and off (and verified the commands were correct). I closed AHP, and re-opened it. It was still defined as an old style, and it still sent the same old-style commands. I tried a few times, and I can't duplicate your issue. Sorry.
You didn't add BOTH an old and a new module on the same code, did you?