Onq ALC lighting: CQC or Elk control?

AceCannon

Active Member
Beelzerob is writing a CQC driver for OnQ ALC lighting and has described all these cool ramp rates, features of the protocol. I am wondering if I should plan on using Elk or CQC to control my planned ALC switches.

I know CQC can control the lighting through the Elk driver, but I dunno if the control will be as robust as it would be directly from CQC.

Then again, there is the complication of how to control the lights based on Elk rules (motion, etc) if the switches are controlled via a CQC driver instead of from the Elk board.
 
The upside about using CQC is that it's much easier to evolve/upgrade a software based driver than a hardware based one. I also personally find it easier to use the CQC automation engine versus the Elk one. Point & Click, GUI, and all that stuff.

I do motion-based control using Elk hardware via CQC all the time, piece of pie.
 
The downside is that your light automation (based on events) now relies on a software package rather than a hardware controller.

I checked with SETNET and it's not really possible to have 2 controllers you have to pick one way or the other.

Considering Beelzerob's driver is not completed yet i am planning to go the ALC<>ELK<>CQC route for the time being.

SETNET did tell me you can control ALC with the ELK through the ALC serial interface rather then the specialized ELK<>ALC module, but i suppose this requires a Elk serial expanded plus a serial ALC controller instead of a ELK/ALC controller that sits directly on the RS475 bus.

I'll probably get the direct interface and may consider changing it over at a later time.

Does anybody know if ELK provides full control (ramp ratesa and all that good stuff) for ALC? Would the CQC driver provide any benefits (other than easier programming) above the ELK interface?
 
...
Does anybody know if ELK provides full control (ramp rates and all that good stuff) for ALC? ...

I believe all HA apps with an ELK M1 driver use the M1's Serial Protocol. This specification provides basic control, on/off/brightness, of all lighting protocols handled by the M1.

If your HA app has a protocol-specific driver, such as for OnQ ALC, then there's a good chance it supports more advanced functions.
 
Considering Beelzerob's driver is not completed yet i am planning to go the ALC<>ELK<>CQC route for the time being.

I've made considerable progress since I made it my #1 priority. I could see it being given to Dean by this weekend. I've got almost all the functionality I want, and I'm almost adding just fun stuff now.
 
I dont understand Setnet saying you cant use two controllers. I use On-Q HMS (HAI) hardware AND Mainlobby. Works perfectly together. All the programming is pretty much handled by the hardware. I use software side to exectute buttons.

Maybe it was not understood properly? In addition, you can use PC Access which is a software and of course the panel itself, hardware. So right there are two controllers: software running hardware.
 
I dont understand Setnet saying you cant use two controllers. I use On-Q HMS (HAI) hardware AND Mainlobby. Works perfectly together. All the programming is pretty much handled by the hardware. I use software side to exectute buttons.

Maybe it was not understood properly? In addition, you can use PC Access which is a software and of course the panel itself, hardware. So right there are two controllers: software running hardware.

I think the original question was if you could use the serial controller required for interaction with the Elk, AND the serial controller required for interaction with a PC, at the same time, and I think the answer to that was no, since I believe those are 2 different controllers, and there's only one interface port on the OnQ board, correct?
 
beez, there are one to 5 serial and up to one ethernet depending on which panel you have . I think thats what you asking?

as far as using more than one serial, i still dont see why you cant. I use several and one talks to Mainlobby. Maybe I am just confused on what someone wants to know, LOL.

I stand behind my stating you CAN use a panel to control ALC as well as a serial or ethernet connection to control it via another controller, ie software. Now can you do that with elk? Dont know, i use on-q/hai.
 
The question is whether the same serial port can be used for multiple things, and that is not possible.

I dunno about devices that have multiple serial ports, or a serial & an ethernet port as i've never had one.
 
Well, looking at the controller, it has an "expansion" bracket, which is what my serial controller card plugs into. Now, that serial card ALSO has an expansion bracket, so that in theory more things could be daisy-chain plugged into expansion. I assume for elk control, there is a special serial controller card? I thought I'd seen that but I can't find it online right now.

But for the sake of arguement, let's say I plugged another serial controller card into the expansion port on my existing serial controller card...so there would be 2 serial connections to the OnQ controller, and thus you could potentially plug in 2 different PC's if you wanted. The question is....will the OnQ controller talk to 2 separate serial controller cards and have no problems?
 
Well, looking at the controller, it has an "expansion" bracket, which is what my serial controller card plugs into. Now, that serial card ALSO has an expansion bracket, so that in theory more things could be daisy-chain plugged into expansion. I assume for elk control, there is a special serial controller card? I thought I'd seen that but I can't find it online right now.

But for the sake of arguement, let's say I plugged another serial controller card into the expansion port on my existing serial controller card...so there would be 2 serial connections to the OnQ controller, and thus you could potentially plug in 2 different PC's if you wanted. The question is....will the OnQ controller talk to 2 separate serial controller cards and have no problems?

They guy may have just misunderstood the question or something. As long as it won't get confused by two automation systems talking to it separately (and provides the physical means to do so), then it shouldn't be problem. Or maybe he meant it in a more generic sense that having multiple automation systems connected to it might cause conflicting demands from them or something like that.
 
Back
Top