eKeypad M1 / Elk / Insteon lighting delay

[iostream212]

I have been using eKeypad M1 edition for several months now to control my Elk and Insteon setup. Everything was great. The response from the iPod Touch to the lighting system was instant. One day I decided to change the system setup to allow access from WAN. After deciding I didn't want that I changed it all back and now have a very bad lag (3-8 seconds from eKeypad button press to Insteon light action.)
Trying to remedy I reset my ISY, reset the PLM, and created a new ELKRP account to no avail. I even reinstalled eKEypad on the Touch. Still lagging. Tech support from eKeypad thinks it is a Insteon communication interference issue. I don't think it is for the following reasons:

1.) The XEP web interface controls the lighting instantly.
2.) ISY web interface controls the lighting instantly.
3.) I listened for data on the ELK port and find that all communication for lighting was instant except for the eKeypad command. When the eKeypad sent an 'on' command (for example) nothing happend on the port for the 3-8 seconds. Then the command was fired to the M1 and the lighting responded instantly after that.

To confuse the issue even more it seems that once the lag is done and the light has been controlled, the same light can be controlled with no lag thereafter. Repeated on offs are instant from eKeypad. If I exit the program and restart the delay is restored.

Any ideas?

 

[apostolakisl]

Might be worth trying to uninstall/reinstall ekeypad.

 

[jaysonc]

iostream,

The testing you have done does rule out Insteon communications issues.

The 3-8 second lag is interesting and may provide a clue. The Elk M1 can only process one message at a time. If eKeypad sends a second message too fast the M1 will drop the processing of the first message. To prevent this eKeypad will queue up messages to be sent. In the event that a message never response, eKeypad will automatically send the next message after 4 seconds.

The way to verify this is to use the "Status" screen. On this screen eKeypad lists the size of the outgoing Queues (Low, Medium and High priority). Any commands you initiate from the GUI will go into the high priority queue. Any messages in the high priority queue will be send before any messages from the lower priorities.

I am starting a new beta testing cycle this weekend and will do some additional diagnostic tests to see if I can replicate this behavior.

 

[iostream212]

iostream,

The testing you have done does rule out Insteon communications issues.

The 3-8 second lag is interesting and may provide a clue. The Elk M1 can only process one message at a time. If eKeypad sends a second message too fast the M1 will drop the processing of the first message. To prevent this eKeypad will queue up messages to be sent. In the event that a message never response, eKeypad will automatically send the next message after 4 seconds.

The way to verify this is to use the "Status" screen. On this screen eKeypad lists the size of the outgoing Queues (Low, Medium and High priority). Any commands you initiate from the GUI will go into the high priority queue. Any messages in the high priority queue will be send before any messages from the lower priorities.

I am starting a new beta testing cycle this weekend and will do some additional diagnostic tests to see if I can replicate this behavior.

Thanks for the info. I am also working on my end to narrow down the possible causes for any delays. I know my issues are probably few and far between. So when is 2.1.0 going live??!!

 

[jaysonc]

The 2.1.0 update is starting Beta testing this weekend.

Barring any big surprises it should go live at the end of July. There are a number of big items in the works.

 

[forgets]

The 2.1.0 update is starting Beta testing this weekend.

Barring any big surprises it should go live at the end of July. There are a number of big items in the works.

sorry to threadjack.. but...
is it can it be truly time for audio control?
hah, i've had those things set up in the elk for a while now, i don't think i've ever talked to you at length about it jayson, but i think you mentioned it'd be done straight through the IP of the IP232?
i've been putting off getting a nuvo wireless control pad, cause if you pull that off then you'll have turned my iphone into one of those that does so much more.. even still ekpro has been my best purchase on my phone ever, worth every penny.

I've been out of the loop ever since you helped me get my dedicated micros ds2 running.. (i still have that ds1 laying around i can lend to you if you want to add that to the list of supported DVR's) but i did notice the 2.0.10 update yesterday, it runs a lot quicker than 2.0 for me, and is about the only good thing that's come out of the iOS4 update (safari crashes if you click a link half the time now..)

Don't know if you're still looking for beta testers, but i'm available if you need..

 

[jaysonc]

Yes. version 2.1.0 grew to an unmanageable size, so I released 2.0.10 last week to clear the table for the major changes in 2.1.0 (all IP Video related). The performance improvements you are seeing in 2.0.10 should address some of the delays seen in lighting but I am not completely finished testing this aspect. There may be more improvements coming in the next updates.

You are correct about the audio integration. The design is based upon the Elk integration with these systems so while I defer to their installation directions, I believe they all make use of an IP232 to allow the XEP to communicate with the audio system serial ports. I am still working on a testing environment for audio control, but as soon as I have a solution in place audio control will be coming quickly afterward.

Supporting the generation 1 Dedicated Micros DVRs does not look like it will ever be possible. After speaking with DM at length about it, these DVRs are simply not able to support the remote interface that eKeypad uses. They only support a proprietary protocol used by the PC Viewer application.
I am working on PTZ and history playback from DM though. Prototypes are looking very nice.

I am going through the process of adding some additional beta testers now, but it is related to a relatively obscure crash. None of my testing devices can re-create the problem, but it is rendering 3 devices useless when they enable a login via the secured port of their XEP. A very hard bug to track down. eMail me via the links on the eKeypad support screens. I could use the help testing the new DM enhancements.

--
Jayson

 

[iostream212]

This new version has caused nothing but issues for me.

Here are a few screen shots of the problems to help troubleshoot.

1.) Incorrect zone status. Notice on this shot ELK (correctly) shows ready to arm while eKeypad does not.

2.) Here is a list of zones sorted by 'Violated', yet in this list is a non-violated zone

3.) Here is one of my outputs, which is off, but shows an on status

4.) A quick vid I took on my camera showing weird lighting control, where I turn a light on, but is turned immediately off.

HERE

 

[jaysonc]

iostream,

Your screen shots look like you may have some of the M1 settings required by eKeypad disabled.

This type of disconnect between the status is exactly what some of these settings will require. In short the M1 does not proactively inform eKeypad of status changes by default. You must tell the M1 (via Elk-RP) to do so.

1. Open your M1 configuration in Elk-RP.
2. In the "folder items" find the "Globals" entry and click on it.
3. On the right panel you will now see a series of tabs. Select "G29-G42 (Special)"
4. You will now see a group of check boxes labeled, "Serial Port 0 Transmit Options". Check all of these boxes.
5. Send these changes to your control.

This process is also described in more detail in the eKeypad install guides with screen shots here.

If this does not resolve the delays, please email me. This type of disconnect and/or delay in status updates is not normal. In version 2.0.10 status update delays are practically instantaneous when connected by local wifi.

 

[iostream212]

Turning off the background option under support fixed most of these issues for me. There is still a lighting delay, but all the other issues stopped after changing this setting.

 

[jaysonc]

Yes, the multi-tasking in iOS4 is causing an intermittent error when reconnecting to the M1. This is preventing eKeypad from successfully reconnect when it returns from the background. A fix is in process for the next update.

The "Disable Background" toggle added to the Support screen in eKeypad was added in anticipation of possible issues related to multi-taksing and as a security feature for people that did not feel comfortable leaving eKeypad running in the background.

Analysis is still ongoing on the lighting delay issue. eKeypad is not delaying the sending of the message, but the first message sent is taking a very long time. This may be the result of a status query happening in the M1 which is a blocking action. I have some ideas of how to force this to happen preemptively but they need to be tested further.

Turning off the background option under support fixed most of these issues for me. There is still a lighting delay, but all the other issues stopped after changing this setting.