Print

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

[JBPatt]

X-10 Tail of Woe

I have about 15LM465 modules controlling 4 watt lamps in my windows and several other appliance modules and wall switches in my house.  The window lights are supposed to come on at dusk, dim to 50%, and go off at 11pm.  I use another module for a night light at 100%, and it goes off at dawn.
I’m transitioning from my Plato HouseLinc control to Active Home Pro, with a CM15A interface, because the HouseLinc software does not support the new daylight savings time start and stop dates and the user interface is dated.
I could not imagine how difficult this transition would be.
I created all the modules in the AHP interface, set up timers on each of the modules, downloaded to the CM15A, and started the system.  About half of the modules didn’t work, mostly those on the B house code.  I physically moved some of the modules to see if the problem was related to the location or the module.  The problem moved with the module to the new location. 
I carefully recreated the non-working modules in AHP and moved them to the D house code.  After that only one of them would work.  Five of the modules that previously worked stopped responding. The night light comes on at dusk but won’t shut off automatically. 
I upgraded my software to 3.304 and recreated three LM465 modules as LM14A modules in AHP.  Now one of them works, one doesn’t work, and one comes on but won’t go off. 
I created macros to turn three of the modules on and off and set up timers to activate the macros.  The macros run on time, but I still have one module that won’t come on and one that won’t go off.  The one that worked before now comes on, but it’s so dim I can hardly see that the lamps it controls are lit.
All the timers are set to Daily.  I can’t upgrade to 3.305.  The file (sw31a_setup_ahp.exe) that’s supposed to be 3.305 loads and identifies itself as 3.304.  I'm running AHP with the Smart Macros plug-in.
The activity log entry for the module that works has three lines:
631  2/3/2011 17:39:20 PM  Macro  B11 (Den Window Lamps)
632  2/3/2011 17:39:20 PM  Macro B Bright 100% (Den Window Lamps)
633  2/3/2011 17:39:20 PM  Macro  B Dim 50% (Den Window Lamps)
A typical log entry for one of the non-working modules has just one line:
635  2/3/2011 17:39:22 PM  Macro  C8 Extended Code 20 31 - Preset receiver operation (MBR Window Lamps)
I set the lamp levels manually and turned them off with the macro, running it from the GUI.  Then I ran the macros to turn on the window lamps from the AHP GUI.  Same result.  Only one module activates its lamps, and they are almost too dim to see.  The macros to turn off the lamps seem to work. 
I replaced the lamp module that works with another LM465 set to the same house code.  I cleared the interface memory and downloaded the timers and macros from the laptop.  The new module works in the old location and codes.  I found out that AHP thinks this LM465 is a Leviton Wall Switch (6383).  My error.  But when I copied this module into another room and set the codes for the module in that room, it fails to activate the module there.
I changed the settings in the macro to ON instead of 50% on several of the LM465 modules.  Now the LR (listed as 2-way Lamp Module) only works from the GUI in AHP, not from the macro.  Reset this module to Lamp Module.  No help, same story.  The DR (also described as a 2-way lamp module), the one that was coming on very dim when set to 50% now comes on.  Reset this module to Lamp Module in AHP.  Still works at ON. Both of these modules drive three 4 watt bulbs. D4 works OK as Lamp Module, drives 3 4watt bulbs.  D5, same room, same circuit, driving one 4w lamp, doesn't work as either a Lamp Module or Leviton 6383.  A Decorator Wall Switch, properly identified in AHP, lights by macro when set to ON, but not when set to 100% or lower. I don’t want to run any of these modules at 100%, so that's not a solution for me, even if it did work reliably. 
Bottom line.  Timers control Macros which have the modules with brightness levels set.  Most modules don't work when activated by macro.  Everything works when activated by the AHP GUI.
I’m running AHP on a laptop with Vista.  I keep the laptop connected to the CM15A for now so I can monitor the Activity Log.
I firmly believe I must be doing something wrong.  Although I've seen a lot of problems in the forum I still don't believe this could be this hard and still have anybody using these systems.  Anyone, please provide your ideas on what I might do differently.  Sorry this is so long, but I thought it important to show where I've been.  Thanks.

[Brian H]

If you are using AHP version 3.304. 3.305 is now available.
The default Lamp Module list is for the new Soft Start versions.
If yours are old enough to be not Soft Start. Use the separate Older Lamps (No Soft Start) module list for the Lamp and Wall Switch Modules.
The soft start {two second ramp On and Off} use different commands for control than the older ones do.
The LM14A trick may work, but I have no concrete data on that. When 3.304 or 3.305 is being used.
http://kbase.x10.com/wiki/SoftStart

[Noam]

I agree with Brian.
Update your AHP to 3.305 (or whatever version is the latest as you read this) first.

You didn't specify how long you've had the modules you have.
Around 2007-2008, X10 changed the circuitry in their lamp modules and wall switches, but didn't change the part number.
The newer ones are "SoftStart," and they respond to the "Extended Dim" codes.
Beginning with version 3.302, AHP now has separate definitions for the newer "SoftStart" modules (listed under the "Lamps" category), and the older ones "listed under "Old Lamps (no SoftStart)".

Your problem may be that at least some of your modules may be the non-SoftStart ones, but are defined in AHP as SoftStart modules.
Older modules won't respond to Extended Dim commands, so they won't dim if defined incorrectly. In many cases they won't turn on, as AHP uses an Extended code for that, too.

The trick is figuring out which of your modules are older, and which are newer.
The easier way I've found, is to turn them on (either using a remote, or using the "switch" in the AHP interface).
Watch the lamp. If it comes right on at full brightness, it is an older module. If it "ramps up" to full brightness, then it is a newer one.

Once you figure that out, you can define them the right way in AHP, and they should work for you.
You might want to mark them to avoid confusion in the future.

[m82a1pa]

I've been struggling with this for some time now.

All my lamp modules are the LM465's, bought new in the last couple of months.  So I expect they are the SoftStart type.

I have a hall lamp that I wanted on a timer.  It absolutely would not turn on or off from the CM15A interface.  Yet I could manually turn it on or off from AHP.  The HR12A remote would not work either.  Eventually I found that changing the module type in AHP to the older type made it function in the current release of AHP, the CM15A and the HR12A.  When the SoftStart LM465 definition was used in AHP, the lamp was instantly on or instantly off.

I could take the lamp module, move it to my den lamp, and the SoftStart worked.  I've tried several lamp modules with the same results.

On another note, in my activity log, I see 'Receive RF - M MTCDDVD'.  Is this something being transmitted from my DS7000 security box?

[Noam]

I've been struggling with this for some time now.

All my lamp modules are the LM465's, bought new in the last couple of months.  So I expect they are the SoftStart type.

I have a hall lamp that I wanted on a timer.  It absolutely would not turn on or off from the CM15A interface.  Yet I could manually turn it on or off from AHP.  The HR12A remote would not work either.  Eventually I found that changing the module type in AHP to the older type made it function in the current release of AHP, the CM15A and the HR12A.  When the SoftStart LM465 definition was used in AHP, the lamp was instantly on or instantly off.

I could take the lamp module, move it to my den lamp, and the SoftStart worked.  I've tried several lamp modules with the same results.

On another note, in my activity log, I see 'Receive RF - M MTCDDVD'.  Is this something being transmitted from my DS7000 security box?

I suspect that you might have been sold some older stock.
A quick test here agrees with my suspicion.
I have a "test rig" at work, that I use for testing different AHP things. I have a lamp plugged into a SoftStart LM465.
In AHP, I have C14 defined as a SoftStart LM465, and C13 defined as a non-softStart LM465.

With the module set to C14, clicking the switch in the AHP interface causes the lamp to "ramp-up" to full brightness. Clicking the switch "off" causes the lamp to "ramp down" to off. This is the normal behavior for a SoftStart module.
I changed the address of the module to C13, and did the same test. Sure enough, it STILL did the slow ramp-up.

Next, I used the AHCMD utility from the SDK.
(Since the SDK doesn't know if it is a SoftStart or not, I left the module definition at C14 for these tests)
Sending it "C14 On" caused  a slow ramp-up.
Sending a "C14 Off" caused a slow ramp-down.
That agrees with what AHP is doing.

Sending it a "C14 ExtCode 31 3e" caused it to ramp-up to 100%.
Sending a "C14 ExtCode 31 01" caused it to ram down to the lowest dim level.
Sending a "C14 ExtCode 31 3f" caused it to turn on to full brightness immediately.
Sending a "C14 ExtCode 31 00" caused it to turn off immediately.

That agrees with the correct Extended Dim behavior.

From my experience, using a handheld remote, the SoftStart modules should ALWAYS ramp-up and ramp-down. The Handheld remotes don't send Extended Dim commands, unless you use them to trigger a macro.
Non-soft Start modules will always go to "full on" from a handheld remote.

I suggest testing each one of your modules, to try and determine if they are all, indeed, SoftStart ones.

[Brian H]

I have found differences between Soft Start Lamp Modules.
I believe the later ones where tweaked to fix the Security Consoles not flashing them correctly.
My 08A01 Lamp Modules ramp up and down always.
My 09J44 Lamp Modules ramp up and down on a single on or off command but revert to fast on and off if more than one commend is sent in a short amount of time.

All Lights On and All Units Off act differently between them also.

I have not checked them lately with a CM15A and a HR12A. As some versions of the CM15A firmware send multiple on and offs with a HR12A.

[Noam]

I have found differences between Soft Start Lamp Modules.
I believe the later ones where tweaked to fix the Security Consoles not flashing them correctly.
My 08A01 Lamp Modules ramp up and down always.
My 09J44 Lamp Modules ramp up and down on a single on or off command but revert to fast on and off if more than one commend is sent in a short amount of time.

All Lights On and All Units Off act differently between them also.

I have not checked them lately with a CM15A and a HR12A. As some versions of the CM15A firmware send multiple on and offs with a HR12A.

I never noticed that (since I don't have the security console).
However, I just tested using the SDK, and my LM465 (10I39) ramps up and down. However, if I rapidly send alternating "on" and "off" commands, it switches to "fast on"/"fast off" mode. Waiting a few seconds puts it back to normal.

sending "All Lights On" and "All Units Off" (as well as "All Lights Off" which is only heard by those modules that hear Extended commands) results in "fast on"/"fast off" behavior.
However, sending three "C14 On" commands in a row, followed by a "C14 Off" results in a ramp-up, and then a ramp-down.
So, the repeated commands (like I have for my timers) shouldn't kick it into "security flash" mode.

[Brian H]

Thanks for the added data and tests.
I am not an SDK users so the tests gave me added information.

[Noam]

Thanks for the added data and tests.
I am not an SDK users so the tests gave me added information.

I have a few third-party utilities that use the SDK, but I also use it for sending quick X10 commands from other PCs around the house.

Using PSExec (part of the PSTools suite that is now available free from Microsoft), I can remotely run commands (like the AHCMD.exe) on my Home Automation PC.
A few command-line scripts, and I can turn on and off lights, etc from any PC in the house.
I have a folder in my Start Menu for "X10 Commands", and shortcuts to the different scripts.

[JBPatt]

I wrote a short macro to test whether I was using an old or new LM465.  The macro wants to cause a new LM465 on D15 to come on at 50%, wait 5 secs, turn off, wait 5 secs, then an old LM465 is commanded to come on at 50%, wait 5 secs and turn off.  I tested 5 modules with this macro, one Radio Shack, the others X-10.  All five come on bright and ramp down to 50%, go off, come on bright again and ramp down, and go off.  No difference.  No extended codes in the log for this test for either type module. 

I took two of the modules that had passed this test and installed them in the windows under D4 and D5.  Ran the macro that commands these codes to turn on to 50%.  Neither one comes on.  Took another module that had passed the test at D15 and set it to D4.  Put this module in the plug next to my computer where I had successfully tested the five modules earlier.  Ran the macro that turns on the window lamps, D4 included.  It does not come on.  No extended codes in the activity log for these modules in this event.

The activity log shows both D4 and D5 with three lines, getting attention, going to 100% then to 50%, but no lights.  No extended codes here.  The activity log for the "test" shows four lines for each on cycle: wake up, 100%, dim to 50%, then a Receive to 52%.  Wait 5 secs.  Wake up, then OFF.  Wait 5 secs and repeat.  No difference in the log entries for the old or new modules.  Light work for either definition.

So, now, why do I get extended codes on new modules sometimes and not others?  Why do the commands for old modules go unanswered on some house codes but not other house codes in the same socket?

[Noam]

I'm not sure what's going on with your setup, but your "test" macro is not working correctly.
It should be sending Extended Dim commands for the first portion, and those modules, if they are SoftStart, should be ramping up to the 50% mark.

Since you are not seeing the extended codes in the Activity Log, you are not performing a true test.

I did have a few issues if I changed modules back and forth between "old" and "new". Sometimes, they would still use the "old" style commands, even after being defined as a "new" module.

Also, if you have both "old" and "new" modules on the same Housecode/Unitcode, AHP will only send the "old" commands.

You might want to add a definition for a brand-new module, on a previously unused HouseCode/UnitCode, and define it as a "new" lamp module.
Then, set the modules you want to test to that address, and re-run your test.

As for why the signals seem to work better on some housecodes than others, that's probably due to noise. Since X10 signals are very prone to noise interference, and the sequence of "pulses" is different from one housecode to another, the noise could interfere with it differently.

[JGM]

I haven't tried lamp timers but have noticed like inconsistancies with an appliance module (it is a three prong pro module with AGC, forget the model #) hooked to a coffee pot.  For the most part the timer works but occasionally it either partially disconnects power (the light on the coffee pot goes dim) or it doesn't turn off at all.  Turning on via timer doesn't seem to be a problem.  I did tell tell the timer to use repeat commands but doesn't seem to resolve the problem.  I'll try the macro route too.  Thanks all.

[ShowLowPhil]

Hi there,

I haven't been around for a while so I just re-registered. I have been using X10 (Prev Radio Shack) products for approx the last 30 years.

I just updated to AHP 3.318 because I was having some strange results with my timers for my outdoor house lights. Well, the good news is that the outdoor lights now work as they should. The bad news is that my old Radio Shack plug-in lamp modules (61-2682B) no longer turn ON with the timer or all lights on. They do however turn OFF with "all lights off". I read this topic and switched the plug-in definition to the older type (no soft start) plug-in and it did not turn ON. I also defined it as some of the other (no soft start) switches and it still does not turn ON.

Just a little more FYI my X10 LM465 lamp plug-in module works which is how I had it defined before the update to AHP 3.318 (which appears to be the latest).

Has anybody out there been able to turn the Radio Shack 61-2682 lamp plugging modules to work with timers or "All Lights on"?

[Dan Lawrence]

AHP will use a Radio Shack 61-2682 lamp module just use the Lamp Module in Older Lamps (NO Soft Start) in 3.318 to define it.   

[Noam]

AHP will use a Radio Shack 61-2682 lamp module just use the Lamp Module in Older Lamps (NO Soft Start) in 3.318 to define it.   

Check your AHP, and make sure that there are no other modules on the same housecode/unitcode that are still defined using the "lamps" category instead of the "old lamps - no soft start" category. From my testing, mixing module types on the same housecode/unitcode can confuse AHP, and cause it to only send the newer Extended commands (for the SoftStart devices).

You should also try the RadioShack modules in outlets where other modules are KNOWN to be working. you could have a marginal signal, and it is having trouble getting through to some of the modules.