W800RF32, Elk M1XSP, and ASCII

[TurboSam]

I am familiar with the process for using the W800RF32 and Elk M1 to monitor the "security code" from an X10 DS10A, but I'm unclear as to how regular X10 signals are monitored. Does the Elk also look for an ASCII text string off the W800RF32 (via the M1XSP) in response to an X10 transmitter or is there some other way to trigger the rule? I assume it's an ASCII code, and if so, are they the standard X10 strings or do I need to "read" what each X10 transmitter is sending some way?

Thanks.

 

[electron]

You don't have to do anything special in order to process the regular X10 codes via the W800RF32.

 

[TurboSam]

Got it. Thanks. I originally thought that I needed to have a rule with a text trigger from the W800Fr32's processing of the X10 commands (like the DS10A trigger), but then I realized the trigger was simply the phantom "lighting change" resulting from the RF command.

 

[electron]

Keep in mind if you do use rules to process the X10-RF commands, it will be adding a delay vs matching the X10-RF code with the unit code.

 

[TurboSam]

I think you lost me on that one.

I'm using the W800RF to catch x10 remote signals and (via the Elk) to control UPB lighting. And I certainly have a delay.

Are you saying that I should trigger the rules based on using having the M1G process the X10-RF codes as text and triggering rules that way? Or does the comment about matching apply only if I was trying to contol X10 devices (in which case I think you were saying I should do it directly to the X10 device without the Elk rules)? The wiring in my house is not very receptive to X10, but it likes UPB just fine, so I wanted the reliability of UPB lighting, and the W800 with X10 remotes seemed to be a good way to contol ligting from wherever.... I'm open to (and appreciative of) comments or suggestions.

Thanks.

 

[electron]

There are 2 ways of controlling UPB with X10-RF (I do this myself), but you never have to deal with the 'raw' data (ASCII texts). You either create rules which trigger when the M1 sees a certain X10-RF code, which allows you to do some complex stuff (i.e., 1 click, light ramps to 50%, 2 clicks -> 100%, 3 clicks -> timed off), but it adds a significant delay.

Or, you can make it so the unit code of the device you are trying to control matches the X10-RF code, so no rules are required. It will be a lot quicker, but you won't be able to do anything complex. I got so frustrated with the delay that I moved my W800RF32 back to my PC.

 

[TurboSam]

Sorry, but I'm still in a fog about the second option. I'm doing what SpaceCowboy described in post #19 in your 2005 thread "Elk M1 & W800RF, what a great combo!" (Whenever Lighting (D1) is turned on, then turn on UPB Light (A1)). So when I press the D1-on button to turn on the phantom D1 device, the rule works and UPB A1 goes on...but with the delay.

I can't figure out the second option. I don't see how to make the unit code of the device to be controlled (i.e. the UPB light on A1) match the X10-RF code from the palm pad RF unit. When I press the palm pad's A1-on button, which presumabley sends the A1 X10-RF code to the Elk via the W800, nothing happens and the real UPB device on A1 does not respond (unless I use a rule). I should add that I do not yet have a PSC05 installed if that makes a difference, but I don't see how it would because I am trying to contol a UPB light not an X10 light, and Elk has control of the UPB light via the second XSP and the CIM. (The only other thing I can think of would be to change something about the A1 device in Upstart so it recognized the X10-RF code--if that is even possible.)

Sorry I'm so dense on this....

Thanks again.

 

[electron]

It should work out of the box, unless the unit code of the UPB device doesn't match the palmpad code. You don't need a PSC05, so that's not the problem either. Play with the checkbox options for the UPB device in ElkRP and see if that makes a difference. Maybe one of the latest firmware updates broke something.

 

[TurboSam]

I thought it might be a baud rate issue. The XSP manual says not to set the baud jumpers (S1-S3) for either of the two XSPs since the rate is contolled by the S5-S8 switches, but changing S1-S3 to 4800 did not do anything. Then I thought it might be a baud setting for port 0, but I only proceeded to hose my XEP connection and ElkRP access since the XEP needs 115,600 (live and learn!). I also tried every variation of setting for the A1 UPB light in ElkRP, but none of that worked either. I was too lazy to pull the UPB CIM off of the M1 tonight and put it back on my computer to see the device settings in Upstart (the second CIM is on its way), but I'll look at that tomorrow.

Much as it would be neat to get rid of the delay and have a direct, rule-less X10-RF to UPB connection via the W800, I must admit that I am having a hard time wrapping my head around how the M1 would recognize (and know it was supposed to act on) an X10-RF code without a rule. Wouldn't that mean any (and all) X10-RF codes sent could inadvertently trigger the corresponding devices in the Elk lighting scheme?

 

[electron]

It would indeed do that, that's why you have to be careful planning this. ELK specifically added support for the W800RF32, which is why it should work directly without rules.