hart2hart Posted July 28, 2012 Share Posted July 28, 2012 From DSCLink forum conversations with io_guy and reviewing my log files, I'm getting slow response and many retries to REST commands. io_guy indicates getting 6 REST updates in a couple seconds and retries only during 3:00 am resync of ISY. From reviewing my log, I get retries all during the day (will have between 80-100 today) and REST updates take 5-15 seconds on a regular basis. The ISY and DSCLink PC are on same network switch and I've looked and don't see anything talking to ISY other than DSCLink. What should I look at to diagnose? I would like REST response faster with retries reduced for optimal inferface with security system and in turn web cam recording software. Also, I've posted couple other questions about thermostat activity. They may have some bearing on this question but seperated them if just coincidental issues. Thanks According to the log, the ISY returned successful writes to variables 1, 2, 5, 6, 8 and 9 within nine seconds after the panel was disarmed (pretty slow). Last few days of error log: Time User Code Message Sun 2012/07/22 12:16:48 PM System -5012 164 Sun 2012/07/22 12:17:01 PM System -5012 165 Sun 2012/07/22 12:17:31 PM System -170001 [uDSockets] RSub:40 error:6 Sun 2012/07/22 12:22:57 PM System -170001 [uDSockets] HTTP:32 error:6 Sun 2012/07/22 12:23:02 PM System -170001 [uDSockets] HTTP:32 error:6 Mon 2012/07/23 09:17:30 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 5 Mon 2012/07/23 09:19:53 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 Mon 2012/07/23 09:22:30 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 6 Mon 2012/07/23 10:19:53 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 Mon 2012/07/23 11:19:53 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 Mon 2012/07/23 12:19:53 PM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 Mon 2012/07/23 01:19:53 PM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 Mon 2012/07/23 08:20:13 PM System -5012 174 Mon 2012/07/23 08:21:40 PM System -5012 175 Mon 2012/07/23 09:21:01 PM System -140005 Net Module Rule: 5 Tue 2012/07/24 11:24:34 AM System -5012 177 Tue 2012/07/24 11:24:46 AM System -5012 178 Tue 2012/07/24 11:25:29 AM System -5012 179 Tue 2012/07/24 11:25:29 AM System -5006 uuid:179 Tue 2012/07/24 11:25:31 AM System -5006 uuid:179 Tue 2012/07/24 11:26:59 AM System -170001 [uDSockets] RSub:40 error:6 Tue 2012/07/24 03:52:41 PM System -140000 datafeed.weatherbug.com Tue 2012/07/24 10:03:41 PM System -5012 181 Tue 2012/07/24 10:03:42 PM System -5006 uuid:181 Tue 2012/07/24 10:03:44 PM System -5006 uuid:181 Tue 2012/07/24 10:06:38 PM System -5012 182 Tue 2012/07/24 10:06:43 PM System -5006 uuid:181 Tue 2012/07/24 10:06:45 PM System -5006 uuid:181 Tue 2012/07/24 11:52:33 PM System -140000 datafeed.weatherbug.com Wed 2012/07/25 07:19:45 AM System -5012 184 Wed 2012/07/25 07:19:47 AM System -5006 uuid:184 Wed 2012/07/25 07:19:49 AM System -5006 uuid:184 Wed 2012/07/25 07:31:32 PM System -10108 Check log Thu 2012/07/26 07:16:33 AM System -10011 n/a Thu 2012/07/26 08:32:44 AM System -5012 188 Thu 2012/07/26 08:34:18 AM System -5012 190 Thu 2012/07/26 08:34:19 AM System -5006 uuid:190 Thu 2012/07/26 08:34:21 AM System -5006 uuid:190 Thu 2012/07/26 09:22:27 PM System -170001 [uDSockets] HTTP:26 error:6 Thu 2012/07/26 09:22:32 PM System -170001 [uDSockets] HTTP:26 error:6 Thu 2012/07/26 10:40:06 PM System -5012 192 Thu 2012/07/26 10:40:07 PM System -5006 uuid:192 Thu 2012/07/26 10:40:09 PM System -5006 uuid:192 Fri 2012/07/27 01:22:26 AM System -170001 [uDSockets] HTTP:26 error:6 Fri 2012/07/27 01:22:31 AM System -170001 [uDSockets] HTTP:26 error:6 Fri 2012/07/27 01:22:36 AM System -170001 [uDSockets] HTTP:26 error:6 Fri 2012/07/27 04:22:22 AM System -170001 [uDSockets] HTTP:27 error:6 Fri 2012/07/27 07:22:23 AM System -170001 [uDSockets] HTTP:30 error:6 Sat 2012/07/28 08:22:20 AM System -170001 [uDSockets] HTTP:30 error:6 Sat 2012/07/28 08:22:25 AM System -170001 [uDSockets] HTTP:30 error:6 Sat 2012/07/28 09:22:25 AM System -170001 [uDSockets] HTTP:26 error:6 Sat 2012/07/28 09:22:30 AM System -170001 [uDSockets] HTTP:26 error:6 Link to comment
Michel Kohanim Posted July 30, 2012 Share Posted July 30, 2012 Hello hart2hart, Sincere apologies for tardy reply. The first thing that sticks out is: Mon 2012/07/23 09:17:30 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 5 Mon 2012/07/23 09:19:53 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 Mon 2012/07/23 09:22:30 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 6 Mon 2012/07/23 10:19:53 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 Mon 2012/07/23 11:19:53 AM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 Mon 2012/07/23 12:19:53 PM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 Mon 2012/07/23 01:19:53 PM System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 4 If you look at ISY error codes (http://www.universal-devices.com/mwiki/ ... r_Messages), -140002 signifies connection timeout. This means that ISY tried connecting to something on the network and it failed. My main question is whether or not you have any type of firewall software on your PC which may be blocking ISY from connecting to it? With kind regards, Michel Link to comment
hart2hart Posted July 30, 2012 Author Share Posted July 30, 2012 Michel: No problems on reply. As always you and team do an excellent job and I'm just trying to get handle on where configuration stands. The ISY is only talking to the one PC with DSCLink installed and that PC does have Norton Internet Security. Would ISY sometimes get responses and other times be refused? I looked at PC NIS network map and marked ISY as fully trusted so can see if that makes a difference. More to what I was looking to determine was the issue with DSCLink timeouts and the speed of REST updates compared to what io_guy gets. Can you offer suggestions on what I should review? BTW, all three of recent posts are part of a tune up review to make sure all is well -- have not done this in quite some time. Thanks. Link to comment
io_guy Posted July 30, 2012 Share Posted July 30, 2012 Your error log is over a 6 day period. I would suggest doing a couple alarm status requests and checking the ISY's general/error log over that timeframe. As mentioned, I run DSCLink on W7 and a PogoPlug, my DSCLink log shows the request, DSC return, ISY REST sends and ISY replies within the same second (maximum two). Try disabling any additional software (such as 3rd party virus/firewall) to see if it makes a difference. My W7 machine runs the standard firewall and Microsoft Security Essentials. Link to comment
Michel Kohanim Posted July 30, 2012 Share Posted July 30, 2012 Hello hart2hart, I am in agreement with io_guy. The first thing is to remove Norton security ... at the moment, firewall software is the ONLY external component of the PC that can impact both incoming and outgoing traffic. With kind regards, Michel Link to comment
hart2hart Posted July 31, 2012 Author Share Posted July 31, 2012 Gentlemen: Thanks. Based on your input, I will perform following actions one at a time and note results every few days. 1. 7/30/2012 8:00am - Put ISY in trusted zone of DSCLink PC NIS Results 7/20/2012 9:39pm No ISY error log entries since but still getting timeouts on DSCLink REST updates 2. Disable programs that run based on DSCLink variables -- Very few program runs immediatly as a result of variable updates. The value of DSC variables are used at other times as part of an and condition to determine if programs run as needed. The alarm variable = 1 is notable exception. 3. Remove NIS To provide additional details, I perform a DSC panel update request from ISY to DSCLink every hour since DSC documentation states you cannot depend on all actions to be broadcast and many (but not all) timeouts during this update (I have 30 zones variables and all other standard like away stay alarm ready etc). The reason I'm evaluating my environment is a time out occured during alarm system test and the alarm variable REST update timed out. Paul Link to comment
Michel Kohanim Posted July 31, 2012 Share Posted July 31, 2012 Hi Paul, Thanks so very much for update. Very much looking forward to the result of your experimentation. With kind regards, Michel Link to comment
hart2hart Posted July 31, 2012 Author Share Posted July 31, 2012 1. 7/30/2012 8:00am - Put ISY in trusted zone of DSCLink PC NIS Results 7/30/2012 9:39pm No ISY error log entries since but still getting timeouts on DSCLink REST updates 7/31/2012 7:30 No ISY error log entries and 7 DSCLink Rest timeouts ... about one per each full DSC hourly update and different variable each time 2. Disable programs that run based on DSCLink variables -- Very few program runs immediatly as a result of variable updates. The value of DSC variables are used at other times as part of an and condition to determine if programs run as needed. The alarm variable = 1 is notable exception. 3. Remove NIS Link to comment
io_guy Posted July 31, 2012 Share Posted July 31, 2012 I perform a DSC panel update request from ISY to DSCLink every hour since DSC documentation states you cannot depend on all actions to be broadcast and many (but not all) timeouts during this update (I have 30 zones variables and all other standard like away stay alarm ready etc) The IT-100 functions directly like a control panel (and receives the same data). The only time data would be missed would be if your computer was locked up. Link to comment
Michel Kohanim Posted July 31, 2012 Share Posted July 31, 2012 Hi all, Can we increase the timeout on the Network resource by 50% and see if that solves the problem. It might just be that the computer is way too busy? With kind regards, Michel Link to comment
hart2hart Posted July 31, 2012 Author Share Posted July 31, 2012 Gentlemen: I'm not concerned about a timeout during the routine hourly update. FWIW, DSC it-100 doc indicates that not all updates are broadcast by panel and recommends a periodic update to confirm in sync ... Not clear the potential missing updates are worth effort but I was just following DSC recommendation. My real concern is that an alarm REST variable update timed out within a couple tests. I'm good with any solution that minimizes this possibility or retries ASAP. My personal efforts have been to see if the timeouts were created by my environment. The DSCLlink PC and ISY are on same network switch and the PC is only running DSCLink. This ties in with reason I was concerned with thermostat activity since I'm not sure how their activity could impact REST updates. Sent from my ADR6300 using Tapatalk 2 Link to comment
hart2hart Posted August 1, 2012 Author Share Posted August 1, 2012 1. 7/30/2012 8:00am - Put ISY in trusted zone of DSCLink PC NIS Results 7/30/2012 9:39pm No ISY error log entries since but still getting timeouts on DSCLink REST updates 7/31/2012 7:30am No ISY error log entries and 7 DSCLink Rest timeouts ... about one per each full DSC hourly update and different variable each time 7/31/2012 7:15pm No ISY error log entries and 66 DSCLink Rest timeouts ... occured all during day while alarm employee and I were moving around house and breaking zones until about 11:00 am and several in afternoon that were from hourly DSC resync 2. Disable programs that run based on DSCLink variables -- Very few program runs immediatly as a result of variable updates. The value of DSC variables are used at other times as part of an and condition to determine if programs run as needed. The alarm variable = 1 is notable exception. 3. Remove NIS Link to comment
io_guy Posted August 1, 2012 Share Posted August 1, 2012 FWIW, DSC it-100 doc indicates that not all updates are broadcast by panel and recommends a periodic update to confirm in sync ... Not clear the potential missing updates are worth effort but I was just following DSC recommendation. Please show me in the doc where it says that. Link to comment
hart2hart Posted August 1, 2012 Author Share Posted August 1, 2012 FWIW, DSC it-100 doc indicates that not all updates are broadcast by panel and recommends a periodic update to confirm in sync ... Not clear the potential missing updates are worth effort but I was just following DSC recommendation. Please show me in the doc where it says that. I can't locate it in the the IT-100 developers manual but I read a warning about an issue in a DSC document about 5/6 years ago when I set up HomeSeer and their DSC plugin. In thinking about it, it may have been a warning not to set baud rate too high becasue if IT-100 orginated commands were very rapid you could loose/overwrite them. In addition, not that HomeSeer documents or programs are a reliable source (cause they are not!), it is still in the DSC plugin setup and documented as follows: Polling Timer HomeSeer will automatically interpret messages from the panel and update the status of your devices, but the Panel does not always send messages back to HomeSeer when its status changes. Setting this value tells HomeSeer to get the latest information from the panel at the interval you set. Setting this value to 0 disables polling. Would you suggest removing this resync for now and observing results. (probably add it back at least every 4 hours for insurance latter) This would allow us to see how many timeouts occurs with only small number of varaibles being updated at one time. However, the situation that put me on this track was when the alarm variable REST timed out during an alarm. Also, please know, I appreciate this utility and am not looking to find fault. As I stated in another post, my thought was that something in my configuation was causing the issue and I was trying to binary my way through possible causes. I am grateful for all advice and suggestions. Link to comment
io_guy Posted August 1, 2012 Share Posted August 1, 2012 Yea, the Homeseer quote is a Homeseer issue, not DSC. The DSC sends all events across the bus to the comm module (IT-100, PC5401, whatever) and the comm module in turn sends all out - there are no lost packets. The only spot for lost packets is on our end. Either a poor RS-232 setup (assuming using a serial comm) where your baud rate it set too high for line length, or your software is stalling and not grabbing all commands being sent (The comm module output does not buffer). It's a moot point either way because an hourly status request should do nothing to affect system performance. It's fine to leave in. I would really jump straight to Norton for my first test. Just a note, I believe you're using a 2DS. In that case you should be looking at the EnvisaLink API, not the IT-100 programmer's manual (very similar but small differences exist). Just as a sanity check on your issue (my setup is only 8 zones), I just populated 40 zones with ISY variables to test speed. From status request to last variable write was within 2 seconds (log doesn't go to milliseconds). Link to comment
hart2hart Posted August 1, 2012 Author Share Posted August 1, 2012 io_guy and Michel: You were 100% right. I should have turned NIS off as the first step... I just turned off Firewall protection of NIS and ran 15 full syncs in row as fast as I could press button and each finished in 2 - 3 seconds. Honestly, I thought putting the ISY in PC's NIS Full trust zone turned off firewall for that device but damn was I wrong. I went back to NIS and there is an option at bottom of trust level screen labeled "Exclude from IPS scanning" (option is kinda full trust with steriod kicker). I turned this option on for ISY IP address and turned NIS firewall back on. Did 10 more full sync updates without a timeout and finish times of 2-3 seconds. So sorry to waste your time with this but for what its worth, I learned several things about networking. Lotta good that does you Again thanks for your advice and patience, Paul Link to comment
Michel Kohanim Posted August 1, 2012 Share Posted August 1, 2012 Hi Paul, that's great news and thanks so very much for the update! With kind regards, Michel Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.