vspete

ALL ERROR TYPES. I just re-launched the admin console and pulled a log as of 1:03:21. Here are the logs last entries. I shut down the the slot #4 nodeserver at 12:21. Sat 2021/01/02 11:13:46 AM System -5012 34 Sat 2021/01/02 11:14:12 AM System -5012 36 Sat 2021/01/02 11:14:43 AM System -170001 [UDSockets] RSub:42 error:6 Sat 2021/01/02 11:14:48 AM System -170001 [UDSockets] RSub:42 error:6 Sat 2021/01/02 11:14:53 AM System -170001 [UDSockets] RSub:42 error:6 Sat 2021/01/02 11:14:58 AM System -5012 37 Sat 2021/01/02 11:20:23 AM System -140005 Net Module Rule: 4 Sat 2021/01/02 11:24:14 AM System -170001 [UDSockets] RSub:42 error:6 Sat 2021/01/02 11:24:14 AM System -170001 [UDSockets] HTTP:43 error:6 Sat 2021/01/02 11:24:17 AM System -5012 38 Sat 2021/01/02 11:25:35 AM System -170001 [UDSockets] RSub:25 error:6 Sat 2021/01/02 11:25:40 AM System -5012 40 Sat 2021/01/02 11:30:22 AM System -140005 Net Module Rule: 4 Sat 2021/01/02 11:35:22 AM System -140005 Net Module Rule: 4 Sat 2021/01/02 11:40:22 AM System -140005 Net Module Rule: 4 Sat 2021/01/02 11:45:23 AM System -140005 Net Module Rule: 4 Sat 2021/01/02 11:50:23 AM System -140005 Net Module Rule: 4 Sat 2021/01/02 11:55:23 AM System -140005 Net Module Rule: 4 Sat 2021/01/02 12:10:23 PM System -140005 Net Module Rule: 4 Sat 2021/01/02 12:15:23 PM System -140005 Net Module Rule: 4 Sat 2021/01/02 12:20:23 PM System -140005 Net Module Rule: 4 I restarted the nodeserver on slot #4 at 12:58 and there ISY is reporting its data correctly. I have to say I am stumped.. THe only change made was to change the logging level from debug to error on the ISY when I restarted the nodeserver. I just pulled the log again at 1:14 and one line had been added: Sat 2021/01/02 12:22:04 PM System -140005 Net Module Rule: 8 Looks like this one entry had been sitting in a cache or queue for more than 40 minutes before posting to the error log. I will check back in a few hours and look at the logs again.

I may have had a breakthrough of sorts. I agree that the errors in my log do not appear connected to subscriptions. However, I shutdown nodeserver #4 (one of 5 nodeservers running) and haven't logged a single error of any type since. It has been 59 minutes. The longest I went before was 10 minutes without an error. In the last full hour prior to shutting down the nodeserver in slot 4, the log registered 25 errors. I guess that's progress.

I originally posted this issue on Mobilinc's board (even though there wasn't a natural topic fit for Mobilinc Pro issues). This seems to match with @oberkc's comment early in this thread. There hasn't been any recent posts on Mobilinc's board, so I posted here. I did tag Wes per your advice. As for Module Rule 4: I don't think your assumption is valid. My Network Resource ID #4 refers to a http command to my Hunter Douglas Powerview hub which isn't called from the ISY at anytime these "errors" are posted. I think the best plan for me is to shutdown my nodeservers one at a time and see which error messages are affected. Will post the outcome of that experiment.

@MrBill Regrettably my oldest error log entries are from early December 2020. This was AFTER I began using network resources to control shades and several cloud hosted node servers. The -170001 particular error type was occurring at that time, but I don't recall any Mobilinc connectivity issues being present. I was experiencing issues with my cloud based nodeservers (frequent loss of connectivity) and moved them to a server on my network. That move completely eliminated those issues. My logs currently only show three error types on a frequently recurring basis and decoupled from any Mobilinc activity: Sat 2021/01/02 11:10:23 AM System -140005 Net Module Rule: 4 Sat 2021/01/02 11:13:36 AM System -170001 [UDSockets] RSub:## error:6 Sat 2021/01/02 11:13:46 AM System -5012 ##

Thanks Dennis for this link. While I can currently always connect without the "Mobilinc Disconnected... attempting to reconnect" message, sometimes the connection is not immediate. I have observed the connection delay issue most frequently when using the iWatch extension. The connection failure is reported on the iWatch not the iphone App. This condition eventually clears. I cannot correlate this phenomena to any specific logged error. I haven't seen any "Already Subscribed" messages since the reboot yesterday. I have used Mobilinc Pro for iOS since 2015 on two different iPhones with this ISY and never experienced this issue. I have never been unable to connect locally to my ISY via a browser, locally, via VPN, or remotely (through a forwarded https port). I disabled uPNP on the ISY this morning as it isn't needed and rebooted. A quick look at the log shows queue full errors after the reboot, but Mobilinc connected without issue and no errors logged associated with Mobilinc connection. Sat 2021/01/02 09:01:15 AM System -5 Start Sat 2021/01/02 09:01:16 AM System -110022 /CONF/INSTENG.OPT Sat 2021/01/02 09:01:16 AM System -110012 /CONF/INSTENG.OPT Sat 2021/01/02 09:01:20 AM System -110022 /DEF/F6/I1/NLS/EN_US.TXT Sat 2021/01/02 09:02:17 AM System -170001 UDQ: Queue(s) Full, message ignored Sat 2021/01/02 09:02:17 AM System -170001 UDQ: Queue(s) Full, message ignored Sat 2021/01/02 09:02:27 AM System -170001 UDQ: Queue(s) Full, message ignored Sat 2021/01/02 09:02:28 AM System -170001 UDQ:Queue Full: PDM : Task[10] HTTP_1 HTTP-Get pty=19 Sat 2021/01/02 09:02:37 AM System -170001 UDQ: Queue(s) Full, message ignored Sat 2021/01/02 09:02:47 AM System -170001 UDQ: Queue(s) Full, message ignored Sat 2021/01/02 09:02:57 AM System -170001 UDQ: Queue(s) Full, message ignored Sat 2021/01/02 09:02:57 AM System -170001 UDQ: Queue(s) Full, message ignored Sat 2021/01/02 09:03:08 AM System -170001 UDQ: Queue(s) Full, message ignored Sat 2021/01/02 09:01:27 AM System -170001 [Network] Established I have now disabled the iWatch extension and will observe behavior and logs over the next few days.

Thanks Mr. Bill for the detailed response. It is good to know that Mobilinc Pro is still viable on iOS. I do make use of the app on both my iPhone and iWatch daily. Your assessment: "When you say "unreliable" do you mean that it works sometimes but then for unexplained reasons you start getting a popup at the bottom of the screen that says something like "mobilinc has disconnected, attempting to reconnect"? " is an accurate description of what I have been experiencing since I upgraded iOS. Upon logging into the ISY admin console this morning, the "Already Subscribed" popup was visible. This is the first time I have seen this notification despite many many accesses to the admin console recently. The only thing new in my environment is I am now hosting a local Polyglot Nodeserver on my local network. I downloaded the ISY error log and found the following entries: Fri 2021/01/01 08:45:21 AM System -140005 Net Module Rule: 4 Fri 2021/01/01 08:46:56 AM System -5 Start Fri 2021/01/01 08:46:57 AM System -110022 /CONF/INSTENG.OPT Fri 2021/01/01 08:46:57 AM System -110012 /CONF/INSTENG.OPT Fri 2021/01/01 08:47:01 AM System -110022 /DEF/F6/I1/NLS/EN_US.TXT Fri 2021/01/01 08:48:06 AM System -170001 UDQ: Queue(s) Full, message ignored Fri 2021/01/01 08:48:06 AM System -170001 UDQ: Queue(s) Full, message ignored Fri 2021/01/01 08:48:16 AM System -170001 UDQ: Queue(s) Full, message ignored Fri 2021/01/01 08:48:17 AM System -170001 UDQ:Queue Full: PDM : Task[10] HTTP_1 HTTP-Get pty=19 Fri 2021/01/01 08:48:26 AM System -170001 UDQ: Queue(s) Full, message ignored Fri 2021/01/01 08:48:36 AM System -170001 UDQ: Queue(s) Full, message ignored Fri 2021/01/01 08:48:47 AM System -170001 UDQ: Queue(s) Full, message ignored Fri 2021/01/01 08:48:47 AM System -170001 UDQ: Queue(s) Full, message ignored Fri 2021/01/01 08:48:57 AM System -170001 UDQ: Queue(s) Full, message ignored Fri 2021/01/01 08:47:08 AM System -170001 [Network] Established After rebooting the ISY, Mobilinc seems to be performing normally. I cleared the logs and currently only show the following errors. I don't know how to interpret them in order to eliminate those that could be problematic, but perhaps you recognize some that should be investigated (note: the errors below were also visible in the log that were cleared following the ISY reboot): Fri 2021/01/01 12:02:25 PM System -140005 Net Module Rule: 4 Fri 2021/01/01 12:05:23 PM System -170001 [UDSockets] RSub:13 error:6 Fri 2021/01/01 12:05:23 PM System -170001 [UDSockets] RSub:30 error:6 Fri 2021/01/01 12:05:28 PM System -170001 [UDSockets] RSub:13 error:6 Fri 2021/01/01 12:05:28 PM System -170001 [UDSockets] RSub:30 error:6 Fri 2021/01/01 12:05:29 PM System -5012 33 Fri 2021/01/01 12:05:29 PM System -5012 34 Fri 2021/01/01 12:07:34 PM System -5012 36 Fri 2021/01/01 12:07:34 PM System -5012 37 Fri 2021/01/01 12:09:34 PM System -170001 [UDSockets] RSub:13 error:6 Fri 2021/01/01 12:09:39 PM System -5012 38 Fri 2021/01/01 12:15:22 PM System -140005 Net Module Rule: 4 Fri 2021/01/01 12:20:22 PM System -140005 Net Module Rule: 4 Fri 2021/01/01 12:22:07 PM System -5012 39 Fri 2021/01/01 12:22:29 PM System -5012 40 Fri 2021/01/01 12:22:39 PM System -170001 [UDSockets] RSub:30 error:6 Fri 2021/01/01 12:22:40 PM System -5012 41 Fri 2021/01/01 12:25:54 PM System -170001 [UDSockets] RSub:20 error:6 Fri 2021/01/01 12:25:54 PM System -170001 [UDSockets] RSub:30 error:6 Fri 2021/01/01 12:25:55 PM System -5012 42 Fri 2021/01/01 12:25:55 PM System -5012 43 Fri 2021/01/01 12:30:21 PM System -140005 Net Module Rule: 4 Fri 2021/01/01 12:35:22 PM System -140005 Net Module Rule: 4 Fri 2021/01/01 12:36:04 PM System -170001 [UDSockets] RSub:13 error:6 I will keep a watch on Mobilinc and check the logs once again should the issue repeat itself.. Thanks again and have a very Happy New Year! BR/Pete

I have used this app (MLP) successfully for years connecting locally (HTTP) and remotely (HTTPS port forwarded) to my ISY. After the most recent (12/18/20) iOS 14.3 update to my iPhone XS, connectivity has become problematic. For years I have left MLP set on https for connecting via local wifi or remotely without any issues. After the update this would no longer connect, so I switched to http (rather than auto). This seemed to work. Believing the https connection to be a certificate issue, I noticed that my ISY certificate had past its expiration date. I created and installed a new self-signed certificate. I removed the ML app from my iphone and reinstalled. On installation, the app reported the new security certificate was recognized. Connectivity is still unreliable using Mobilinc Pro either via http or https I have rebooted both the phone and my ISY several times, no change in connection reliability. I can launch and relaunch the app and eventually get MLP to connect. I have no trouble connecting to my ISY locally or remotely from any browser. The beta UDI mobile app for android also has no issues connecting (without using the ISY portal). I believe, something has happened to MLP with the latest iOS update (v14.3) that is adversely affecting the apps ability to connect. Any help would be appreciated.

Thanks guys. The ultimate solution to my issue was to delete and reinstall the 2441TH into the ISY. Doing so after a factory reset restored all reporting features from the thermostat including the current cooling state (CLIHCS).

My program is similar to your ":status" version. I will give the "control" version a try. Many thanks...

Thanks Stu. It is good to hear that these thermostats are working for someone. My ISY firmware is v.4.3.30 and 2441TH is v.0F When I started this thread, I was getting regular reports the thermostat visible in the ISY event viewer. I performed a thermostat factory reset and now only get updates when I query the device from the administrator. I do get unsolicited updates every 15 minutes from the ZTH thermostat (which is not the master). Here is what is returned from the wired master thermostat: Mon 08/17/2015 04:28:32 PM : [ 2F 79 E8 1] CLISPC 156 Mon 08/17/2015 04:28:32 PM : [ 2F 79 E8 1] CLISPH 136 Mon 08/17/2015 04:28:32 PM : [ 2F 79 E8 1] CLIHUM 40 Mon 08/17/2015 04:28:34 PM : [ 2F 79 E8 1] CLIMD 3 Mon 08/17/2015 04:28:34 PM : [ 2F 79 E8 1] CLIFS 8 Mon 08/17/2015 04:28:34 PM : [ 2F 79 E8 1] UOM 2 Mon 08/17/2015 04:28:35 PM : [ 2F 79 E8 1] ST 157 What I don't see returned is CLIHCS which should be the "State" which ISY would use to create the Cool Clt and Heat Clt status. Do you see a value for CLIHCS returned in your event viewer log? When I run a thermostat query command from within a program, I do not see any response in the event viewer. What am I missing?

Thanks Larry. Sounds like I need to search for another compatible thermostat. I haven't installed any Z-wave products yet. Looks like it is time to do a little research. Any suggestions for options compatible with isy would be appreciated.

I am currently using two Insteon thermostats. Both are controllable from the ISY and report temperature and humidity without any issues. The control state fields never populate for either thermostat therefore making them unusable for programming purposes. I realize that these do not respond to a query command, but these never update when heating or cooling is called for by either the ISY or the thermostats. I would question the thermostat if the issue was limited to only one of the thermostats. I seem remember that these fields populated when I first installed the thermostats. I have subsequently updated the ISY firmware a couple of times - currently running v.4.2.30. Any ideas how I can get the ISY to populate these values? If I initiate cooling manually on TH thermostat, and observe received events on the ISY, I receiver CLISPH 134 followed by CLISPC 154 which indicate the changes in setpoints, but I do not receive anything reporting a change in control state. Is there anything I need to set at the thermostat to cause these states to report? Many thanks, Pete