Jump to content

Keypad delay communicating with ISY


sanders2222

Recommended Posts

I found this response in an earlier thread...

(The Keypadlinc) v41 did in fact exhibit major problems with link table.

 

Using 4.0.2 on 994 might address this issue.

I've been trying to diagnose an intermittent delay I sometimes experience when I press a (bottom) button on my keypad. The button press is suppose to arm the ELK. Sometimes, it can take 10-20 seconds before the ELK responses to my button push. I replaced my 99i/IR with a 994i/IR and that did not correct the problem (although I think I get more instant responses now than I did before).

 

I have a KPL v36. So I would assume whatever bug the v41 had, mine may be worse. I'll try upgrading my firmware to see if that will correct this issue. (Edit: I also noticed the ISY recognizes this KPL as a 6 button but it's actually set up as an 8 button. I wonder if that could effect how the commands from the switch are received by the ISY?)

 

My second option may be to replace the KLP pad with a newer version.

Link to comment
Share on other sites

Hi sanders2222,

 

I do not think v41 issue has anything to do with what you are experiencing. Does this happen all the time? Is it reproducible?

 

Have you looked at the Event Viewer to see what else is happening at the same time? Could it be that ELK is slow? For instance, in the same program, add another Action with turns on a light before the ELK call. Does that take the same amount of time?

 

With kind regards,

Michel

Link to comment
Share on other sites

Thanks Michel for your response.

Does this happen all the time? Is it reproducible?
It seems about 50-70% of the time there is this delay. I've even noticed the delay sometimes occurs when I Arm/Disarm from the Admin Console as well.
Have you looked at the Event Viewer to see what else is happening at the same time?
Yes. I am attaching what the event viewer shows when I press the button. Here is the procedure that is tied to the button.
Program="Going Out"
If
       Control 'Utility Room / Util KPL G Away 10.9D.73.G' is switched On
   And Control 'Utility Room / Util KPL G Away 10.9D.73.G' is not switched Off
Then
       Set Scene 'Hallways / Hall Utility' On
       Set Elk Area 'House Main' Arm Away
Else
  - No Actions - (To add one, press 'Action')

Could it be that ELK is slow? For instance' date=' in the same program, add another Action with turns on a light before the ELK call. Does that take the same amount of time?[/quote']This was a good suggestion. In this test, the light did come up when I pressed the button. Then it seemed like 10 seconds or so before the ELK acknowledged. The Event Viewer shows the delay. I use to think the ISY was the delay (unknown looping program). But this test would seem to rule that out. Now it might appear the ELK is slow OR there is too much communication between the ELK and ISY that causes the delay.

However, I do not experience any delay issuing commands from the ELK RP.

post-1419-140474159217_thumb.jpg

Link to comment
Share on other sites

Something is running in a loop. It took 16 seconds before the KPL button was marked On and the Program triggered to issue the Scene command. Look at the Programs | Summary tab for Programs that show running in the Activity column.

Link to comment
Share on other sites

Something is running in a loop. Look at the Programs | Summary tab for Programs that show running in the Activity column.
I have checked the Program/Summary but there is no activity except the program that arms the ELK. Programs that put the house in away mode are initiated once the ELK is armed.

What I have seen during the day are a number of programs that use the Weather module in the condition. These programs seem to execute (FALSE) every time the outside temperature changes. Sometimes I think these create a lot of unnecessary traffic that keeps my ISY busy and delaying the command transmitting to the ELK.

Short of disabling all the programs, then add them back in one at a time (until I find the culprit) I do not see another diagnostic tool available that will point to the problem. I saw a post somewhere where someone had a simple solution to disable all programs. But I don't remember the trick.

Link to comment
Share on other sites

On the Programs | Summary page below Summary tab, select Disable. Left click and hold on top program dragging cursor down to last Program. Click Apply. There is a Refresh button on right side to refresh display.

Link to comment
Share on other sites

On the Programs | Summary page below Summary tab, select Disable. Left click and hold on top program dragging cursor down to last Program. Click Apply. There is a Refresh button on right side to refresh display.

 

Before disabling all of your programs, make a note of any that are already disabled that will need to remain disabled when your reverse the disable all procedure above.

 

-Xathros

Link to comment
Share on other sites

  • 4 weeks later...

Instead of disabling programs, I took another approach and I believe I have identified my problem. During the last week I have been able to armed/unarmed my Elk without a reoccurring delay. My fingers are crossed that I now know the issue although, at this point I only have a partial solution.

 

The problem I have was not the result of a looping program. But my ISY was busy with a constant bombardment of condition tests involving my add on modules. I have a number of HVAC & irrigation programs that monitor values in the Climate module. What I noticed was every time the temperature outside changed a degree, the light percentage changed or irrigation values changed, the programs with these in the conditions was tested and appeared on the program summary. I also compounded this problem by having numerous programs with multiple/complex condition tests.

 

A partial fix is to split up the complex program logic into multiple programs that call another. This has helped reduce the delays I was experiencing. An example of a program that was problematic is:

If
       (
            On Sun, Tue, Fri
            Time is  6:20:00AM
   And Module 'Climate' Irrigation Requirement >= 0.25 inches
         )
    Or (
            On Sun, Tue, Fri
            Time is Sunset  - 45 minutes
   And Module 'Climate' Irrigation Requirement >= 0.15 inches
         )
Then
       Run Programs that water zones

I found the above program tested for the time specified as well as any time the weather variable changed. My fix was to disable this program and created a new 'trigger' program that only included the time schedule. That way, this program will only run at the specified times from the call and not when a variable changed.

 

I will do some more testing on this theory and continue to 'break apart' programs that use multiple condition tests. But hopefully, the program execution delays I was experiencing are a thing of the past.

Link to comment
Share on other sites

If indeed it is ISY being busy that is causing the program execution delay, then it should affect all programs, not just the one to arm the elk. Have you seen delays like this with other programs?

 

I also have a kpl that arms my Elk. I have never had such a delay in arming. Whatever that's worth to you.

 

I have at times noticed a very slight delay in pushing a button that executes a program and the result of that program happening. Like maybe 1 or 2 seconds.

 

I have accidentally created looping programs (programs that count, re-triggering on the result of its own action). As I tried to get out of the loop, I experienced significant delays, on the order of 10 to 15 seconds. I would be a bit surprised if any non-looping program no matter how complex could hang ISY for 15 to 20 seconds. But perhaps if the programs summoning network resources or something?

Link to comment
Share on other sites

Have you seen delays like this with other programs?

And...

I would be a bit surprised if any non-looping program no matter how complex could hang ISY for 15 to 20 seconds. But perhaps if the programs summoning network resources or something?

I would say no on other programs, only those that involve my ELK.

I also eliminated the looping program theory as I disabled all my programs, except for the 4 programs that relate to the KPL button and ELK control. I still would experience a delay of up to 20 seconds. Plus sometimes I have this same delay even if I arm/disarm from the buttons on the ISY Console.

My problem has to be in the communication link between the ISY and the ELK. Perhaps my M1EXP card is the problem. At this point, I'm just not sure nor do I know how I can troubleshoot and resolve this issue. It's a bugger!

Link to comment
Share on other sites

Hi sanders2222,

 

Aren't there any diagnostic tools for M1XEP? I am sure there used to be ... the first thing is to check the traffic between ISY and M1XE: i.e you can see ISY sending the command and thus we have to see how long it takes for ELK to receive/process it.

 

With kind regards,

Michel

Link to comment
Share on other sites

Aren't there any diagnostic tools for M1XEP?
Thanks for the response Michel. I am looking into tools that may be available to diagnose ELK problems. I added a post at cocoontech.com http://cocoontech.com/forums/topic/24830-elk-not-playing-nice-with-isy/and checked the ELK.com site. I have noticed a couple of things.

I have ELKRP installed on one computer and it seems to work properly. But if I try to access the virtual keyboard, my browser shows a message "This page cannot be displayed". When I try to fix the connection, this dialog box pops up:I also get the same message when I try to access the virtual keypad through the Admin Console. So it may be that only have my connection partially set up.

At the ELK site I downloaded a software diagnostic tool for the M1EXP although I do not understand all that it can do yet. Hopefully, I'll have some time to get more familiar with the tool to see if I can sort out my problem, if there is one.

Following one suggestion, I rebooted the XEP and now when go to the ELK console, I need to enter my username and password. So that is some progress. Problem is I don't remember what those credentials were so I'll have look for that info.

post-1419-140474159655_thumb.png

Link to comment
Share on other sites

Are you using the secure port for communications between ISY/ELK?
I have a secure port (2601) as well as a non-secure port (2101) enabled in my ELKRP. However, (it took a while for me to find the configuration setup) I discovered the port was set at the non-secure value. If I understood you right I need to change 2101 to 2601.

Prior to making this change, I rebooted the XEP but that did not seem to change the behavior I experience with delayed responses from my ELK. When I push the KPL button, the light comes up (as it should) but sometimes it can take up to 20 seconds before the Elk responds.

I also noticed a delay in the ISY program response when the overhead door is violated. The following program should execute when this happens:

Program 'Arrive Garage'
If
       (
            Elk Zone 'Double Garage' is Violated
         Or Elk Zone 'Single Garage' is Violated
       )
Then
       Set Elk Area 'House Main' Disarm
Else
  - No Actions - (To add one, press 'Action')

I observed the Admin Console recognized the violation (viewing the ELK tab) but the program did not execute. I would think this is NOT the same issue but something else that is amiss.

I was hopeful that changing the port connection would have resolved these issues. Instead, with the ISY set to 2601, I get no response from the ELK nor does the console recognize the garage door violation.

Link to comment
Share on other sites

Hi sanders2222,

 

Apologies! My question was to make sure you were NOT using the secure port.

 

My recommendation is to export all your programs (My Programs), take a good backup, and then REMOVE all your programs except ONE or two with which you have delays. Once that's done - and if you still have delays, then the problem is either ELK itself OR the communications between ELK/ISY.

 

With kind regards,

Michel

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...