Print

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

[GeneMar]

I'm just installing a new AHP and I'm seeing something I haven't seen in years of working with X10: When I dim a module to say, 50%, the module dims to 50%. A second after that, it turns off. The Activity Monitor tells the story:

The first two log entries are as expected:
1 10/29/2009 6:43:25 PM Transmit G On (Credenza)
2 10/29/2009 6:43:33 PM Transmit G Dim 50(Credenza)

Then I 'Receive' a third:
3 10/29/2009 6:43:35 PM Receive G Dim 52(Credenza)

This additional DIM turns off the light. It also moves the Slider in the X10 UI from 50% to 0%

If I disconnect my SignaLinc™ Plug-in Coupler-Repeater http://www.smarthome.com/4826B/SignaLinc-3-Pin-Plug-in-Coupler-Repeater/p.aspx everything works fine; that additional Receive is (is being echoed?) does not affect the module like it did when the AHP was plugged in.

The problem is, I have never had this problem with any other X10 home automation system or timer. What is AHP doing when the Repeater is sending this protocol. The problem only happens if both the AHP and the Repeater are both plugged in. Remove either, and all is fine.

If I send these commands from a separate controller, there is no double-dim, the AHP just hears the Receives it's getting and adjusts the slider in the UI. The problem is only when the commands are sent from the AHP, it hears itself and is confused.

This is a show-stopper, but I can't be the first with this problem... Any suggestions?

Gene

[Brian H]

So basically the G Dim 50 when the repeater sends it back on the line AHP is reacting to the received Dim?
Are the modules in question soft start?
Is the dim instructions being sent. In a macro or timer?
If modules are soft start. What are they defined as in AHP?

There where Signal Firestorms reported with CM15A conrollers and some repeaters. I believe the Smarthome was one of them and the Leviton HCA02 was another. On my Act CR134 unit. I set the options to do not repeat a known repeated signals. I now has an XTB-IIR. Though my main system is Insteon with X10 Addresses added to the modules. With X10 modules where needed.

[GeneMar]

So basically the G Dim 50 when the repeater sends it back on the line AHP is reacting to the received Dim?

Yes, the graphical slider moves from the 50% I left it at to 0%!
BUT, even worse, the lamp reacts too and I'm not seeing how that could be without the AHP sending something else out, too. If I remove the AHP, the problem goes away. If I remove the SignaLinc Repeater, the problem goes away. With other controllers (and no AHP) the problem does not happen.

Are the modules in question soft start?

This is happening to all my lamp modules, soft-start and non-soft-start.

My soft-starts are 'HomePro HPD3/HPSS' and can be found as SmartHome Item# 2208ACWI or HomePro Product No.: AS001
However, the basic plug-in-the-wall lamp modules fail the same way.

Is the dim instructions being sent. In a macro or timer?

My timers didn't appear to be firing (they were, but everytying was full-DIMed off) so I checked it out. Everything else I did at that point was just through the graphical UI - on, off, dim sliders in the UI.

If modules are soft start. What are they defined as in AHP?

While it fails on all modules, I did pick one and selected every possible module type for that lamp module. No change.

Appreciate the help...
Gene

[Brian H]

Thanks for the added information.
It should help in finding an answer.

[Boiler]

Hello Gene,

I think you're correct that this isn't the first time this has come up.  When I've seen it previously, it was related to %dim commands.  Direct dim commands and extended code commands (LM14a) were not affected.  I have not kept up with the different versions of AHP (I'm still at 3.204).  It's possible something has changed.

Here's a previous thread for your perusal: Dimming & brightening Commands From Software.  See if it matches up with your symptoms.

Boiler

[GeneMar]

Yes that does sound very close. And I will admit that %Dim appears to be anew protocol in my world. With other controller projects, I would issue DIM() command repeatedly until things were where I wanted them.

I am also working with a X10 Power Line Signal Analyzer X10 Power Line Signal Analyzer http://www.smarthomeusa.com/ShopByManufacturer/Monterey-Instruments/Item/PLSA/ and was surprised to see just one Dim packet come across, and not a series of GDM packets.

So, is there any way for me to configure AHP to not use %Dim commands, but ... relative(?) dim commands?

[Boiler]

Gene,

I used some bad terminology in my original post.  Have a close look at the link I provided.

The problems that were documented were related to the use of "relative dim" commands combined with a HCA02 repeater.  "Absolute dim" commands appeared to work properly.  Note that when you use the dim slider on the AHP Icons you are effectively using "relative dim" commands.

I'm not very well versed on the Monterey, but I'm surprised that it's only showing one Dim as well.  Are you using the LM14a interface (extended codes)?

Boiler

[GeneMar]

After another chunk of hours trying to get this to work, I am finding no difference between Relative and Absolute settings from within a Macro. I've settled on ensuring ON is issued in macros instead of Bright(100%), and then I DIM half the amount I really want, knowing that the feedback is going to double it. I also had to add a 2-second delay before each X-10 transmission. Now, the AHP is delivering some benefit, but this is has been a painful experience.

I feel AHP can become more robust in this area: Perhaps a 'repeater is present' attribute can be configured into the device such that it can wait a bit for repeated commands (so I don't have to remember to include a wait before each command), and perhaps ignore received commands less than a second from transmitting the same-exact-command!

[Noam]

I didn't see this listed in this thread (but I may have missed it), but are you trying to dim the lights from within the AHP interface, from a timer (in AHP), or from a wired or wireless remote?

I can see if you are using a remote, and have a TM751 or RR501 plugged in, that they would ALSO receive that command, and transmit it to the powerline.

I suppose it is also possible that AHP is sending an RF signal, which is being picked up by one of those, and coming back a second time.

--Noam

[GeneMar]

... are you trying to dim the lights from within the AHP interface, from a timer (in AHP), or from a wired or wireless remote?

• The AHP Interface (though that's just for fun)
• A Daily Timer (That, like the UI doesn't work as it uses absolute/relative DIMs (don't recall)
• A Macro (As a workaround, it was suggested I make a Macro for everything to use absolute).

All three methods respond to the Received feedback the AHP Sees as the result of the SignaLinc being present.
Not using any remote, just trying to turn on a light at 50% when it's dark!

There are no RF packets displayed in the monitor window, but that was my first suspicion as well, so I turned off trans coding(?) of all house codes - no affect.

[Noam]

Are the lamp and the macro on the same housecode/unitcode?
If not, is there anything else on the same Housecode/unitcode as either one of them?

--Noam

[GeneMar]

Are the lamp and the macro on the same housecode/unitcode?

No. Modules are on the 'G' house code, all my Macros are on the 'A' house code.

If not, is there anything else on the same Housecode/unitcode as either one of them?

All the macros are triggered via non-existent address on A, all the physical modules that control lights are on G. Nothing is doubled-up. Like stated earlier: Remove the AHP and any other controller works fine. Remove the SignaLinc and AHP works fine.

[Rocket J Squirrel]

I have this issue, too. I just work around it by specifying half as much dimming as I actually want.

[JeffVolp]

I feel AHP can become more robust in this area: Perhaps a 'repeater is present' attribute can be configured into the device such that it can wait a bit for repeated commands (so I don't have to remember to include a wait before each command), and perhaps ignore received commands less than a second from transmitting the same-exact-command!

Actually, it is not necessary to wait for a repeated command.  Normal X10 commands are transmitted as two identical halves for redundancy.  The receiving module only has to receive one half to respond to the command.  Repeaters take advantage of this by receiving the first half of the command, and then retransmitting that in bit sync with the second half.  So, the repeater should finish its transmission at exactly the same time as the original transmission.

Modules near the transmitter will receive the first half directly from the transmitter, and the combined second half from both the transmitter and the repeater.  Modules located a long distance from the transmitter may only receive the second half sent by the repeater.

Jeff

[GeneMar]

I agree, this protocol and the repeating, should all be within one packet. That's why I'm surprised this AHP is not working, and explains that (whatever its failure) I have not experienced this with any other controller.  The delay was a last-ditch hail-mary that worked!  I would turn on a phantom module to turn on a module on another housecode:

Press on any house controller:
G 15
G ON

The AHP sees this and the macro then sends:
M 1
M ON (To turn on that other device)
G 15
G OFF (to clear the signal on the phantom device)

These commands play out like this just fine in the Monitor window, but the M1 would never actually turn on! I added a 2-second delay at the start of the macro and all works reliably.  I have no idea why.