How should I control lights with CQC / Elk

Sacedog

Active Member
I was planning on installing OnQ ALC lighting in my new house, and have the lighting controlled by the Elk M1. Over the past few days, I have been going through the CQC tutorials, and it dawned on me during the triggered events tutorial...can CQC control the lighting through the Elk system, by use of the CQC Elk driver? The same question could be asked for any other automation software out there too, such as ML.

I am planning on a total of 104 light switches, to be controlled through HA. If CQC (or ML) can't control them through the Elk driver, will there be enough rule space in the Elk for performing automation on all of these switches?

All of the sudden, I am wondering if I should be going with UPB Gen II instead of ALC. I know it's not hardwired, but will it give me more flexibility? I haven't bought my ALC switches yet, and want to make sure of my decision before I plop down the $7,500!

All opinions are welcome!
 
I was planning on installing OnQ ALC lighting in my new house, and have the lighting controlled by the Elk M1. Over the past few days, I have been going through the CQC tutorials, and it dawned on me during the triggered events tutorial...can CQC control the lighting through the Elk system, by use of the CQC Elk driver? The same question could be asked for any other automation software out there too, such as ML.

I am planning on a total of 104 light switches, to be controlled through HA. If CQC (or ML) can't control them through the Elk driver, will there be enough rule space in the Elk for performing automation on all of these switches?

All of the sudden, I am wondering if I should be going with UPB Gen II instead of ALC. I know it's not hardwired, but will it give me more flexibility? I haven't bought my ALC switches yet, and want to make sure of my decision before I plop down the $7,500!

All opinions are welcome!

CQC should be able to control them via the Elk, but hopefully someone who has actually done it can state this definiteily or not. But the CQC to Elk driver does provide access to control over lights under the Elk's control.
 
If the ELK M1 can control the lighting system, then MainLobby (and very likely CQC) can control and see status updates (if the lighting hardware supports that) via the HA / ELK integration link.

For many lighting control systems, both ML and CQC also can control those system natively. If a software driver was written to do that. There are pros / cons with both approaches.
 
There exists the real possibility of a (non-Elk) CQC driver for OnQ lighting within the next months.....

Wait, I've already said too much.... :)
 
Well, it looks like Main Lobby and CQC can control the ALC switches through their Elk drivers. Does anyone out there have any experience with a large number of switches being controlled by the Elk? I have read in many threads that the Elk does not have a very large memory space for storing rules.

I like the idea of a direct driver, Rob. :)
 
I would stick with your plans for ALC. There is no substitute for hardwire if can can do it. You can always add UPB at anytime if you needed to later and have a hybrid system. Personally I like the Elk controlling the lighting, I consider that more mission critical and left to a dedicated controller. You can always use CQC as a backup. The rule space all depends on what you do. You can have 500 switches but only 5 rules - it all depends on how granular you get and how you do it.
 
FWIW, just because the lights are under Elks' control doesn't mean that's where the rules have to go. I'm moving the aprilaire to the Elk, so I can have 1 less RS232 port, but the rules will still be in CQC.
 
FWIW, just because the lights are under Elks' control doesn't mean that's where the rules have to go. I'm moving the aprilaire to the Elk, so I can have 1 less RS232 port, but the rules will still be in CQC.

That makes sense. My cold feet are getting warmer now. :)
 
OnQ ALC has a single board interface for the M1's RS-485 data bus. It is generally not listed in their product line catalog, but it does exist. It simplifies the interface between the M1 and ALC lighting.
 
FWIW, just because the lights are under Elks' control doesn't mean that's where the rules have to go. I'm moving the aprilaire to the Elk, so I can have 1 less RS232 port, but the rules will still be in CQC.

That makes sense. My cold feet are getting warmer now. :)
That's absolutely true, but it still kind of defeats the purposes of having lighting control on the controller (but that horse has already been beaten a bunch of times). The ideal situation (depending on how critical you view your lighting), would be to have the control and rules on both and have backup systems. If Elk fails, CQC takes over and vice-versa.
 
FWIW, just because the lights are under Elks' control doesn't mean that's where the rules have to go. I'm moving the aprilaire to the Elk, so I can have 1 less RS232 port, but the rules will still be in CQC.

That makes sense. My cold feet are getting warmer now. :)
That's absolutely true, but it still kind of defeats the purposes of having lighting control on the controller (but that horse has already been beaten a bunch of times). The ideal situation (depending on how critical you view your lighting), would be to have the control and rules on both and have backup systems. If Elk fails, CQC takes over and vice-versa.

It all depends on the purpose. In my case, the purpose is to reduce the # of direct RS232 connections, so I can get rid of my MOXA 8way PCI serial card. Then, I can seriously look at moving to an XPe or other super-low-power server, maybe i'll even play with SSD drives.

But sure, having identical rules in both systems would work, perhaps with using one of the outputs to toggle between which system to listen to.
 
I like the idea of a direct driver, Rob. :rolleyes:

Well, you can like it even more in about a month, then. If everything goes as planned, I should be producing a basic CQC driver for ALC/OnQ within about a month. I should be getting the hardware in a couple weeks, and if that happens as planned, then another couple weeks to work out the bugs in the initial version.
 
I like the idea of a direct driver, Rob. :rolleyes:

Well, you can like it even more in about a month, then. If everything goes as planned, I should be producing a basic CQC driver for ALC/OnQ within about a month. I should be getting the hardware in a couple weeks, and if that happens as planned, then another couple weeks to work out the bugs in the initial version.

You da man!!!

I have been messing around with CQC for a few weeks, and will be purchasing in Feb, due to the sale. :rolleyes:
 
I would not want to depend on a PC software based solution for anything critical...i know thats has been said before.

If you didnt want fancy rules/scenes then woudl OnQ needs a controller at all or do the switches simply talk to each other?

In any case i can't imagine you would have that many complex rules that you run out of Elk memory space.

I am considering a very similar setup. OnQ for lighting. Elk for security automation, CQC for GUI/Automation.

My thoughts were to put all the basic rules in the Elk for good availability (i travel a look and need the lights to keep working when i'm not home to keep the WAF high). Then any real fancy stuff and rules that need input from devices not under Elk would go under CQC.

Does anybody have a good general overview wiring schematic for OnQ. I understand i need cat5 running along the switches, but not sure how it all comes together at a hub and the relation to a controller.

Do the switches have dimmer built into them? Can you have a switch with multiple buttons to control other light but that has 1 dimmer built in to replace whatever dimmer/switch was there before automation?

The documentation i am finding on OnQ has been pretty unclear to me. Maybe it's mostly geared to installers or something.

Any links to products, wiring methods, etc would be greatly appreciated.

MavRic
 
Back
Top