elvisimprsntr

BACKGROUND I've been experiencing problems with stale values for my TStat (v2.2 adapter). I had moved my RF APs to address problems with a TriggerLinc. Then I starting noticing the TStat was not reporting changes and longer query times. I eventually had move my APs back to their original locations, deleted and re-added my TStat to get it working as expected again. I had already deleted and re-added my TStat under a prior release per release notice instructions. During this time my RF motion sensors continued to work normally. Not exactly sure what to make of it.

Michel, I have been unable to reproduce the problem, but I had been doing electrical work turing off various circuits while re-wiring some electrical boxes. All circuits were on during the time the ISY locked up and the times are correct.

BACKGROUND I have a few programs that use network resources to sent http get commands to an IR blaster to change the channel on my whole house video distribution set up. Unfortunately the ISY locked up trying to send those commands. The ISY would not respond to ping requests and the admin console would not come up. I have to power cycle the ISY. ERROR LOG Tue 2011/12/27 18:00:01 System -140005 Net Module Rule: 23 Tue 2011/12/27 18:00:01 System -140005 Net Module Rule: 23 Tue 2011/12/27 18:00:02 System -140005 Net Module Rule: 30 Wed 2011/12/28 00:00:00 System -140005 Net Module Rule: 25 Should have been followed with Rule: 28 Should have been followed with Rule: 30 Wed 2011/12/28 03:16:59 System -170001 UDQ:Queue Full: ELK Wed 2011/12/28 03:16:59 System -170001 UDQ: Queue(s) Full, message ignored Wed 2011/12/28 03:16:51 System -5 Start Wed 2011/12/28 03:16:53 System -170001 [Network] Established Wed 2011/12/28 03:19:10 System -170001 [uDSockets] RSub:31 error:6

I keep getting errors that the ELK WSDK PDF is currupted. http://www.universal-devices.com/develo ... DK-ELK.pdf

Attached are some shell scripts, resulting XML responses, and logs of the wget communication. I added comments in the elk/isy_interrogate.log files where I noted discrepancies. UPDATE I fixed a bash script bug for the elk rest command to disarm the system. the resulting output indicated the command was successful, but the ISY did not disarm the Elk. I also changed the bash scripts to prompt the user for unique settings so you can run them at your facility. I also have a question what "ae type" is in the area status output. <?xml version="1.0" encoding="UTF-8"?> And where do I find the elkArmType definition or enumeration? rest.zip Archive.zip

If the rest/security interface as been depreciated, should it still be in the WSDK document? My ID and PW are correct and the syntax for the wget command I pulled off a forum and confirmed with the wget --help option. Here is the output for a successful command: root@Siri:~/SiriProxy# sh isy_living_off.sh --2011-12-01 07:32:54-- http://192.168.69.90/rest/nodes/19496/cmd/DOF Connecting to 192.168.69.90:80... connected. HTTP request sent, awaiting response... 401 OK Reusing existing connection to 192.168.69.90:80. HTTP request sent, awaiting response... 200 OK Length: 104 [text/xml] Saving to: `cmdresp.log' 100%[================================================================>] 104 --.-K/s in 0s 2011-12-01 07:32:54 (2.34 MB/s) - `cmdresp.log' saved [104/104] UPDATE I have tried a number of the Elk REST commands defined in the Elk WSDK document an I get mixed results on the responses. Some result in 404 errors, other result in 200 status with empty contents, a few result in 200 status will what appears to be appropriate contents. All REST commands I get the initial 401 message when I have confirmed I am using the correct ID/PW. Some of the Elk REST 404 errors appear to be documentation errors. I have also seen random slow response as another forum member has reported.

Not sure if I am doing something wrong, but the security REST interface seem to be returning 404 errors. Excerpt from my bash script. Same syntax works for other REST commands. wget -O security.log --user $USER --password $PASS ${ISYRESTURL}${ISYCMD} Output from command. --2011-11-30 07:15:45-- http://192.168.69.90/rest/security Connecting to 192.168.69.90:80... connected. HTTP request sent, awaiting response... 401 OK Reusing existing connection to 192.168.69.90:80. HTTP request sent, awaiting response... 404 OK 2011-11-30 07:15:45 ERROR 404: OK. The above command is listed in the WSDK http://www.universal-devices.com/develo ... Manual.pdf

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)

BACKGROUND My error log seems fairly clean, but do notice a few errors. I also observe the error log does not save the last entry. For example there should be a "System -140005 Net Module Rule: 30 " entry at 6::00:01 AM at the very end. Also noticed the first few events are out of order. Time User Code Message Tue 2011/11/22 05:27:55 System -170001 [uDSockets] RSub:32 error:6 Tue 2011/11/22 05:28:14 System -170001 UDQ:Queue Full: ELK Tue 2011/11/22 05:28:14 System -170001 UDQ: Queue(s) Full, message ignored Tue 2011/11/22 05:28:05 System -5 Start Tue 2011/11/22 05:28:07 System -170001 [Network] Established Tue 2011/11/22 05:28:24 System -140005 Net Module Rule: 25 Tue 2011/11/22 05:28:25 System -140005 Net Module Rule: 28 Tue 2011/11/22 05:28:25 System -140005 Net Module Rule: 30 Tue 2011/11/22 05:36:27 System -170001 [uDSockets] RSub:31 error:6 Tue 2011/11/22 05:36:32 System -170001 [uDSockets] RSub:31 error:6 Tue 2011/11/22 05:36:36 System -170001 [uDSockets] RSub:31 error:6 Tue 2011/11/22 05:36:41 System -170001 [uDSockets] RSub:31 error:6 Tue 2011/11/22 05:36:45 System -5012 26 Tue 2011/11/22 05:58:12 System -140005 CLI-WBug Tue 2011/11/22 06:00:00 System -140005 Net Module Rule: 24 Tue 2011/11/22 06:00:01 System -140005 Net Module Rule: 23

FYI, I relinked my APs and no longer observe the 170 humidity problem. Everything is being observed on my local WLAN. In my case i can duplicate the problem by simply manually query the tstat. 50% of the time the humidity is reported by the adapter as 170. (see previous post) All other values are reported correctly. Your Cool Setpoint is set to 85 degrees, right? (humidity reports 2 x Cool Setpoint) I believe this is a Venstar adapter bug that has been around ever since I first got mine 2 versions ago and they (Smarthome) still haven't fixed it. The good news is if you don't do manual queries it won't happen much.

Lee, I found the problem. I forgot I have some IR receiver lighting programs which I never use, one of which had a bug in it. Thanks, Elvis

Lee, I do not have any lighting programs in my ISY yet. All still reside in my Elk at the moment. I attached the toggle mode settings, on and ramp rate, and comm error log. Let me know if I am doing something wrong or can help troubleshoot. Elvis Archive.zip

Lee, OK I now see the scene vs the controller initial and ramp rates, and tweaked them to get it working, or so I thought..... For some reason now when I press the MOVIE button when all the lights are off, the responders in the MOVIE scene perform a FAST ON, then proceed to ramp off at the specified ramp rate. I added the MOVIE button as a responder to other scenes to make the illumination respond as appropriate. I attached my topology if this helps. P.S. Are the version numbers reported by the ISY supposed to match the version numbers physically on each device? topology.v3.1.12__Sun 2011.11.20 22.12.28.html.zip

BACKGROUND Sorry if this is a duplicate question, but I didn't come across anything recent. I added a 6 button Keypadlinc switch (2486S v5.5) which I am using secondary buttons for MOVIE and PARTY scene. For the MOVIE scene I want the theater lights to ramp up/down over 30 seconds like in a movie theater. When I add a button to the MOVIE scene the lights simply FAST ON/OFF even though I have the ramp rates set for the individual dimmer devices. The only way I could get it to work was to remove the button from the MOVIE scene and create separate programs to FADE UP/DOWN the MOVIE scene. QUESTIONS Is there a better way to do this or is this a limitation of either the KPL or ISY? Elvis

i installed the Elk module. everything seems to be working, including the voltage and zone status. I discovered that I had to export and import the lighting into the Elk, then tweak my Elk event and time based lighting rules since the indexes changed. My Elk lighting rules are working again. But now the Elk module is no longer reporting area status, zone status or voltages. I have tried rebooting my ISY the symptoms remain. I confirmed the Elk config settings. UPDATE I cleared java cache again even though I had cleared cache after upgrading to 3.1.12 and the Elk module. Now the Elk area/zone information is reflected in the admin console. elk.tiff

Everything is being observed on my local WLAN. In my case i can duplicate the problem by simply manually query the tstat. 50% of the time the humidity is reported by the adapter as 170. (see previous post) All other values are reported correctly.

I upgraded to 3.1.12 remotely without any problems. I did follow the instructions to remove and re-add my tstat per the release notes. When I did i observed that when editing my devices the changes would not take effect until I close my browser and logged back in. Perhaps this is because I was remotely connected. I am at back home now, so I will reports any similar behavior if I see it. I also upgraded to the v2.3 stat adapter late last week. Upon reboot (hard and soft) of the ISY the humidity is sometimes first reported at 170. A manual query of the tstat corrects the humidity. I can't imagine I have Insteon communication issues as my network as been stable for better than a year. Elvis UPDATE I can actually get the tstat to report 170 approx. 50% of the time when I manually query the stat. Thu 11/17/2011 14:47:11 : [ 14 66 F4 1] CLIHUM 53 Thu 11/17/2011 14:47:18 : [ 14 66 F4 1] CLIHUM 170 Thu 11/17/2011 14:47:28 : [ 14 66 F4 1] CLIHUM 53 Thu 11/17/2011 14:48:08 : [ 14 66 F4 1] CLIHUM 54 Thu 11/17/2011 14:48:08 : [ 14 66 F4 1] CLIHUM 170 Thu 11/17/2011 14:48:14 : [ 14 66 F4 1] CLIHUM 54

I just requested my replacement. My guess is they update units as they come back and ship them out to different customers. The downside of non-field reprogrammable hardware.

I have a v2.0 adapter and don't seem to have the communication/lockup issues everyone is reporting. Just curious what the communication issues are and with what version.

Try using a different time server (us.pool.ntp.org) Also try a city not so close the time zoneline. Not sure if the ISY DST determination is look up table or is formula based, but I have seen formula based implementation get it completely wrong, or change a week prior or late. If the time is correct after this Sunday, we will know it is formula based or the offset is wrong for your city.

I don't have flex power enabled.

why does the ISY keep making requests to Above Net Communications (64.124.109.237) servers? is this for weather bug?

confirmed the beta 10 still locks up when rebooting the Elk XEP.

sorry to report that rebooting the Elk XEP once again causes the ISY to lock up

according to Wes "UDI broke UPnP auto discovery in the .8 and .9 firmware releases that can lead to his issue." I believe this will be fixed in .10