Release 3.1.13 (Beta) Is Now Available

[Michel Kohanim]

Hello ooker,

 

I think the problems are related. The fact that Programs tab takes a long time to load indicates that ISY is very busy running programs and thus cannot release the lock so that the Admin Console can load program config.

 

The fact that your ELK is sluggish when ISY is connected indicates that ISY is trying to send it commands too frequently.

 

What I suggest is:

1. Try to get to the Programs Summary tab

2. Look for all programs that are in the Running state

3. Right mouse click on each and then choose Stop ... this might take a while since ISY is busy

--> for each program you stop, observe the performance of ELK; if ELK performance improves then that specific program is the cause

 

With kind regards,

Michel

[elvisimprsntr]

only problem i have observed so far is upon first login after upgrading and clearing cache, the Insteon devices statuses are blank. I had to close my browser and log back in without clearing cache.

 

 

UPDATE

 

I have several program that use network resources that run at different times of the day. I do not have run at startup enabled for these programs. My network resource programs change the channel on my whole house video distribution system at various time of the day.

 

In .12 only the program that should have run last based on the time of day would run. Now all of them run at start up in .13

 

 

Time User Code Message

Fri 2011/11/25 20:18:34 System -5012 28

Fri 2011/11/25 20:19:51 System -5012 29

Fri 2011/11/25 20:22:51 System -170001 UDQ:Queue Full: ELK

Fri 2011/11/25 20:22:51 System -170001 UDQ: Queue(s) Full, message ignored

Fri 2011/11/25 20:22:41 System -5 Start

Fri 2011/11/25 20:22:43 System -170001 [Network] Established

Fri 2011/11/25 20:23:02 System -140005 Net Module Rule: 25 (CH 5)

Fri 2011/11/25 20:23:03 System -140005 Net Module Rule: 28 (CH 8 )

Fri 2011/11/25 20:23:03 System -140005 Net Module Rule: 30 (Enter)

Fri 2011/11/25 20:23:04 System -140005 Net Module Rule: 23 (CH 3)

Fri 2011/11/25 20:23:04 System -140005 Net Module Rule: 23 (CH 3)

Fri 2011/11/25 20:23:05 System -140005 Net Module Rule: 30 (Enter)

Fri 2011/11/25 20:23:05 System -140005 Net Module Rule: 24 (CH 4)

Fri 2011/11/25 20:23:06 System -140005 Net Module Rule: 23 (CH 3)

Fri 2011/11/25 20:23:06 System -140005 Net Module Rule: 30 (Enter)

[ooker]

I ran into a number of issues getting the ELK Module setup. Unfortunately, it took most of the day and two support sessions with UD (they were very helpful).

 

Unfortunately, there is not a lot of documentation about how to setup the ELK Module and the ELK M1XEP Ethernet interface for the ELK. So I wrote up what it took to get things working for me, here. I hope this helps other people who are trying to get their ISY-99i ELK Modules working:

 

viewtopic.php?f=26&t=7415

 

Documentation on the ELK module is now available here: http://www.universal-devices.com/mwiki/ ... ity_Module

[LeeG]

elvisimprsntr

 

There is a "Catch up schedules at restart" Configuration option that will cause Programs to run at startup as well. Try disabling that option.

 

Lee

[wuench]

I need to know that ISY is connected and communicating to ELK at all times. I tried writing a test program to check the connection state "IF Elk System is Connected" or "IF Elk System is Enabled" and they are always false. I do have an active connection because I can change a output and also see a zone status change in real time in the ISY admin app.

 

I reported this not working in the 3.1.12 thread although I did see my rule fire once, when I disconnected from the Elk using ElkRP. I have two rules, one to email upone Elk System is Connect and one for Elk System is NOT connected. Never saw the NOT rule fire...

[Tunaman]

Michel

 

I got a chance to try 3.1.13.

Unfortunately, I'm still seeing same problems. The error log is full of messages:

Sat 2011/11/26 10:26:37 PM System -170001 [uDSockets] HTTP:31 error:6

[FRR]

 

FRR,

 

You do not want to use Enabled because as long as you have ELK enabled in the configuration panel, then the condition is always true. Or, perhaps, you would want to use AND instead of Or.

 

With kind regards,

Michel

 

Michel Thanks for the reply.

 

The Connected status always evaluates to FALSE even though I have a connection and can control ELK outputs and see zone changes in real time in the ISY app.

 

Keeping the ISY/ELK connection up is now imperative since I'm relying on ISY for security events etc. I would like to know when there is a connection issue and also would like to know how to have ISY re-establish the connection. It would also be nice to periodically ping the ELK to verify that it is reachable. This could be set up in the configuration tab including ping enable, ping frequency, retires before error, etc. There could be a status and an event to indicate the ping results which would be used in ISY programs.

 

Here's the program I used to test the functionality and it is always evaluates to false which I believe is incorrect.

If

Elk System is Connected

Then

Set '2nd Floor / Master BedRm_Floor Lamp Lt' On

Else

Set '2nd Floor / Master BedRm_Floor Lamp Lt' Off

 

Regards, Frank

[Michel Kohanim]

Hello tunaman, if you are available tomorrow (Sunday) please send an email to support@universal-devices.com and we'll try to accommodate a remote session.

 

wuench/FRR, we are looking into this issue as we speak.

 

With kind regards,

Michel

[IndyMike]

Michel and UDI Team,

 

Thank you for all the hard work. 3.1.13 Installed without issues. ELK Arm/Disarm, Exports, and Zone queries appear to be working nicely.

 

I attempted to diagnose the problems reported by weunch and FRR regarding the ELK "connected" function and learned a couple of things -

 

1) Initially the program below indicated false. I assumed this was due to it not being triggered.

2) Fired up ELKRP2 and connected to the ELK. The program did not trigger. It was at this point that I realized that the ISY could still communicate with the ELK with ELKRP2 running. I didn't realize this was possible. Communication appears to be one-way. The ELK communicate state changes to the ISY, but ISY cannot Arm/Disarm the ELK.

3) Physically disconnected the ELK from the network. The ISY displayed a warning message in the top menu bar area and triggered the program. This appears to be automatic - the user does not need to manually query to determine the status.

4) Reconnecting to the Elk again triggered the program which now evaluated to True.

 

If

Elk System is Connected

Then

- No Actions - (To add one, press 'Action')

Else

- No Actions - (To add one, press 'Action')

 

I'm hoping that the source of the confusion is the fact that running ELKRP2 does not fully disconnect the ISY.

 

IM

[IndyMike]

Michel,

 

There appears to be a refresh problem with the ISY Link Table Viewer under 3.1.13:

 

1) Upon initial entry into the admin console everything works fine. Viewer correctly displays the ISY links for various devices.

2) Performing a device link table scan correctly shows device links.

3) Performing a compare correctly opens the ISY Link Viewer and compares links.

4) After step 3 (compare) the ISY Link Viewer will "stick" to whatever device was compared. All devices will appear to have the same links.

 

Exiting/re-entering the admin console clears the problem. Not a huge deal - we have a work around.

 

Hope you and the team managed to fit in some down time over the Holiday,

IM

[Michel Kohanim]

Hello IM, thanks so very much! You are correct ... the only time ISY considers itself disconnected from ELK is if it cannot communicate with it.

 

As far as the ISY/Device links table, would you be kind enough to let me know the procedure you used? I tried all permutations and could not reproduce the problem. I used Node | Right Mouse Click | Diagnostics menu ...

 

 

With kind regards,

Michel

[IndyMike]

Hello Michel,

 

I was using the "right click" method as well.

 

The problem only occurs after you use the "compare" function within the device links viewer. After using the compare, the ISY link viewer appears to hang - presents the same information for all devices.

[LeeG]

Michel

 

The Show ISY Links appears to be intermittent or very step specific. I ran several tests when IM made his initial post and could not recreate.

 

Tried it again today and can reproduce with a specific sequence.

 

Start Admin Console

Show Device Links Table for ICON Dimmer

Compare

Show ISY Links Table for RemoteLinc2

 

The last Show ISY Links for RemoteLinc2 does not replace the ISY Links display from the Compare of the ICON Dimmer.

 

Other sequences have run without any problems.

 

Lee

 

EDIT: it is NOT specific to the RemoteLinc2. Same sequence except the Show ISY LInks for an ICON Relay produces the same result; the Show ISY Links from Compare is not replaced. Also found it not necessary to restart Admin Console to recreate.

[Tunaman]

Michel -- I think I may have found the problem. It looks like my M1XEP is failing. I noticed that the ISY was hanging when it was trying to get the text for the audio devices. I was able to write a quick script which uses socat to ease-drop on the serial port, and I noticed that when the sd command with type 18 was sent, the M1XEP was sending back what looked like a corrupt response (a lot of hex values), however, I don't have any audio devices, so it should have responded with a 000 for the value. I think the ISY then went into a tight loop.

 

I also noticed that when I check the version of the M1XEP software via the vn command, it was returning all 000's. From ElkRP, it shows the correct version. I tried to overwrite it with the same version, but it failed on the upgrade. The interesting part is that everything else that uses the M1EXP (ekeypad for instance) continues to work fine (but nothing is looking for audio devices).

 

I'll reach out to Elk tech supp tomorrow, but based on fact that my experiences seem to be unique, and that I'm seeing some strange responses from the M1EXP, let's wait and see what they have to say.

[FRR]

Michel,

 

I have some additional info on the Elk connection status issue. If there is a current connection and I create a new program that checks the connections status and force a Run If, it always evaluates to false. Then, if I enter any 4 digit CORRECT or INCORRECT User Access Code in the Elk configuration, save it, the connection status in now true and the arm/disarm panel remains as displayed.

 

If I then enter the ElkRP Access Code (5 digits in my case), the connect status is now false and the arm/disarm panel NOT displayed.

 

If I now enter any 4 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now TRUE and the arm/disarm panel IS displayed.

 

If I now enter any 5 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now FALSE and the arm/disarm panel is NOT displayed.

 

If I now enter any 6 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now TRUE and the arm/disarm panel IS displayed.

 

If I now enter any 5 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now FALSE and the arm/disarm panel is NOT displayed.

 

If I now enter any 6 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now TRUE and the arm/disarm panel IS displayed.

 

If I now enter any 7 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now FALSE and the arm/disarm panel is NOT displayed.

 

Seems that any even number of digits entered in the Access Code >= 4 results in the Arm/Disarm panel being displayed and the Connection Status being evaluated to TRUE as long as the program was created before the Access Code was entered.(Similar results for Enabled Status. Both seem to only be evluated when the Access Code is changed.)

 

The "If Elk System is Connected" runs when the Access Code is changed even if the program is marked as Disabled!

Also, I can't seem to Arm the ELK regardless if the Access Code that I enter.

 

I hope this helps.

Regards

Frank

 

If

Elk System is Connected

Then

Set '2nd Floor / Master BedRm_Floor Lamp Lt' On

Else

Set '2nd Floor / Master BedRm_Floor Lamp Lt' Off

 

 

 

 

 

 

 

.

[Michel Kohanim]

Hi IM/Lee, thanks so very much for the information ... it's fixed for the next release.

 

Frank,

Access code has to either be 4 or 6 digits otherwise ISY considers the code an invalid access code and won't even try to connect.

 

If the access code 4 o 6 (quick syntax test), then ISY tries to connect ; making a connection has nothing to do with the Access Code. Connection merely means that ISY has established a network connection to M1XEP.

 

Now, if the Access Code is wrong, the only thing you cannot do is arm/disarm. So, are you certain that you have the correct access code?

 

With kind regards,

Michel

[FRR]

Michel, Thanks for your reply.

 

Sorry for the confusion. Which Access Code should be used in the ISY/ELK Conf Tab? The RP Access Code, a valid Users Access Code, the M1XEP User Web Access Code, The Installer/Programmers Access Code?

 

There still seems to be an issue when the "If Elk System is Connected" is evaluated. It is not evaluated correctly when a new program is created until the Access Code is changed. Also, the "If Elk System is Connected" program runs when the Access Code is changed even if the program is marked as Disabled!

 

If I connect with ELKRP while ISY is connected, the ISY ELK Connected Status is unaffected even though some functions are now not possible through ISY. I think we need a status that would indicate that ISY has full access to the ELK so we can be assured that communications will happen as expected. Can this be done?

 

Regards,

Frank

 

EDIT

I changed my ElkRP Access Code from 5 to 6 places and reconnected and still can't arm and the above behavior continues. Here's the log:

Also what do the lines in RED mean? Why are these 3 zones showing up here when none of the others are?

 

Sun 11/27/2011 11:54:21 PM : connect(ELK notSSL xxx.xxx.xxx.xxx 645A08F0 2101 200)

Sun 11/27/2011 11:54:33 PM : [ELK 0 0 0] (157/1/0)

Sun 11/27/2011 11:54:33 PM : [ELK 0 0 0] (156/1/0)

Sun 11/27/2011 11:54:33 PM : [ELK 0 50 0] Zone : Garage Dr #1 Up : (53/134/0)

Sun 11/27/2011 11:54:33 PM : [ELK 0 55 0] Zone : Driveway #1 : (53/135/0)

Sun 11/27/2011 11:54:33 PM : [iNST-ACK ] 02 62 04.8E.CD 0F 11 FF 06 LTONRR (FF)

Sun 11/27/2011 11:54:33 PM : [ELK 0 86 0] Zone : Analog Dr Test : (53/82/0)

Sun 11/27/2011 11:54:33 PM : [iNST-SRX ] 02 50 04.8E.CD 0F.9E.D4 27 11 FF LTONRR (FF)

Sun 11/27/2011 11:55:20 PM : [ELK 0 0 1] Keypad : Main Panel : Access Code Valid (101/1/0)

Sun 11/27/2011 11:55:28 PM : [ELK 0 0 1] Keypad : Main Panel : Access Code Valid (101/1/0)

Sun 11/27/2011 11:55:37 PM : [ELK 0 0 1] Keypad : Main Panel : Access Code Valid (101/1/0)

Sun 11/27/2011 11:55:45 PM : [ELK-ERR ] Arm Stay : Area 1

Sun 11/27/2011 11:56:27 PM : [ELK 0 2 0] (113/130/0)

[Chris Jahn]

Hi Frank,

 

Those cryptic Zone messages are the current voltages for each zone in decivolts. The voltage for a zone is sent whenever a zone voltage query is performed and the voltage actually changed.

 

eg.

Sun 11/27/2011 11:54:33 PM : [ELK 0 50 0] Zone : Garage Dr #1 Up : (53/134/0)

 

Zone : Garage Dr #1 Up has a voltage of 13.4 volts (134 decivolts)

[ryarber]

I still only get outputs 65 and up showing on my elk module. Should I be seeing 1-64 as well?

[Chris Jahn]

I still only get outputs 65 and up showing on my elk module. Should I be seeing 1-64 as well?

Hi ryarber,

 

Yes, you should see some or all outputs 1-64. The way to make them show up is to give them a name in Elk RP and select "Show" (in Automation -> Outputs). Make sure to save/send to control.

 

When you are finished, do a "Refresh Topology" from the ELk config page in the ISY Admin console.

[TJF1960]

I was making some scene changes as well as program changes this morning. I am now getting a ton of errors in the error log for the last 2 hours such as:

 

>/rest/vars/set/2/8/1
Tue 2011/11/29 08:43:12 AM	System	-170001	2: GET-->/rest/vars/set/2/8/1
Tue 2011/11/29 08:43:12 AM	System	-170001	0: GET-->/rest/vars/set/2/80/120
Tue 2011/11/29 08:43:12 AM	System	-170001	0: GET-->/rest/vars/set/2/80/120
Tue 2011/11/29 08:43:15 AM	System	-170001	0: GET-->/rest/vars/set/2/190/1
Tue 2011/11/29 08:43:15 AM	System	-170001	0: GET-->/rest/vars/set/2/190/1
Tue 2011/11/29 08:43:17 AM	System	-170001	0: GET-->/rest/vars/set/2/114/1
Tue 2011/11/29 08:43:17 AM	System	-170001	0: GET-->/rest/vars/set/2/114/1
Tue 2011/11/29 08:43:17 AM	System	-170001	0: GET-->/rest/vars/set/2/78/170
Tue 2011/11/29 08:43:17 AM	System	-170001	0: GET-->/rest/vars/set/2/269/1
Tue 2011/11/29 08:43:17 AM	System	-170001	0: GET-->/rest/vars/set/2/78/170
Tue 2011/11/29 08:43:17 AM	System	-170001	1: GET-->/rest/vars/set/2/269/1
Tue 2011/11/29 08:43:17 AM	System	-170001	0: GET-->/rest/vars/set/2/80/121
Tue 2011/11/29 08:43:17 AM	System	-170001	0: GET-->/rest/vars/set/2/80/121
Tue 2011/11/29 08:43:22 AM	System	-170001	0: GET-->/rest/vars/set/2/190/-1
Tue 2011/11/29 08:43:22 AM	System	-170001	0: GET-->/rest/vars/set/2/190/-1
Tue 2011/11/29 08:43:22 AM	System	-170001	0: GET-->/rest/vars/set/2/114/-1
Tue 2011/11/29 08:43:22 AM	System	-170001	0: GET-->/rest/vars/set/2/114/-1
Tue 2011/11/29 08:43:22 AM	System	-170001	0: GET-->/rest/vars/set/2/80/120
Tue 2011/11/29 08:43:22 AM	System	-170001	0: GET-->/rest/vars/set/2/80/120
Tue 2011/11/29 08:43:23 AM	System	-170001	0: GET-->/rest/vars/set/2/269/-1
Tue 2011/11/29 08:43:23 AM	System	-170001	0: GET-->/rest/vars/set/2/269/-1
Tue 2011/11/29 08:43:23 AM	System	-170001	0: GET-->/desc
Tue 2011/11/29 08:43:27 AM	System	-170001	0: GET-->/rest/vars/set/2/8/-1
Tue 2011/11/29 08:43:27 AM	System	-170001	0: GET-->/rest/vars/set/2/8/-1
Tue 2011/11/29 08:43:28 AM	System	-170001	0: GET-->/rest/vars/set/2/114/1
Tue 2011/11/29 08:43:28 AM	System	-170001	0: GET-->/rest/vars/set/2/114/1
Tue 2011/11/29 08:43:28 AM	System	-170001	0: GET-->/rest/vars/set/2/80/121
Tue 2011/11/29 08:43:28 AM	System	-170001	0: GET-->/rest/vars/set/2/80/121
Tue 2011/11/29 08:43:28 AM	System	-170001	0: GET-->/rest/vars/set/2/269/1
Tue 2011/11/29 08:43:28 AM	System	-170001	0: GET-->/rest/vars/set/2/269/1
Tue 2011/11/29 08:43:28 AM	System	-170001	0: GET-->/rest/vars/set/2/190/1
Tue 2011/11/29 08:43:28 AM	System	-170001	0: GET-->/rest/vars/set/2/190/1
Tue 2011/11/29 08:43:33 AM	System	-170001	0: GET-->/rest/vars/set/2/114/-1
Tue 2011/11/29 08:43:33 AM	System	-170001	0: GET-->/rest/vars/set/2/114/-1
Tue 2011/11/29 08:43:33 AM	System	-170001	0: GET-->/rest/vars/set/2/269/-1
Tue 2011/11/29 08:43:33 AM	System	-170001	0: GET-->/rest/vars/set/2/269/-1
Tue 2011/11/29 08:43:35 AM	System	-170001	0: GET-->/rest/vars/set/2/190/-1
Tue 2011/11/29 08:43:35 AM	System	-170001	0: GET-->/rest/vars/set/2/190/-1
Tue 2011/11/29 08:43:38 AM	System	-170001	0: GET-->/rest/vars/set/2/114/1
Tue 2011/11/29 08:43:38 AM	System	-170001	0: GET-->/rest/vars/set/2/114/1
Tue 2011/11/29 08:43:38 AM	System	-170001	0: GET-->/rest/vars/set/2/78/171
Tue 2011/11/29 08:43:38 AM	System	-170001	0: GET-->/rest/vars/set/2/78/171
Tue 2011/11/29 08:43:39 AM	System	-170001	0: GET-->/rest/vars/set/2/80/120
Tue 2011/11/29 08:43:39 AM	System	-170001	0: GET-->/rest/vars/set/2/80/120
Tue 2011/11/29 08:43:39 AM	System	-170001	0: GET-->/rest/vars/set/2/269/1
Tue 2011/11/29 08:43:39 AM	System	-170001	0: GET-->/rest/vars/set/2/269/1
Tue 2011/11/29 08:43:41 AM	System	-170001	0: GET-->/rest/vars/set/2/190/1
Tue 2011/11/29 08:43:41 AM	System	-170001	0: GET-->/rest/vars/set/2/190/1
Tue 2011/11/29 08:43:42 AM	System	-170001	0: GET-->/rest/vars/set/2/8/1
Tue 2011/11/29 08:43:42 AM	System	-170001	0: GET-->/rest/vars/set/2/8/1
Tue 2011/11/29 08:43:44 AM	System	-170001	0: GET-->/rest/vars/set/2/114/-1
Tue 2011/11/29 08:43:44 AM	System	-170001	0: GET-->/rest/vars/set/2/114/-1
Tue 2011/11/29 08:43:44 AM	System	-170001	0: GET-->/rest/vars/set/2/78/172
Tue 2011/11/29 08:43:44 AM	System	-170001	0: GET-->/rest/vars/set/2/78/172
Tue 2011/11/29 08:43:44 AM	System	-170001	0: GET-->/rest/vars/set/2/80/121
Tue 2011/11/29 08:43:44 AM	System	-170001	0: GET-->/rest/vars/set/2/80/121
Tue 2011/11/29 08:43:44 AM	System	-170001	0: GET-->/rest/vars/set/2/269/-1
Tue 2011/11/29 08:43:44 AM	System	-170001	

 

Suggestions on where to look for the problems? No programs are looping that I can see. Programs seem to be running fine thru this.

 

Thanks,

Tim

 

Edit:

I did a full back up just before rebooting to see if the errors continued. It looks as though the errors stopped right when the backup started (or ended, not sure).

 

At any rate for the last five minutes since the reboot I have not had any errors.

 

Thoughts on what could have caused the massive amounts of errors and why they stopped during back up?

[LeeG]

I don't think these are errors. The 170001 is an information message which in this case reflectes variable access through the REST interface. I saw a post from Michel some time ago (which I cannot immediately locate) about the 170001 messages which may come when the Event Viewer has been run.

 

I’m still searching for that post.

 

Did they stop when the Event Viewer was closed.

[TJF1960]

Hi Lee,

 

Good memory, now that you mention that I do recall that thread also.

 

In answer to your question though no the errors continued even after I closed the event viewer which I opened to see if I could see any reason for the quickly filling error log. I do not recall if I opened the event viewer or not during my work with scenes and programs earlier but if I did I didn't leave it open very long and would have closed it. But either way the data for the error log continued even after the viewer was closed.

 

Edit: I just ran event viewer for a few minutes then turned off and waited a minute. No errors in the error log so perhaps that problem has since been corrected.

[LeeG]

I think the application that is using the REST interface would have to be running, at least doing something that required variable access before the 170001 messages related to rest variable access would be logged. What I don't remember and have not found is what turns those information messages on and what turns them off. I was thinking event viewer but that is ruled out when the event viewer was closed.

[TJF1960]

If you mean the apps accessing ISY I do have 1 DSCLink and 3 WCLink apps running 24/7, constantly updating variables in ISY, and all 4 were running and updating the variables the last time the event viewer was accessed. But if you mean something in ISY which is run or turned on which causes the data writes to the error log, then I haven't a clue what it could be.