Print

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

[x10newbie]

I'm running AHP (v. 3.206) and have a simple macro that turns ON/OFF an appliance module (ELK-9100) if a certain flag is set.  The module responds when the macro is run from the PC but not when the same macro is run from the "interface".

Observations:

• Signals are definitely being sent even when run from the "interface" (the Activity Monitor says the right things are going out and I can see the module detect signals with its flashing LEDs, but it just ignores them when they are sent from the "white box".  I can hear it thinking,  "Not meant for me..."  (I tried a delay and multiple sends in the macro -- no luck with those).
• The misbehaviour occurs when the macro is triggered by X10 signal or by timer but works fine when you click on the "run macro" button even when "stored on interface".
• The results are always the same -- consistently reproducible.

I've been trying to get help on this for the past 2 days.  ELK's technician picked up my call after 1 ring yesterday and cut right to the chase as he knew of this issue.  He claims that the CM15A sends a couple of trailing bits to the X10 commands and that they proved this for themselves with some kind of line sniffer.  So they think that their module is doing the right thing -- ignoring the malformed X10 command.  My X10 lamp module eats these codes up fine, though.  Chomp, chomp.

X10 support hasn't wanted to make any meaningful contact with me yet (they seem to use email as a customer defense tool!).  Two days in and they have requested a data file only tonight.  Seems like this might take a while, so I thought I'd write in to this list with this bug report.

Hope someone has experienced this or has ideas on how to move forward -- can anyone do a protocol check to confirm/disprove these allegations?  I guess I could work around it with other modules, but if this is truly a bug in the basic control signal format, I would think that this gets noticed and fixed (haven't seen other complaints specific to these symptoms, though).

Thanks for your time (and to X10 for hosting this forum!)

-x10newbie   

[JMac]

I only have x10 (+ a couple of old Radio Shack ones), and insteon modules and have never had this problem.  Are you sure the Elk appliance modules are compatible ?

[x10newbie]

>> Are you sure the Elk appliance modules are compatible ?

They both are claiming conformance to the X10 standard.  The answer should be "yes".  I'm not 100% sure if the sender (CM15A) or the receiver (ELK) has veered off course here.  The fact that the ELK responds differently to the same macro (we're talking a single ON / OFF command here) when run on the CM15A, tells me that the signal is different when there is no logical reason for it to be.  I'm thinking bugginess in the CM15A...

[Noam]

1. You mentioned a conditional macro.
Conditions don't run when you run the macro from the PC.
It ignores the conditions, and just runs the commands.

2. Have you tried setting an X10 appliance module to the same address to see if it responds to the macro?

I don't know if this helps troubleshoot your issue at all.
--Noam

[x10newbie]

>> Conditions don't run when you run the macro from the PC.

I see conditions run from the PC if triggered via timer or by calling the macro's address.  If you simply hit the "run macro" button, then conditions are ignored (also, that button runs the macro from the PC even if it is told to run from "interface" -- so it seems from my tests).  Note that I removed the conditions to simplify testing and get the same behaviour.

>> Have you tried setting an X10 appliance module to the same address to see if it responds to the macro?

I have a "soft" module and it responds to the commands just fine.  I also can control other "real" modules from the X10 company.  ELK is just more sensitive... and perhaps, rightly so.