ALC ELK question

jmark71

Active Member
Hi Guys,

This weekend I plan to finally start down the rabbit hole with CQC. Initially, I'll be working on getting my ELK M1 up and going along with the ALC stuff I've put in so far. I have the ELK<>ALC interface that currently connects to the ELK, but I'm beginning to think that I want to control the lighting completely from CQC, so that prompts the following questions:

If I run the ELK<>ALC interface in standalone mode, how do I make the serial connection from the PC to the ALC interface? I see an RJ45 Serial connection on the board, but I have no idea whether that's the way to do the connection, or what the pinout connections would be. If I don't connect through this RJ45 port, I presume I'll need to add an ALC Serial Expansion board to the setup?

One other question... snice I'll be running the ELK<>ALC interface in standalone mode, I'll need to power it seperately... since I acquired the board without the power supply, can someone tell me what specs I need to be looking at in another supply?

Thanks in advance,
Mark
 
I don't think you can run the ALC->Elk interface in "standby" mode. It is a specially designed peice of hardware that combines the ALC master controller with the Elk interface unit. In order to use the ALC system with CQC, you need a regular control module and a serial expansion card.

The ALC Elk controller is a special board that combines all those features into on unit. It makes it very handy, but you really have to decide from the beginning what route you want to take. Although I do believe you can use the regular ALC control module, a regular ALC serial expansion card combined with the ELK M1XSP serial expander. So if you start out with the regular ALC hardware, you can simply add a ELK-M1XSP to make it work with ELK. But I don't believe you can start with the ALC ELK control unit and utilize it with something other than ELK.
 
I don't think you can run the ALC->Elk interface in "standby" mode. It is a specially designed peice of hardware that combines the ALC master controller with the Elk interface unit. In order to use the ALC system with CQC, you need a regular control module and a serial expansion card.

The ALC Elk controller is a special board that combines all those features into on unit. It makes it very handy, but you really have to decide from the beginning what route you want to take. Although I do believe you can use the regular ALC control module, a regular ALC serial expansion card combined with the ELK M1XSP serial expander. So if you start out with the regular ALC hardware, you can simply add a ELK-M1XSP to make it work with ELK. But I don't believe you can start with the ALC ELK control unit and utilize it with something other than ELK.
Hmmm... well, I bought the ELK<>ALC unit from a CT member along with a bunch of switches so wasn't really aware of what you're saying (the interface board was really an 'impulse' buy at the price anyway), but I'm not sure that what you're saying is accurate. I seem to remember that AceCannon had an Elk<>ALC interface setup in a standalone mode - I've found his build thread on AVS, but can't find where I thought I read that... the picture he had on there of his ALC boards is missing now (AceCannon build)...

Ah... found the picture... it's actually on here... post #7. I'll follow up with AceCannon and ask him. Thanks!
 
Hmmm... well, I bought the ELK<>ALC unit from a CT member along with a bunch of switches so wasn't really aware of what you're saying (the interface board was really an 'impulse' buy at the price anyway), but I'm not sure that what you're saying is accurate. I seem to remember that AceCannon had an Elk<>ALC interface setup in a standalone mode - I've found his build thread on AVS, but can't find where I thought I read that... the picture he had on there of his ALC boards is missing now (AceCannon build)...

Ah... found the picture... it's actually on here... post #7. I'll follow up with AceCannon and ask him. Thanks!

Yeah, I was running the ALC<>Elk interface in standalone mode. Like really ALONE. No Elk attached or PC. I believe Sic is correct, you cannot interface a regular serial device to the ALC<>Elk board. The only comm provided is via the Elk RS485 bus. The rj45 jack on the board is to communicate with a distribution hub, as in the picture of mine you linked. (The Elk connection is of course not pictured. Since that pic, I have actually made the Elk connection and it works just fine. More pics need to be taken!)
 
Yeah, I was running the ALC<>Elk interface in standalone mode. Like really ALONE. No Elk attached or PC. I believe Sic is correct, you cannot interface a regular serial device to the ALC<>Elk board. The only comm provided is via the Elk RS485 bus. The rj45 jack on the board is to communicate with a distribution hub, as in the picture of mine you linked. (The Elk connection is of course not pictured. Since that pic, I have actually made the Elk connection and it works just fine. More pics need to be taken!)

Ah, okay... now that makes sense, although there is an extension connector on the ELK/ALC board - maybe that can connect to an OnQ ALC Serial board and then on to the PC? Won't hurt to buy the serial board b/c it sounds like if I have to go down the route of CQC controlling the lighting rather than the ELK, I'll have to purchase it anyway. I can try this approach first and then if it doesn't work, pick up the regular ALC controller.

One question though Ace... what were the specs on the power supply you used on the ALC<>Elk interface? I bought the board from someone and the PS wasn't included.

Thanks,
Mark
 
You can still control your ALC lights from CQC going through the M1's serial or ethernet port.
 
Note that if you want to control the ALC with CQC going through the Elk, you'll be using the Elk CQC driver, not the ALC CQC driver.
 
I realize I can use the Elk Driver, but isn't there a downside to doing it that way? I thought I read somewhere that there was more flexibility in using the direct CQC ALC driver than using the Elk driver? Is this not the case?
 
Someone on in these forums dabbled in that, I can't remember who...might have been Brian. I think one of his main issues with control through the Elk was that sending commands to change multiple lights all at once ended up causing issues. That's about all I remember...I know it's buried in a thread somewhere here at cocoontech. The ALC threads tend to get lengthy and packed full of various discussions.
 
Someone on in these forums dabbled in that, I can't remember who...might have been Brian. I think one of his main issues with control through the Elk was that sending commands to change multiple lights all at once ended up causing issues. That's about all I remember...I know it's buried in a thread somewhere here at cocoontech. The ALC threads tend to get lengthy and packed full of various discussions.
Yup, I think that's what I remembered reading which is why I was going to seperate ALC from the ELK. I don't think I'm losing much by going this route and it seems from all accounts that you have created a pretty solid driver for ALC in CQC so thanks in advance for that!!!
 
One reason I chose to use the Elk<>ALC method is automation. The Elk is a piece of hardware that is not likely to go down. The M1 control can save rules that control my tstats and lights. It feels more bullet-proof. Second, I deployed the Elk before I got CQC up and running, the rationale being we needed the security system as a priority. Third, I know CQC can send commands based on events, but it hasn't been easy for me to learn how to do it. The Elk's rule-based programming has been very easy to implement. (I'm sure CQC will be also, when I can get the time to learn).

BUT, I don't think the Elk driver for CQC includes the advanced functions like exended ramp rates. Also, as noted above, there may some issues with sending several simultaneous lighting commands from CQC via Elk to ALC. I have not (as of yet) tested this. So far, I can load up the Java applet for the M1XEP and control lights one at a time without any problems. Works every time.
 
Back
Top