Delay between Commands needed for ELK <> ALC?

[felixrosbergen]

Hi Spanky,

I'm planning a reasonable size ALC installation (12 lights in now, another 10 to 15 to go) and am using the OnQ ELK<>ALC interface.

Everything is working quite well, but i'm running into the following issues:

SPEED OF COMMAND EXECUTION
- There is about a 1 sec delay between subsequent liights going on/off when they are part of the same rule. I setup some tets rules with 6 lights and conditions to turn them all on or all off. I can see the progression through the house. About 1 light per second.
- If i put an X in the 'Opt' column to 'Elimate the delay between subsequent lighting commands' not all the lights go on/off. It seems the commands are issued too fast and only some are executed.
- The 1 second delay may sound trivial, but when trying to make smooth lighting scene transitions it doesn't look very good.
- According to the lighting screen the delay should not be needed for lighting commands via M1XSP, which is essentially what i'm doing since the OnQ ELK<>ALC interface is supposed to include those components.

Is the delay changeble so i can set it to something shorter? Also I have not gotten there yet, but i am planning to have some lighting control rule within CQC with CQC telling ELK which lights to turn on/off. Would this still be subject to the same delays?

SETTING LEVEL TO 0
- The ELK lighting rules allow me to turn the light on to xx% value, which for ALC the dimmer create a fairly smooth transition doing so.
- When transition speed is slower/nices when using 'Set to 100%' then 'Turn On'
- Using "Turn Off' is not smooth at all and the problem is that the screens do not allow 'Set to 0%', the lowest value is 1%. This means there no way to turns the lights of smoothly unless i used double the rules space to first set it to 1% and then issue the turn off command. While this could work it's obviously not the most sensible way.
- The interesting thing is that when controller the lights using CQC with CQC giving the commands to ELK to turn the ALC lights on/off the CQC system allow me to 'set to 0'.

It is possible to change something to allow the rules to control the lights by 'Set to 0%' rather then 'turn off'? This would be great. Since It's already possible when CQC issues the command to ELK it seems strange that the ELK cannot do it by itself.

My overall plan is to have basic lighting control rules within the ELK which are all prefixed with a condition checking if CQC is online. If CQC is online then it would control all the lighting by issuing commands to the ELK and none of the ELK lighting rules woudl execute. If CQC is offline then the ELK lighting rules would be functional. I plan to have ELK check if CQC is online by having CQC flip an output every 60 seconds and then have ELK reset a counter everytime this happens. If the counter reaches 0 that means CQC didn't flip the ouput and it's offline.

 

[felixrosbergen]

Nobody?

Is Spanky on vacation or something ?

Seriuously, it's a very annoying issue. I'm pretty close to trying the serial router route and how CQC and ELK control the lights concurently rather than have the ELK relay the commands. Based on beelzerobs test there no noticeable delay between commands when issued from CQC via his driver.

 

[AceCannon]

I am also very interested in this thread. I've got to decide very soon how to implement ALC with my new house. Elk or CQC (or both? I guess)

Mav, it sounds to me like the delays are happening when Elk issues several commands at once. What about ALC scene switches? Any delay when multiple lights are controlled by a scene?

 

[Spanky]

The lighting commands for most systems are set to 1 second intervals. Universal Devices had us add an option to speed up the lighting commands by checking the OPT option in the lighting setup menu. I am not sure it will work with ALC, but worth a try.

 

[felixrosbergen]

Did i read the manual backwards then? I way i read it was that it was only needed for some but not for most and not when using the M1XSP.

If CQC can send commands in much more rapid succesion to the ALC controller and have it all work fine why can't elk?

In my original post i note that i've tried this both with the OPT setting on and off. With it checked (meaning no delay) not all commands are properly processed.

Programming the scenes in ALC is a major PITA, for a ALL OFF scene i need to redo the entire scene each time i commision a new light. Programming the scenes involved running around the house and hitting every light switch. Doing this with 20-30 switches for each scene switch where i want the ALL OFF command takes forever. Due to this i had hoped to configure the scens in ELK and then just use the scene switches as triggers, but if the ELK can only send the commands too fast (apparently since out of 10 commands only 1 or 2 are executed) when OPT is check or terribly slow (1 second interval is a lot) then this is not going to work very well.

Is there a way to configure the delay between commands? If i can set it to like 200ms it would probably be much better.

Trying to find out if this is caused by the ALC<>ELK module or if this is also and issue with the clases EKL<>M1XSP<>ALC serail<>ALC controller setup.

 

[felixrosbergen]

Acecannon:

when you learn a scene associated with a scene switch and then press the switch to execute the scene the various lights all change states simulatenously or close enough to simultenously that i can't tell any delay.

Who has the classic setup so we can figure this thing out?

Trying to figure out if the classic setup in combination with the serial router will work.

http://www.avocationsystems.com/SR-2.html

 

[Spanky]

I am not the ALC expert, but does ALC have group or scene commands where a single command will control entire groups or scenes of lights? That way one command can change a lot of lights.

 

[felixrosbergen]

Yes, they do have that capability, but learning the scene into the controller is a PITA as described in post #5. If you have a completely finihsed installation it may not be so bad, but if you're adding switches regularly it's a pain.

Their scenetech software 'may' resolve this issue for a non ELK installation, but when using the ELK<>ALC module it's apparently not possible to use that software.

 

[AceCannon]

Didn't I read in one of these threads that each button on a scene switch has a "phantom" device code? If so, could you learn the ALL OFF scene to one button on one scene switch, then have the Elk execute that specific button?

Granted, you would still have to run around re-doing the scene when you add a new device. . .

 

[felixrosbergen]

Acecannon:

You could possibly be right that indeed i could learn the scene once for 1 button on one switch and then have ELK use the ALL OFF buttons on the other scene switches to trigger the same scene. I'm fairly sure i can trigger the 'scenes' from ELK, but will try to confirm tonight.

Thansk for the suggestion, if it works it's a good time saver.

I just tried togling the ELK lighting field representing the scene switch buttons in CQC and found no action. The screne switches show up as 'false' in CQC and when pressed for a few seconds become true, the never appear to switch back to false.

I'll try to do this directly from the ELK tomorow night if i can and will try to read up a bit more on the virtual scenes, but i'm getting pretty frustrated with this and am pretty close to throwing in the towel and getting the straight up serial controller rather than the ALC/ELK interface. Then at least my lighting will be smooth, if i want to i can then go the serial router route to have both ELK and CQC control the lighting (if that even works).

From what i hear from beelzeron though CQC you get much better control of the lights (ramp rates, etc).