Minimizing ELK Lighting Delay

[icellama21]

I know this topic has been discussed before, but it is hard to piece it all together. What are the general steps to minimize the delay for lighting control with an ELK M1 and RS232 controlled lighting interfaces. I know there are some specifics to technology, I'm more interested in minimizing the time between an ELK event(zone change, time, etc) and the transmission of a command from the M1XSP to the lighting interface. I've noticed this can take anywhere from 0.3 sec to 2-3 seconds. Here is what I have seen before:

1) M1XSP for lighting on lower address and closer to M1 on bus
2) Use the OPT flag to limit delay between multiple commands if possible
3) Place event sensors(zones, motion detectors, etc) on fast-loop response
4) Limit the amount of routine work the M1 has to do(like events every second to decrement counters, etc)
5) Use only one lighting interface/expander
6) Using older firmware. Not sure why, but rolling back to 2007 firmware(which came with the system) cut my latency by 50%.

 

[electron]

I wish there was an easy fix for this, but I don't think there is. I have tried everything but changing the address of the M1 XSP (I think it was the first one in line anyways), and it is slow as heck. I'm ready to move away from the Elk M1 platform for my main home automation stuff because of weird behavior like this.

 

[BDHall]

I wish we could be given an option to improve on the response time for the I/O. This has been one of my few complaints with my M1G along with wishing for an "or" clause in the rules.

 

[GraysonPeddie]

I'd probably have my computer do the home lighting instead of Elk (this also frees up my virtual outputs), as I found that a 1-second interval is too limiting when it comes to signaling the lights. Also, the whenever-and-then rules just makes it a mess for sequencing lights. No hard feelings toward Elk Products, since I'll stop there before I mention many more limitations about home lighting through Elk M1 Gold.

 

[edselrt]

I just ordered ELK m1 Gold system and planning to turn on/off ALC lighting using motion detector . 1 sec delay before activation is not good

 

[BDHall]

I'd probably have my computer do the home lighting instead of Elk (this also frees up my virtual outputs), as I found that a 1-second interval is too limiting when it comes to signaling the lights. Also, the whenever-and-then rules just makes it a mess for sequencing lights. No hard feelings toward Elk Products, since I'll stop there before I mention many more limitations about home lighting through Elk M1 Gold.

Do you see a full second delay?

 

[GraysonPeddie]

The minimum interval is 1 second. If you want to go down to 250 milliseconds (50 milliseconds is the minimum for Insteon), it must be done either by another RS232-based controller or a PC-based controller that supports interval less than 1 second.

One thing that I'd like to mention is it may not be recommended to poll analog zones (for voltage monitoring purposes) for less than 100 milliseconds. I've never done this, as I'm not sure if Elk M1 Gold has the processing power to meet up with today's PCs and servers. But one day, it'd be great to do that for the next 3 to 5 years when processors become efficient enough.

 

[SteveL]

If you use your ELK and communicate with the MIXEP and talk to a device like the ISY from Universal Devices over the network rather than the serial buss ithan commands can be instant. If you are trying to talk to something other than X-10 there will be a delay because ELK sends out the X-10 code first before it send the serial command. There are now options to turn that off in the lighting config under "OPT"

Steve L

 

[GraysonPeddie]

Yes, I do use the OPT feature. But what I'm trying to say is if you want to do a 250ms flash for two times within a second, you can't do that with Elk.

Here's what I meant (as an example: I wanted the light to flash 5 times in 2.5 seconds short of 3 seconds; "-" and "_" represents 250 milliseconds):

[:)_:(_-___]

(had to get rid of emoticon with "[" and "]" inside the code tag...)

 

[SteveL]

I will be at ELK in a couple of weeks doing a class. I will run your question by their team is see if i can find anything to add that may be helpful.

Steve L

 

[BDHall]

I will be at ELK in a couple of weeks doing a class. I will run your question by their team is see if i can find anything to add that may be helpful.

Steve L

Steve,

If you get a chance, would you please ask if there is anything else that can be done to improve response time of the Elk I/O, perhaps some type of user selectable option to speed things up a bit. I am referring to the time it takes to detect the change in a zone and to fire an output or turn it off. I know the serial bus will slow things down slightly, but the delays seem a little excessive.

Have a safe trip.

Brian

Perhaps Spanky will chime in.

 

[scriptx]

Ouch! 1 second isn't automation, I can turn on a lot of lights myself in that time! I just got finished installing the Elk. Sounds like I will have to find another lighting controller.

 

[GraysonPeddie]

Yep! 1 second is not automation, even with the OPT flag turned on for a couple of light/appliance devices! :wacko:

 

[edselrt]

I've read that ALC integrates with automation/security controllers using X10, hence, this delay is also present with other controllers too! correct me if i am wrong...

 

[Lagerhead]

What are the general steps to minimize the delay for lighting control with an ELK M1 and RS232 controlled lighting interfaces. I know there are some specifics to technology, I'm more interested in minimizing the time between an ELK event(zone change, time, etc) and the transmission of a command from the M1XSP to the lighting interface. I've noticed this can take anywhere from 0.3 sec to 2-3 seconds.

I must admit to being puzzled here. I do not see this behavior in the M1G built-in serial port.

This is allowing of course for normal X10 transmission delay of (very close to) 1 second. I'm not saying that this is "great", only that the M1 is responding promptly and correctly, and so is not implicated in the problem.

What am I missing?