Elk M1 -> RS232 -> Lutron Illuminations: Newbie questions

[cowger]

Hi,

After 11 years, my old Lutron HWI system bit the dust and I recently had a new Illuminations processor installed. Since the new Lutron processor has Ethernet built-in, it has freed up an RS232 port which I'd now like to connect to my Elk M1. The purpose is to have the Elk send serial strings to a phantom keypad in Lutron and thus have lighting respond to specific security events.

I've read through the Elk manual again, and while it references the ability to use RS232 to control lighting and other peripherals, it doesn't seem to have much as to how this is accomplished. I've also searched this forum, and again, while there are references to doing this, I'm just not getting it as to how to accomplish this.

So, I submit two (admittedly very basic) Elk M1 questions:

Q1: Which port on the M1 do I use to output commands? Is there more than one choice?

Q2: How do I program the M1 to send a specific ASCII string? I have the latest ElkRP2 software installed and running, but it's not apparent to me where one would define the command strings.

FWIW, I do understand the format of the commands that Lutron is looking for, as I got an iRule setup working previously. I just need to figure out how to send a simple ASCII string out an Elk M1 serial port under programmatic command.

Help, Mr. Wizard!!

Thanks,
Bryan

 

[tmbrown97]

This is pretty easy, just not entirely intuitive.

The first thing you need to do is create custom Text Strings which contain the strings to send to the controller. I think you need to terminate with ^M but you'll have to test that a little bit.

Once you have the strings built, you'll create a rule or task to send that string out the com port. The Com Port number is dependent on the order they're addressed on the bus - the built-in port that the XEP connects to is the first one, then they increment in the order of their address.

I'm on the wrong computer for ElkRP (a Mac) but I have some rules to communicate with my thermostats and it works great.

 

[cowger]

This is pretty easy, just not entirely intuitive.

The first thing you need to do is create custom Text Strings which contain the strings to send to the controller. I think you need to terminate with ^M but you'll have to test that a little bit.

Once you have the strings built, you'll create a rule or task to send that string out the com port. The Com Port number is dependent on the order they're addressed on the bus - the built-in port that the XEP connects to is the first one, then they increment in the order of their address.

I'm on the wrong computer for ElkRP (a Mac) but I have some rules to communicate with my thermostats and it works great.

Ah-so -- thank you so much! This does make sense now but I doubt I would have stumbled into this without the pointers. I'll play around with this and let you know if I have any further questions.

Greatly appreciated!
Bryan

 

[tmbrown97]

It may take a little trial & error - but if you get stuck I can copy/paste some rules and look up the details a little closer.

 

[cowger]

It may take a little trial & error - but if you get stuck I can copy/paste some rules and look up the details a little closer.

Thanks, I will definitely keep your offer in mind.

Here's a sample command that Lutron is looking for, which seems pretty straight-forward to implement as an Elk text string:

KBP, [01:01:06], 02 (with a carriage return, 0xd, immediately after the 2)

followed by:

KBR, [01:01:06], 02 (carriage return)

This pair equates to a "keypad button press and then release" event to Lutron, and sending these strings has worked just fine for that previous project. I do agree that it can be tricky, but worst case I can just haul home a 'scope from work and watch the 0s and 1s on the link to see what's going on...

I like how the Elk SW apparently allows you to insert all the appropriate control characters in there. Should (hopefully) be a piece of cake. Just need to get my serial expander installed, set up baud rates, etc., and then go to town. Fingers crossed...

Thanks again for the help!
Bryan

 

[cowger]

I'm on the wrong computer for ElkRP (a Mac) but I have some rules to communicate with my thermostats and it works great.

BTW, what thermostats are you using? That's my next upgrade...

 

[tmbrown97]

I'm on my phone so it's a PITA to find my blog entry but I have a multi-zone setup using RCS' communicating zone controller. I think it's the best possible way to do a multi-zone setup but unfortunately it seems they discontinued the product recently.

So - if I had to do it again tomorrow, I would go with an HAI Omnistat2. I used a regular Omnistat in my last house and it worked great. The omnistat2 is newer and much better looking.

While we're at it, another useful addition was the W800RF32 - it lets you receive the signal from the super-cheap x10rf remotes into your system for HA use. I use it to interact with my UPB switches but there's no reason you couldn't translate to your lighting system or other things connected to your system.

 

[cowger]

This is pretty easy, just not entirely intuitive.

The first thing you need to do is create custom Text Strings which contain the strings to send to the controller. I think you need to terminate with ^M but you'll have to test that a little bit.

Once you have the strings built, you'll create a rule or task to send that string out the com port. The Com Port number is dependent on the order they're addressed on the bus - the built-in port that the XEP connects to is the first one, then they increment in the order of their address.

Well, months later, I finally got some time to get a Serial Expander added to my system today and get it interfacing to my Lutron system. As Work2Play points out, it took a little trial and error but I eventually got it working. Now I can control any light or load in the house based on alarm system events. :rockon:

For anyone who stumbles into this thread at a later date, I want to correct something I said in a previous post: The KBR (keypad release) event I listed is not needed. Just KBP works fine. Set up a phantom keypad and go to town...

One question, though: How is the baud rate set on the M1XSP? I know the simple answer would seem to be via jumpers S1,S2, and S3; I have those set to 1,1,1, which I think should select a baud rate of 38,400, but the unit is definitely running at 9,600. This was the trial and error part for me... after hooking up a simple terminal program to the output of the serial port and seeing gibberish, I played around with the baud rate and found that 9,600 worked. After adjusting Lutron down to 9,600, things are working fine, and I might just leave it at that speed (not a lot of data going back and forth, after all), but I would like to know what I'm doing wrong to not get the 38,400 I was looking for...

Thanks,
Bryan

 

[drvnbysound]

Well, months later, I finally got some time to get a Serial Expander added to my system today and get it interfacing to my Lutron system. As Work2Play points out, it took a little trial and error but I eventually got it working. Now I can control any light or load in the house based on alarm system events. :rockon:

For anyone who stumbles into this thread at a later date, I want to correct something I said in a previous post: The KBR (keypad release) event I listed is not needed. Just KBP works fine. Set up a phantom keypad and go to town...

One question, though: How is the baud rate set on the M1XSP? I know the simple answer would seem to be via jumpers S1,S2, and S3; I have those set to 1,1,1, which I think should select a baud rate of 38,400, but the unit is definitely running at 9,600. This was the trial and error part for me... after hooking up a simple terminal program to the output of the serial port and seeing gibberish, I played around with the baud rate and found that 9,600 worked. After adjusting Lutron down to 9,600, things are working fine, and I might just leave it at that speed (not a lot of data going back and forth, after all), but I would like to know what I'm doing wrong to not get the 38,400 I was looking for...

Thanks,
Bryan

I just pulled the XSP manual to double check and what you have should correct. 9600 should be set if you were using 1,0,1. Using 1,1,1 should have it set to 38,400... no idea why that wouldn't be working for you. I'm assuming you've tried it, but the only thing that I could think is that you may have to cycle power on the board to allow the baud rate to reset (??)...

 

[cowger]

Thanks, drvnbysound. I did try power cycling, but it's hard on 9600. It works, so oh well. On to the next challenge...

So I have comms working from Elk -> Lutron; now I'm trying to get the reverse to work. I've programmed the Lutron system to send the text string "armstay" to the Elk, and by plugging a terminal program into the output of Lutron, I see this:

(The KBP command is what I'm using to induce Lutron to send that string, along with a LF and CR.)

And here's the rule in ElkRP2:

Obviously it's not doing anything useful yet; just trying to debug. I have a multimeter monitoring Output7, which is how I'm trying to tell if Elk is receiving anything. Note that Lutron is sending Elk everything you see on the screen, meaning it's getting a lot of traffic from the Lutron system, but I'm assuming / hoping it can parse through that, discard everything else, and find the "armstay" string correctly.

But as you can probably guess by now, I'm not seeing Output 7 go high. Couple questions:

1) What's the exact format I should be sending to Elk? CR? LF?
2) What kind of flow control is used by the XSP? Is this part of the mode selection jumpers? If this is documented in the XSP manual, I can't seem to find it...

Any ideas why Elk isn't happy about what Lutron is sending?

Thanks!
Bryan

 

[cowger]

Update1: I also tried sending the string "armstay" directly from the terminal emulator into Elk. Nuttin'. I can get Elk to output to the screen of the emulator, but it simply won't respond to anything I send in.

Update2: I see in the software that the input string must end with CR. I have the box checked "terminate with CR" in the terminal emulator program, and it seems to be doing that. Still scratching my head...

 

[cowger]

Another update: In scouring through the XSP manual again this morning, I noticed one little line at the top of the table on the last page, which essentially states: "To use the M1XSP as a Serial Port Expander, set the MODE jumpers to 1,0,0,0 (S5...S8) and then set BAUD jumpers according to the desired speed." I never noticed this before, and instead had been setting the MODE jumpers for a Lutron RA, or 0,1,1,0. This is where I suspect I'm screwing things up.

1) Based on this, I'm guessing the MODE jumpers are overriding the BAUD jumpers and setting the baud rate to 9,600, which is what they think Lutron wants.
2) Also based on this, perhaps the XSP firmware is expecting something that's defined in the Lutron command set and therefore is ignoring my custom command string.

Since all I really want here is for this thing to operate as a Serial Port Expander, I should have configured it as such all along. I'll give this a shot when I get home tonight...

 

[cowger]

Success! Finally....

For anyone who hasn't blocked / unfollowed / auto-ignored this thread, here's what I learned:

1) The XSP MODE jumpers definitely override BAUD rate selection.
2) When in a selected mode, e.g. Lutron RA, the XSP will function as a general purpose Transmitter but NOT a general purpose Receiver.
3) When the Elk RP2 software tells you that "Received text must end with a Carriage Return", they mean that the string that you define must end with a CR *and* the incoming serial ASCII stream must also be followed by a CR.

A couple comments:

Regarding 2) above, I don't know why they disable the receipt of unexpected text strings, but perhaps it's just to reduce the chances of noise or unintentional traffic messing up the M1G.

Regarding 3) above, I did try to define the text string both ways during my previous days of debug, but apparently the interaction with 2) kept this from working.

So, there you have it. Perhaps obvious to you, but maybe my slow learning curve hopefully provided some entertainment. And hopefully this could be useful to someone coming across this in the future who is trying to foster happy chatting between these two types of systems. If you do, feel free to drop me a note at bryan_cowger at yahoo

Cheers,
Bryan