vspete

My issue with this is that I am unable to reduce the shortpoll time below 10 minutes (600 seconds) to remain compliant with PurpleAir API polling restrictions. I hope that this can be addressed. I will also comment about node servers in general: It is my observation that they are not robust in reporting that they have stopped updating IoX. They just stop and the only way to see if they are running is to look at the log and observe that IoX updates are actually happening. To do this requires monitoring the log in debug mode. For the Purple Air node server that means opening the log and watching it for 10 minutes. Or doing a restart just in case. I am not saying there is a particular issue with the PurpleAir node server, it seems to be the case with generally. The node server reports whether or not it is connected to the eISY, but not whether its program is updating its nodes.

Hi @bpwwer, I recently updated to the PG3x version of this node server and observed that I can use my sensor's local IP addresses in lieu of API calls to Purple Air's servers. I would like to do this for both of my sensors. When i attempt to use local IP's for both, only one of the sensors is being updated. I can use a local for one and access PurpleAir for the other. This seems strange, can you confirm that it is not possible to locally connect to more than one sensor? Thanks in advance...

Thanks for the detailed information regarding zone status communication. I did program my panel per the EnvisaLink instructions. As I indicated, I would try running the node server WITHOUT using the "smartzonetracking" option. I shortened the "shortpoll" time from 30 to 10 seconds giving me an average 5 second response time. This level of responsiveness is just fine and I have yet to experience the node server becoming non-responsive. I appreciate your offer to troubleshoot the smartzonetracking issue. My situation is probably an outlier based on multiple zones being triggered at virtually the same time on a regular basis. If it would help you, I can re-enable smartzonetracking and run it with Debug-level logging set in the PG3 dashboard until the error condition occurs, then send you the plugin log file. Thanks again.

Yes, I have had "SmartZoneTracking" enabled while experiencing this issue. I haven't experienced any issues overnight when the motion detectors are not being frequently triggered. When walking through the house, one can trigger multiple zones in an overlapping fashion, viz., a motion zone is triggered while another motion zone has yet to no longer sense motion. The most disturbing thing is that when a wired exit zone is also "opened" the administrative console shows that zone as open even after it is closed (and system not ready). The console, EzeOn App, and Total Connect App show everything okay and ready to arm. As for connectivity: the eISY and EnvizaLink communicate via a wired LAN. Viewing the node server log, is not throwing any errors and seems to indicate that no change is occuring. Also, the log shows that only the first 16 zones are being "set." All motion detectors are in zones 3-7. Bypassing, a zone higher that 16 does correctly report its condition. As of this morning, I have disabled "SmartZoneTracking" to see if that makes a difference. Thanks...

Hi @joeria, yes you would need the installer code to make some adjustments. As far a privacy, once you have updated the firmware in th EnvisaLink, you can restrict access to only your LAN or specifically to your eISY only. Access to the internet is not required for functionality. You will find this solution to behave much like the Vista panel did using X10 signalling. Good luck, I hope someone will be able to diagnose and update the Total Connect node server to work with the current PG3x.

First, I love this node server when it is working. I am using a HW Vista Panel with 24 zones and 1 partition. When first started the panel and all 24 zones report correct status and update status in a timely manner. My system has 5 motion detectors. After some random number of hours (less than a day), the motion detectors stop updating their status and remain showing an "open" condition. Occasionally, an exit door status will freeze reporting an "open" state despite being closed. The node server partition status reports "not ready" when any of the zones report an "open" condition. The panel console, Eon App, and Total Connect all show the panel status to be "ready" Restarting the node server clears this condition and we start fresh. My suspicion is that the frequency of Motion triggers and potential overlap with processing zone updates is causing the issue. I believe that Total Connect and Eon do not use motion zones to determine whether the panel can respond to commands. The Eon App shows motion detectors to be open for a long time following a trigger. Any help with this issue will be greatly appreciated. Thanks in advance....

Hi, You might find this message from the Node Server author. I don't believe he is still active (maintaining this Node Server). I have abandon using Total Connect in favor of EnvisaLink-HW. https://forum.universal-devices.com/messenger/10289/

Update: Looks like the panel status (disarmed/armed, etc.) is being retrieved and updated per the short poll time. The individual zones are not being discovered or updated. Not the end of the world for me. Unfortunately, the pulldown menu for eisy v5.8.0 programming for possible "armed status" conditions is incomplete (or in error). Per security_panel_node.py, the options should be for UDM 25 values (only the bold ones are available): armStatusMap = { ArmStatus.DISARMED: 1, ArmStatus.DISARMED_BYPASS: 2, ArmStatus.ARMED_AWAY: 3, ArmStatus.ARMED_AWAY_BYPASS: 4, ArmStatus.ARMED_AWAY_INSTANT: 5, ArmStatus.ARMED_AWAY_INSTANT_BYPASS: 6, ArmStatus.ARMED_CUSTOM_BYPASS: 7, ArmStatus.ARMED_STAY: 8, ArmStatus.ARMED_STAY_BYPASS: 9, ArmStatus.ARMED_STAY_INSTANT: 10, ArmStatus.ARMED_STAY_INSTANT_BYPASS: 11, ArmStatus.ARMED_STAY_NIGHT: 12, ArmStatus.ARMING: 13, ArmStatus.DISARMING: 14, ArmStatus.ALARM: 15, ArmStatus.ALARM_FIRE: 16, ArmStatus.ALARM_CARBON: 17, ArmStatus.UNKNOWN: 18 The pull down menu offers: Alarm Cancelled (Alarm_Fire ?) Unknown (Alarm_Carbon ?) 18 (Unknown ?) I don't have any experience coding node servers, but am willing to give it try. First I need to find where the node server code is that defines the pulldown menu. I cannot seem to locate the node server source code file. Thanks for any suggestions.

Migrated from isy 5.x.x and PGC2 to above now receive node discovery failure on polyglot. Connected standalone PG2 to eisy after migration first and had the same problem (using existing slot). Upgraded node server (same slot) same error. Installed in new slot received the same error. Note: I have never specified (or needed) a panel user code for the "user" used for ISY access. 2024-01-26 06:59:47,422 Thread-2 root WARNING TotalConnectClient:populate_details: No usercode for location ######. 2024-01-26 06:59:58,436 Thread-2 udi_interface ERROR totalconnect-poly:discover: Discovery failed with error Missing element isSceneZones (GetPanelMetaDataAndFullStatusEx_V1.isSceneZones) Traceback (most recent call last): File "/var/polyglot/pg3/ns/0021b902625c_5/totalconnect-poly.py", line 157, in discover self.add_security_device(loc_id, loc_name, device, update) File "/var/polyglot/pg3/ns/0021b902625c_5/totalconnect-poly.py", line 176, in add_security_device panel_data = self.tc.soapClient.service.GetPanelMetaDataAndFullStatusEx_V1(self.tc.token, loc_id, 0, 0, 1) File "/usr/local/lib/python3.9/site-packages/zeep/proxy.py", line 46, in __call__ return self._proxy._binding.send( File "/usr/local/lib/python3.9/site-packages/zeep/wsdl/bindings/soap.py", line 123, in send envelope, http_headers = self._create( File "/usr/local/lib/python3.9/site-packages/zeep/wsdl/bindings/soap.py", line 73, in _create serialized = operation_obj.create(*args, **kwargs) File "/usr/local/lib/python3.9/site-packages/zeep/wsdl/definitions.py", line 224, in create return self.input.serialize(*args, **kwargs) File "/usr/local/lib/python3.9/site-packages/zeep/wsdl/messages/soap.py", line 79, in serialize self.body.render(body, body_value) File "/usr/local/lib/python3.9/site-packages/zeep/xsd/elements/element.py", line 232, in render self._render_value_item(parent, value, render_path) File "/usr/local/lib/python3.9/site-packages/zeep/xsd/elements/element.py", line 256, in _render_value_item return self.type.render(node, value, None, render_path) File "/usr/local/lib/python3.9/site-packages/zeep/xsd/types/complex.py", line 307, in render element.render(node, element_value, child_path) File "/usr/local/lib/python3.9/site-packages/zeep/xsd/elements/indicators.py", line 256, in render element.render(parent, element_value, child_path) File "/usr/local/lib/python3.9/site-packages/zeep/xsd/elements/element.py", line 226, in render self.validate(value, render_path) File "/usr/local/lib/python3.9/site-packages/zeep/xsd/elements/element.py", line 284, in validate raise exceptions.ValidationError( zeep.exceptions.ValidationError: Missing element isSceneZones (GetPanelMetaDataAndFullStatusEx_V1.isSceneZones) Any help would be appreciated. Thanks, Pete

@Michel Kohanim, thanks for the update. I have been using both "Isy js" and "Isy Maker" on Homebridge to provide homekit support for everything running on the isy (now eisy). I am looking forward to a native solution and one that hopefully doesn't require using state variables to interface with isy/eisy programs. Thanks for all your efforts. BR/Pete

@Geddy, I was aware of the iOS privacy notification issue posted by @InsteonNut. That wasn't the issue in my case. My iPhone Mobilinc iOS connection issue was tied to the iWatch Mobilinc extension. The iWatch extension is not usable since the iOS 14.3 update. Since that update, Apple appears to require iPhone app to be successfully authenticated to the host before the iWatch extension can be used (when host authentication is required). Most iWatch apps (such as MyQ) require the iphone app to be logged in while the iWatch app is used. If not, the user is told by the watch that this is a requirement. In the case of the TC2 iWatch extension, the watch provides a sign-in button on the watch. The Mobilinc iWatch extension does not appear to recognize this change and somehow locks up both the iWatch extension and iPhone app in a condition fraught with connection issues when the iWatch extension is used. The only solution that worked for me is to NOT install the Mobilinc iWatch extension. When not installed, the iPhone app works just fine. Also, I haven't had any issues with my 5 node servers other than Mobilinc does not have an appropriate UI to effectively use them. Thanks for posting your suggestion..

Thanks @Whitehambone! I am okay with the SSL performance as I seldom use it to access my ISY. Most accesses are from the LAN side and are not encrypted beyond the WiFi connection. My server remote desktop, security NVR, cameras, etc., all require a VPN connection through the Fortigate when accessed from the Internet.

@Whitehambone, I run a Fortigate 60D POE at home and will be unable to upgrade the firmware beyond v6.0.xx due to hardware limitations. I think you will find that the issues are associated with the Mobilinc iWatch extension. I have abandoned being able to use Mobilinc with iWatch totally and now have zero Mobilinc connection issues on the iPhone. Apple has made significant security changes on iOS that have resulted in usability issues. For example, I find using my iWatch to control my garage door opener (MyQ) or Alarm System (TC 2.0) no longer useful. Since the last iOS upgrade, these iWatch apps regularly will not connect and show that logging into the respective accounts using the iPhone app is required prior to working. When I say regularly, I mean at least once a day and randomly. As you must retrieve the iPhone and do this step, the convenience using the iWatch App is completely lost. And the experience just serves as a frustration. I just noticed that my Powerview (Hunter Douglas Shades) will not show scenes on my iWatch. This is new, they are properly selected in the iPhone app. Mobilinc Pro is no longer being updated by its developer, so it is what it is.

I am running FortiOS v6.0.10 build0365 (GA) and haven't updated the firmware for several months. I did upgrade my ISY security cert due to its expiration. When I removed Mobilinc from my iPhone and reinstalled, it would not work with the expired cert. I created the new cert with a 2048 bit key (the old one used a 512 bit key). This is when I noticed increased delay in connecting when https was used. I have tested connecting securely connecting via both LAN and WAN. There wasn't any noticeable difference. To my knowledge, the Fortigate only plays a role when a WAN connection is used. I haven't noticed any performance hits with the level of FortiOS I am running. I hope this helps.

Thanks @InsteonNut I can confirm that NodeServers DO NOT use this pool. When I logged into this pool, no subscriptions were in use. When I opened Mobilinc on the iphone, it immediately took a slot. The slot was released when the app was closed. If the app was just placed into background, it held the slot until something timed out. Tried this numerous times always behaved the same way. When opening the iwatch app, things are less predictable. Sometimes it gets one slot and later gets a second slot. Sometimes when I open iwatch app, I am able to control a device with the watch (the watch display sometimes accurately displays status and sometimes it doesn't.) I have also been able to open the iWatch App and use it successfully with no subscription slots shown to be in use (yes, I refreshed the browser many times - no change - no subscriptions in use). I have seen one one subscription when the iphone app and iwatch apps are both open and sometimes I have seen two subscriptions. I have never seen more that 2 of the 10 subscriptions used at the same time. I do not have the console open. I do believe that something in the Apple world has changed. It may be iOS 14.3 or possibly iWatch 7.2. These updates were released at about the same time. Apple has been making changes to improve security which may be an issue. A number of my iWatch apps (MyQ, TC2.0) for example, now frequently require me to open and authenticate the iphone app prior to allowing the iwatch app to connect to the service. I believe this requirement is relatively new and clearly detracts from the convenience of the iWatch app due to both the frequency and unpredictability of needing to open the phone app. Coupled with having to remove the phone from one's pocket and either removing a mask for facial recognition and/or typing a long password into the iphone in order to launch the iphone app as a prerequisite to allowing the iwatch app to operate is quite annoying. Don't know if this has any relation to the behavior issues we are experiencing with Mobilinc, but things are different. Thanks again for helping me understand better what is going on.

@asbril, thanks for trying. When I first try an action on the iWatch, it works. It is when I try multiple actions over a relatively short period of time that causes issues. Also I have notice that sometimes when I would select the app in the watch dock it would already be displaying a connection issue that must have occured in the past. I think Wes may by on the right track in my case so I will address his comments. @InsteonNut , thanks for the recommendations. I think we may be closing in on the issue. 1. I appreciate the additional time associated with the 2048 bit handshake. I accept that when using https. It is either that or establishing a VPN connection to my Fortigate and then going http. 2. I have set mobilinc to http (only). For the testing and reporting these connection issues. 3. My watch has been running v7.2 (the latest), since it was released. I think your discussion regarding subscription channel slots and their "release" may be where the issue is. My ISY is running firmware 5.2.0. It was my understanding that the number of "slots" available (at least for Nodeservers), has been greatly increased sometime in the recent past. I currently connect to 5 nodeservers, mobilinc, watch, admin console. My nodeservers are hosted locally and I receive a text message if any of their connections go offline (this does not happen unless I do it deliberately). However, I am not particularly careful in fully terminating the Mobilinc App and it sometime is left running on my iPhone. The iWatch connection appears to not terminate fairly frequently (until it times out - 10 minutes as you suggest??). I say this, because I can fire up the watch, successfully turn on a scene and go back to watch face. A minute or so later if I go to the watch app and attempt to turnoff the scene, there is no response for 10s of seconds. If I attempt to connect to the ISY via the phone app, It hangs and doesn't display the dashboard until the scene eventually responds to the watch command. The lack of reasonable responsiveness causes me to repeat commands to the watch which probably overflows queues and/or cause other issues. Addendum: I just entered a room that had an insteon device that was on. I opened the iwatch app and it showed the scene as off. After about 10 seconds the iwatch app crashed (closed itself), I didn't touch the watch screen. I reopened the iwatch app and it correctly displayed the device status and didn't crash.

@InsteonNut I am connecting direct to my ISY on both the local network (HTTP) and remotely (HTTPS). Both are working fine from Mobilinc Pro on iOS 14.3. Since the iOS 14.3 upgrade, any attempt to use the iWatch extension causes connection problems. After removing (not using) the iWatch extension, these issues no longer cause the app to have connection issues. I have not tried Mobilinc Connect as I have a ISY portal account and understand I can use only one or the other. My network services license I believe is bundled with my ISY Portal account. I prefer direct connection to ISY (local or port forwarded through my router). I have only seen the "subscription" issue once. One reboot of the ISY eliminated this issue. In terms of behaviors, when I connect via HTTPS from Mobilinc it takes more time to establish a connection and refresh the dashboard. I expect this is due to my use of a 2048 bit encryption key in my certificate (it seemed to go faster when the key was only 512). I do believe the connectivity issue I have been experiencing is related to using the Mobilinc Pro iWatch extension.

@asbril, I have determined that the issues that prompted this topic are associated with using the Mobilinc iWatch extension after the 14.3 iOS update. Just to confirm, did you test Mobilinc Pro on your iWatch? I will review Home Assistant as a possible Mobilinc alternative. Thanks...

Hi Bob, I agree with Andrew regarding having the date of last update for any weather nodeserver (or any sensor nodeserver for that matter) available in the ISY data. While connection to polyglot is always reported, however, data can become stale if connectivity to the originating service is lost. If the nodeserver connection is lost, the ISY has no way of knowing when the nodeserver went down and therefore whether the data the ISY has is still of any use. Just a thought... Happy New Year and thanks for your diligent efforts.

@DennisCthe VM hosting Debian 10 / Polyglot has been up about a week. Don't think the issues being discussed here relate to the Nodeserver as it is spitting out data to the ISY continuously around the clock and not generating any correlatable errors in the ISY log (now that all nodeservers have their ISY logging set to either off or error only). Below is the a snapshot of my ISY error log taen at 10:59 AM this morning. What is notable is how the lack of error activity since 9PM last evening. There are ISY programs running after 9PM sending out commands during this period of zero errors logged, but no devices changed their state as a result of the insteon commands sent. Mobilinc was not used between 9PM & 10:59AM. The -140005 Net Module Rule: 3 message at 4:56PM corresponds to the ISY turning the front lights on at sunset and then off at 9PM based on program action. Mobilinc was used from the iPhone at the times associated with -170001 errors shown last evening. These are associated with turning various scenes containing insteon devices on or off and/or dimming a number of scene members using the Mobilinc Pro app on the iPhone. I am beginning to believe the RSubs seem to relate to specific scenes or devices being controlled by Mobilinc. While these errors are being logged, the Mobilinc connections were responsive and the devices responded without issue. Sat 2021/01/02 04:56:38 PM System -140005 Net Module Rule: 3 Sat 2021/01/02 05:06:47 PM System -170001 [UDSockets] RSub:28 error:6 Sat 2021/01/02 05:06:47 PM System -170001 [UDSockets] RSub:33 error:6 Sat 2021/01/02 05:06:47 PM System -5012 56 Sat 2021/01/02 05:06:47 PM System -5012 57 Sat 2021/01/02 05:15:37 PM System -170001 [UDSockets] RSub:19 error:6 Sat 2021/01/02 05:15:42 PM System -170001 [UDSockets] RSub:19 error:6 Sat 2021/01/02 05:15:47 PM System -5012 58 Sat 2021/01/02 05:18:47 PM System -170001 [UDSockets] RSub:16 error:6 Sat 2021/01/02 05:18:52 PM System -170001 [UDSockets] RSub:16 error:6 Sat 2021/01/02 05:18:57 PM System -170001 [UDSockets] RSub:16 error:6 Sat 2021/01/02 05:19:01 PM System -5012 59 Sat 2021/01/02 05:20:24 PM System -5012 60 Sat 2021/01/02 05:20:24 PM System -5012 61 Sat 2021/01/02 05:21:03 PM System -170001 [UDSockets] RSub:20 error:6 Sat 2021/01/02 05:21:03 PM System -170001 [UDSockets] RSub:30 error:6 Sat 2021/01/02 05:21:05 PM System -5012 62 Sat 2021/01/02 05:21:05 PM System -5012 63 Sat 2021/01/02 05:21:43 PM System -170001 [UDSockets] RSub:27 error:6 Sat 2021/01/02 05:21:48 PM System -170001 [UDSockets] RSub:27 error:6 Sat 2021/01/02 05:21:53 PM System -170001 [UDSockets] RSub:27 error:6 Sat 2021/01/02 05:21:58 PM System -5012 64 Sat 2021/01/02 05:22:50 PM System -170001 [UDSockets] RSub:16 error:6 Sat 2021/01/02 05:22:50 PM System -170001 [UDSockets] RSub:20 error:6 Sat 2021/01/02 05:22:51 PM System -5012 65 Sat 2021/01/02 05:22:51 PM System -5012 66 Sat 2021/01/02 05:23:40 PM System -170001 [UDSockets] RSub:16 error:6 Sat 2021/01/02 05:23:45 PM System -170001 [UDSockets] RSub:16 error:6 Sat 2021/01/02 05:23:50 PM System -170001 [UDSockets] RSub:16 error:6 Sat 2021/01/02 05:23:55 PM System -170001 [UDSockets] RSub:16 error:6 Sat 2021/01/02 05:23:59 PM System -5012 67 Sat 2021/01/02 05:24:50 PM System -5012 68 Sat 2021/01/02 07:19:09 PM System -5012 70 Sat 2021/01/02 07:41:55 PM System -170001 [UDSockets] RSub:31 error:6 Sat 2021/01/02 07:42:00 PM System -170001 [UDSockets] RSub:31 error:6 Sat 2021/01/02 07:42:05 PM System -5012 71 Sat 2021/01/02 08:06:13 PM System -5012 72 Sat 2021/01/02 08:08:41 PM System -5012 73 Sat 2021/01/02 09:00:03 PM System -140005 Net Module Rule: 3 Sun 2021/01/03 04:05:18 AM System -10 n/a Sun 2021/01/03 05:03:01 AM System -60006 n/a I haven't had any problems with connectivity since i removed the Mobilinc iWatch app. I now believe that the iOS 14.3 update has made the iWatch app effect both its own and the iphone apps connectivity to the ISY. To avoid connectivity/responsiveness issues, I will not be using the iWatch app going forward.

Here is the continuation of the log since the entries above: Sat 2021/01/02 12:22:04 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 01:12:53 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 01:25:21 PM System -5012 43 Sat 2021/01/02 03:20:23 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 03:25:24 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 03:30:24 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 03:40:23 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 03:41:49 PM System -5012 44 Sat 2021/01/02 03:45:21 PM System -5012 45 Sat 2021/01/02 03:45:23 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 03:50:23 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 03:55:23 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:00:24 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:02:02 PM System -5012 46 Sat 2021/01/02 04:05:24 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:10:24 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:20:24 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:21:38 PM System -170001 [UDSockets] RSub:25 error:6 Sat 2021/01/02 04:21:38 PM System -170001 [UDSockets] RSub:33 error:6 Sat 2021/01/02 04:21:43 PM System -5012 48 Sat 2021/01/02 04:21:43 PM System -5012 49 Sat 2021/01/02 04:24:03 PM System -170001 [UDSockets] RSub:25 error:6 Sat 2021/01/02 04:24:08 PM System -170001 [UDSockets] RSub:25 error:6 Sat 2021/01/02 04:24:08 PM System -5012 50 Sat 2021/01/02 04:25:24 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:25:53 PM System -5012 51 Sat 2021/01/02 04:25:53 PM System -5012 52 Sat 2021/01/02 04:27:58 PM System -5012 53 Sat 2021/01/02 04:30:23 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:35:23 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:36:22 PM System -170001 [UDSockets] RSub:33 error:6 Sat 2021/01/02 04:36:27 PM System -170001 [UDSockets] RSub:33 error:6 Sat 2021/01/02 04:36:32 PM System -170001 [UDSockets] RSub:33 error:6 Sat 2021/01/02 04:36:37 PM System -170001 [UDSockets] RSub:33 error:6 Sat 2021/01/02 04:36:42 PM System -5012 54 Sat 2021/01/02 04:40:24 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:45:24 PM System -140005 Net Module Rule: 8 Sat 2021/01/02 04:56:38 PM System -140005 Net Module Rule: 3 Sat 2021/01/02 05:06:47 PM System -170001 [UDSockets] RSub:28 error:6 Sat 2021/01/02 05:06:47 PM System -170001 [UDSockets] RSub:33 error:6 Sat 2021/01/02 05:06:47 PM System -5012 56 We now are getting net module rule 8 and 3 entries. No more net module #4. The UDSocket errors have returned and can be linked to attempts (ultimately successful) to control one dimmer device and one scene using the iWatch. I didn't use the iPhone app to control anything during the afternoon, so no idea if it would throw a UDSocket error. No issue with the iphone app connecting to the isy on numerous tries during the afternoon. No more information to report.

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 ##