-
Posts
119 -
Joined
-
Last visited
Everything posted by vspete
-
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 @bpwwer. When I started the admin console this AM I noticed that the polyglot client side had been updated. Going to the Polyglot cloud dashboard, I further noticed that the launching of the admin council had stopped and restarted the node server as well. All good now and I am getting a much better understanding of how everything works....
-
@bpwwer - Thanks for the suggestion. Unfortunately "pressing the update the profile" button did not change the screen or correct the labels as expected in version 1.0.12. Looks like this is a Polyglot Cloud issue.
-
I have been unable to update the Aeris nodeserver from 1.0.10 to 1.0.12 by starting and stopping the server (as described in the documentation and elsewhere on the forum). The version number does not update on the dashboard (which is supposed to be a known bug). If the node server has indeed updated, it HAS NOT downloaded updates (or replaced the client side code) to (on) my ISY, because the 1.0.12 bug fixes are not visible on my ISY. When shutting down and restarting the node server, the node removal messages do occur and the realtime log starts over. No apparent changes on the ISY side are visible however. Running ISY 5.2.0 firmware & UI. I attempted to update the Purple Air Node server from 1.0.3 to 1.0.4, by stopping and starting the service, but I cannot determine that it actually updated (version number is unchanged.) In the past, I have only seen node changes on the ISY client side occur when the node server is DELETED from the dashboard. Deleting a node server on the dashboard totally removes everything from the ISY (client) side. Deleting a node server therefore requires complete re-customization and re-programming on the ISY. I would not like to have to DELETE and REINSTALL node servers every time they are updated on the cloud. I hope this isn't required.
-
Hi Bob, Access to Aeris Data is available for free if you publish your weather station data to PWS Weather. All your questions about that can be found here: https://www.pwsweather.com/frequently-asked-questions. Once you begin publishing to PWS Weather, you are granted a free Aeris Contributor Plan subscription which is needed to use the Aeris Polyglot Nodeserver. You will need to limit your API calls to < 1000 per day by setting the polling times (to stay within the restrictions of the free plan). I use 300 for short (weather poll) and 600 for long (forecast poll) . The node server makes 2 API calls for weather and 1 API call for each forecast day node. These polling times work out to 700 API calls per day for me (weather plus forecasts for today and tomorrow). Weather data is therefore updated to my ISY every 5 minutes and forecast data every 10 minutes. I have found the forecasts provided by AERIS to be much more accurate than those from Weather Underground for my particular location.
-
Just wish to express my appreciation for all the development work being done in this area. After trying several weather node servers, I found the AERISWeather worked the best for me. To better understand the relationship between the various climate fields returned in the forecast data, I found the following link helpful: https://www.aerisweather.com/support/docs/api/reference/weather-codes/. Two small nits to report in the translation of the coded weather reports that the Aeris service provides (Polyglot Version 1.0.10). Climate Coverage shown in ISY as "difinite" should be "definite" and Climate Intensity currently shown as "N/A" should be "Moderate" Thanks again to Bob Paauwe for developing and maintaining this excellent NodeServer.
-
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