johnnyt

Hi, I'm using 994i and see lots of PG3 errors and encounter general struggles whenever I restart a NS, and especially so when I restart Polisy which restarts *all* the NS at once. For my testing and log capture today, I first made sure things were stable and ISY was not particularly busy. I then restarted just WeatherFlow NS. I did same with Airthings NS (with a break in between). Attached are PG3 logs showing entries immediately following the WeatherFlow restart, along with the NS logs for it for the same period. Also attached are the PG3 logs for Airthings to show how both have some similar struggles (> 5000ms, retries, aborts, etc.) I removed (substituted) my ISY ID and any references to API keys thinking it's not a good idea to broadcast that info. For the record, I do always have a number programs running on ISY but they are just 60 sec. counters, which, hopefully is not consuming much ISY CPU but if that's the case (and I'm really wondering if it is) let me know because I always have some counters running, e.g. If 'HVAC / Venting-Humidity / 1-Fan High Relay' Status is On Then Repeat Every 1 minute $iHVAC.Count.FanHigh += 1 I also made sure to put some "wait" commands in any ISY programs that act on Weatherflow data to at least spread the load out on the ISY side. I'd rather be able to throttle the NS/PG3 if that was possible. What else can I do? Do all the errors/delays suggest a busy ISY or is there something else, like network collisions or something, that could be causing them? I think I asked a while back and the answer was 'no' but in latest version of PG3 is there a way to control NS startup, e.g. set order and delay between them, and/or a way to stop/start NS from ISY? Is that something that could be added in the future? Any info would be appreciated WeatherFlowLogs.zip

So bottom like seems to be that the errors I had are ST-Inventory NS related, which means I posted in the right place. In fact there many unhandled errors in the NS log. See attached sample. Now how does one get the NS Developer to chime in? ST-Inventory_10-31-2022_113836-AM.zip

I recently reset/moved/renamed a couple of my devices but NS is still using old name. I do see in the logs (after restart) that the NS noticed the new name but didn't change it in "Nodes" nor ISY to match. In fact it makes that point right in the log entry. 2022-11-11 10:09:36,383 Thread-11 udi_interface WARNING Controller:add_node: Existing node name 'Furnace Room' for s_2930206779 does not match requested name 'HRV Out', NOT changing to match 2022-11-11 10:09:36,384 Thread-11 udi_interface.interface INFO interface:addNode: Adding node Furnace Room(s_2930206779) [None] Can this be fixed to change the node name when the airthings device name is changed? I did find I could manually change the ISY node names and it seems to work in ISY but NS "Nodes" page still uses the old names. Over time this could make troubleshooting more difficult/prone to errors. As I assume it's just a label, i.e. not the underlying device or node ID that both NS and ISY uses, I'm thinking it shouldn't break ISY programs relying on one or more of the devices' sensors. Is that correct? I don't have any programs associated with the devices I moved so can't tell but figure you would know based on how things work under the covers. If you don't, I could do maybe test it. Thanks for considering it.

Ok, thanks @bpwwer So the only remaining question I have is related to feature request regarding having been prevented from installing ST-Inventory in slot 1 when it was already in slot 7. Is this something the NS has to check for, or can/should PG3 provide that check for all? Just to elaborate/illustrate. Attached is screenshot of 994i dashboard showing NS in slots 1, 4, 5, 6, 7, 8, followed by the NS Store Install view for IoP, which has same NS as 994i in slots 4, 6, 7 so those are blocked. But not blocked are slots 1, 5, and 8 and I can install whatever I want there. For example I was able to install Envisalink DSC in slot 1 (which is in slot 5 for 994i). Unlike when I installed ST-Inventory in slot 1, this one did not generate any errors in log. Not sure if that's a good thing or a bad thing but it isn't the behavior mentioned below: I didn't go so far as to check what happens if I configure and try to use Envisalink NS with IoP but not sure testing this would be reliable as there may be conflict (some or all the time) logging into the panel since the 994i NS also needs to connect to only panel I have to test this with. (With ST Inventory I had two separate ISY instances to point to).

So I can't make heads or tails between before and after upgrade logs. There are so many log entries pre upgrade. My log files are all close to 60MB prior to upgrade. Since upgrade they're about 1-1.3MB. I think log level was "Debug", now it's "Info". There is a set of entries that I'd like to know what they mean. 11/6/2022, 19:14:14 [pg3] info: ISY node server user configuration update required <my 994i ID> vs <myIoP ID> 11/6/2022, 19:14:14 [pg3] info: ISY node server user configuration update required <my 994i ID> vs <myIoP ID> 11/6/2022, 19:14:14 [pg3] info: ISY node server user configuration update required <my 994i ID> vs <myIoP ID> 11/6/2022, 19:14:14 [pg3] info: ISY node server user configuration update required <my 994i ID> vs <myIoP ID> 11/6/2022, 19:14:14 [pg3] info: ISY node server user configuration update required <my 994i ID> vs <myIoP ID> 11/6/2022, 19:14:14 [pg3] info: ISY node server user configuration update required <my 994i ID> vs <myIoP ID> I do have different IP addresses as well as userid/passwd between 994i and IoP. Is that what causes those messages? Why six times? FWIW, I have 6 NS on 994i dashboard with only 5 running (not running ST-Inventory), and 3 NS on IoP Dashboard with only 1 running (ST-Inventory)

ok , got in using ssh (I thought I had changed the password) and will look at the historical logs (/var/polyglot/pg3/logs) later to see what was maybe already an error pre-upgrade vs post-upgrade. Maybe the errors I saw post upgrade were already happening pre upgrade. I will hopefully be better able to explain the problem. I miss stated the feature request. what I wanted was to not be able to install ST-Inventory in slot 1 (which was free) when it was already installed in slot 7 as it resulted in the errors I reported here (and wasted a lot of time). That said, if this was/is just an issue with this NS and others could have multiple instances, this may be something for ST-Inventory to prevent, not PG3.

Ok, I think I may have found the problem. Or at least the one related to the recent log entries I posted. I think a while ago I removed a different NS in slot 1 for IoP. Then, when I encountered problems running ST-Inventory after the upgrade to PG3, I reinstalled it in slot 1 instead of slot 7, where it is for 994i. So I just uninstalled/installed the NS for IoP it in slot 7 to match the slot for 994i and it now works. But I don't think I have the complete story yet because, while I may have put the NS in a bad slot, I didn't just uninstall and reinstall the NS for no good reason. It was not working for some reason. I'm trying to go back to older PG3 log entries to get the complete story but am struggling to SSH into Polisy. Part of the problem is that I don't do it often anymore (since upgrades need to be done in AC for IoP. I can't login with the known/confirmed userid (admin) and password that I just re-typed into my PG3 "Profile" to be sure. Why isn't this working? Also, I will make a feature request here: Don't let people install different NS' in same slot, like it appears I was able to do. I may have more to come once I can go back to see how things looked before the upgrade...

I purchased a license of ST-Inventory a while back and it was running fine for both my 994i and IoP. Since upgrading to PG3 3.1.12, it refuses to work for IoP. It works fine for 994i. I've tried uninstalling and re-installing for IoP - no joy. When I go to the store and read "More Info" for it https://github.com/simplextech/pg3_docs/tree/main/ST-Inventory it appears to be the same version (1.08) but I don't see the same configuration options. Here's what I see for both 994i and IoP. Here are the PG3 log entries following the uninstall/install: 11/2/2022, 08:31:44 [pg3] info: [00:0d:b9:53:c7:dc_1] :: Installation Complete. Added 'ST-Inventory' to database... 11/2/2022, 08:31:44 [pg3] info: [00:0d:b9:53:c7:dc_1] 'ST-Inventory' installed into ISY successfully... 11/2/2022, 08:31:45 [pg3] info: startNs:: ST-Inventory 11/2/2022, 08:31:46 [pg3] info: startNs:: ST-Inventory is valid 11/2/2022, 08:31:46 [pg3] info: checkLicense:: ST-Inventory Valid perpetual license found. 11/2/2022, 08:31:46 [pg3] info: startNs:: ST-Inventory finished update check 11/2/2022, 08:31:46 [pg3] info: [ST-Inventory(1)] :: Starting Node server - Version 1.0.8 11/2/2022, 08:31:46 [pg3] info: startNs:: ST-Inventory updating database (enabled, timestarted) 11/2/2022, 08:31:47 [pg3] error: [ST-Inventory(1)] :: STDERR: /var/polyglot/pg3/ns/000db953c7dc_1/st-inventory.js:1 'use strict';const a1_0x37af3c=a1_0x1d18;(function(_0x2876b7,_0x35bf8f){const _0x25de5a=a1_0x1d18,_0x2951ea=_0x2876b7();while(!![]){try{const _0x3bcf70=-parseInt(_0x25de5a(0x18b))/0x1+-parseInt(_0x25de5a(0x178))/0x2+-parseInt(_0x25de5a(0x183))/0x3*(-parseInt(_0x25de5a(0x179))/0x4)+-parseInt(_0x25de5a(0x17f))/0x5+-parseInt(_0x25de5a(0x163))/0x6+parseInt(_0x25de5a(0x185))/0x7*(parseInt(_0x25de5a(0x182))/0x8)+parseInt(_0x25de5a(0x16f))/0x9;if(_0x3bcf70===_0x35bf8f)break;else _0x2951ea['push'](_0x2951ea['shift']());}catch(_0x471660){_0x2951ea['push'](_0x2951ea['shift']());}}}(a1_0x10f2,0x8a380));function a1_0x1d18(_0x59cac8,_0x6ee69f){const _0x10f24d=a1_0x10f2();return a1_0x1d18=function(_0x1d18a6,_0x401601){_0x1d18a6=_0x1d18a6-0x154;let _0x57df81=_0x10f24d[_0x1d18a6];return _0x57df81;},a1_0x1d18(_0x59cac8,_0x6ee69f);}trapUncaughtExceptions();const fs=require('fs'),markdown=require(a1_0x37af3c(0x186))[a1_0x37af3c(0x186)],AsyncLock=require(a1_0x37af3c(0x16c)),P 11/2/2022, 08:31:47 [pg3] error: [ST-Inventory(1)] :: STDERR: olyglot=require(a1_0x37af3c(0x172)),logger=Polyglot[a1_0x37af3c(0x164)],lock=new AsyncLock({'timeout':0x1f4}),ControllerNode=require(a1_0x37af3c(0x17d))(Polyglot);logger[a1_0x37af3c(0x17e)](a1_0x37af3c(0x156));const poly=new Polyglot[(a1_0x37af3c(0x18e))]([ControllerNode]);poly['on'](a1_0x37af3c(0x168),function(){const _0x2e09b6=a1_0x37af3c;logger[_0x2e09b6(0x17e)](_0x2e09b6(0x180));}),poly['on'](a1_0x37af3c(0x17a),function(_0x43f89e){const _0x2028ec=a1_0x37af3c,_0x1ccb2d=Object['keys'](_0x43f89e[_0x2028ec(0x177)])[_0x2028ec(0x16a)];logger[_0x2028ec(0x17e)]('Config\x20received\x20has\x20%d\x20nodes',_0x1ccb2d);if(_0x43f89e[_0x2028ec(0x166)]){poly[_0x2028ec(0x16d)]();const _0x3f1dab=fs[_0x2028ec(0x191)](_0x2028ec(0x165));poly[_0x2028ec(0x169)](markdown[_0x2028ec(0x18d)](_0x3f1dab['toString']()));if(!_0x1ccb2d)try{logger['info'](_0x2028ec(0x15e)),callAsync(autoCreateController());}catch(_0x55a676){logger[_0x2028ec(0x15b)](_0x2028ec(0x16e),_0x55a676);}}}),poly['on'](a1_0x37af3c(0x157),function(_0x186411){}),poly['on'](a1_0x37af3c(0x184),function(){const _0xf25299=a1_0x37af3c;try{const _0x1dac6e=poly['getNodes']();Object[_0xf25299(0x159)](_0x1dac6e)[_0xf25299(0x155)](function(_0x9d50f6){const _0x3812fc=_0xf25299;if(_0x3812fc(0x16b)in _0x1dac6e[_0x9d50f6]){let _0x399039=_0x1dac6e[_0x9d50f6][_0x3812fc(0x16b)]();_0x399039&&logger['info'](_0x3812fc(0x18f));}});}catch(_0xd9070d){logger[_0xf25299(0x15b)](_0xf25299(0x170),_0xd9070d);}}),poly['on'](a1_0x37af3c(0x17c),function(_0x55e57d){callAsync(doPoll(_0x55e57d));}),poly['on'](a1_0x37af3c(0x161),async function(){const _0x23116e=a1_0x37af3c;logger[_0x23116e(0x17e)](_0x23116e(0x17b)),poly[_0x23116e(0x161)]();}),poly['on']('delete',function(){const _0x2b5c57=a1_0x37af3c;logger[_0x2b5c57(0x17e)](_0x2b5c57(0x181)),poly[_0x2b5c57(0x161)]();}),poly['on'](a1_0x37af3c(0x18a),function(){const _0x5dcb65=a1_0x37af3c;logger['info'](_0x5dcb65(0x176));}),poly['on'](a1_0x37af3c(0x162),function(_0x2abf7e){const _0x3e1899=a1_0x37af3c;!_0x2abf7e[_0x3e1899(0x17a)]&&logger[_0x3e1899(0x189)]('Message\x20Received:\x20%o',_0x2abf7e);}),poly['on']('messageSent',function(_0x5ab640){const _0x39f2ec=a1_0x37af3c;logger['debug'](_0x39f2ec(0x192),_0x5ab640);});function a1_0x10f2(){const _0x323638=['200BvYpdz','309xrAFAR','discover','64491aqyjyO','markdown','message','controller','debug','mqttEnd','326716dXLHzf','ST-Inventory','toHTML','Interface','Discovering\x20Nodes','Error\x20creating\x20controller\x20node','readFileSync','Message\x20Sent:\x20%o','getNodes','forEach','Starting\x20Node\x20Server','customParams','newController','keys','Short\x20Poll:\x20Inventory','error','uncaughtException\x20REPORT\x20THIS!:\x20','uncaughtException','Auto-creating\x20controller','Long\x20Poll:\x20Inventory','Error\x20while\x20polling:\x20%s','stop','messageReceived','5325288KdUHTi','logger','./configdoc.md','isInitialConfig','Error\x20with\x20async\x20function:\x20%s\x20%s','mqttConnected','setCustomParamsDoc','length','onDiscover','async-lock','removeNoticesAll','Error\x20while\x20auto-creating\x20controller\x20node:','6689826FBIpFL','Discover\x20Failed:\x20%s','addNoticeTemp','polyinterface-v3','stack','acquire','Controller\x20node\x20initialized','MQTT\x20connection\x20ended.','nodes','488150hbanfE','42852yCDVZc','config','Graceful\x20stop','poll','./Nodes/ControllerNode.js','info','262975lyPzzH','MQTT\x20Connection\x20started','Node\x20Server\x20is\x20being\x20deleted'];a1_0x10f2=function(){return _0x323638;};return a1_0x10f2();}async function doPoll(_0x28d45c){const _0x1f0331=a1_0x37af3c;try{const _0x32724d=poly[_0x1f0331(0x154)]();await lock[_0x1f0331(0x174)](_0x1f0331(0x17c),function(){const _0x41b6ce=_0x1f0331;_0x28d45c?logger[_0x41b6ce(0x17e)](_0x41b6ce(0x15f)):(logger[_0x41b6ce(0x17e)](_0x41b6ce(0x15a)),Object['keys'](_0x32724d)[_0x41b6ce(0x155)](function(_0x20227a){const _0x1cf74e=_0x41b6ce;'onDiscover'in _0x32724d[_0x20227a]&&_0x32724d[_0x20227a][_0x1cf74e(0x16b)]();}));});}catch(_0x3ae021){logger['error'](_0x1f0331(0x160),_0x3ae021[_0x1f0331(0x187)]);}}async function autoCreateController(){const _0x463785=a1_0x37af3c;try{await poly['addNode'](new ControllerNode(poly,_0x463785(0x188),_0x463785(0x188),_0x463785(0x18c)));}catch(_0x39c08d){logger[_0x463785(0x15b)](_0x463785(0x190));}poly[_0x463785(0x171)](_0x463785(0x158),_0x463785(0x175),0x5);}function callAsync(_0x59259a){(async function(){const _0x34f693=a1_0x1d18;try{await _0x59259a;}catch(_0x25c0a7){logger[_0x34f693(0x15b)](_0x34f693(0x167),_0x25c0a7['message'],_0x25c0a7['stack']);}}());}function trapUncaughtExceptions(){const _0x5ea7d0=a1_0x37af3c;process['on'](_0x5ea7d0(0x15d),function(_0x494388){const _0xde4858=_0x5ea7d0;logger['error'](_0xde4858(0x15c)+_0x494388[_0xde4858(0x173)]);});}poly['start'](); ReferenceError: Cannot access 'logger' before initialization at process.<anonymous> (/var/polyglot/pg3/ns/000db953c7dc_1/st-inventory.js:1:5642) at process.emit (node:events:513:28) at process._fatalException (node:internal/process/execution:167:25) Node.js v18.7.0 11/2/2022, 08:31:47 [pg3] info: startNs:: ST-Inventory starting polls 11/2/2022, 08:31:47 [pg3] info: Starting Node server Info timer 0 11/2/2022, 08:31:51 [pg3] info: [00:0d:b9:53:c7:dc_1] Retrieved oauth 11/2/2022, 08:32:19 [pg3] info: upload successful 11/2/2022, 08:32:19 [pg3] info: upload successful 11/2/2022, 08:32:19 [pg3] info: upload successful 11/2/2022, 08:32:19 [pg3] info: startNs:: ST-Inventory 11/2/2022, 08:32:19 [pg3] info: startNs:: ST-Inventory is valid 11/2/2022, 08:32:20 [pg3] info: checkLicense:: ST-Inventory Valid perpetual license found. 11/2/2022, 08:32:20 [pg3] info: startNs:: ST-Inventory finished update check 11/2/2022, 08:32:20 [pg3] info: [ST-Inventory(1)] :: Starting Node server - Version 1.0.8 11/2/2022, 08:32:20 [pg3] info: startNs:: ST-Inventory updating database (enabled, timestarted) 11/2/2022, 08:32:21 [pg3] info: startNs:: ST-Inventory starting polls 11/2/2022, 08:32:21 [pg3] info: Starting Node server Info timer 0 11/2/2022, 08:32:22 [pg3] error: MQTTS: ClientID: 00:0d:b9:53:c7:dc_1 is already connected. Disallowing multiple connections. 11/2/2022, 08:32:22 [pg3] error: MQTTS: clientError: 00:0d:b9:53:c7:dc_1 Auth Error I also get these - not sure if it's related. 11/2/2022, 08:34:42 [pg3] info: ISY node server user configuration update required <my 994i ID> vs. <my IoP ID> 11/2/2022, 08:34:42 [pg3] info: ISY node server user configuration update required <my 994i ID> vs. <my IoP ID> 11/2/2022, 08:34:42 [pg3] info: ISY node server user configuration update required <my 994i ID> vs. <my IoP ID> 11/2/2022, 08:34:42 [pg3] info: ISY node server user configuration update required <my 994i ID> vs. <my IoP ID> 11/2/2022, 08:34:42 [pg3] info: ISY node server user configuration update required <my 994i ID> vs. <my IoP ID> 11/2/2022, 08:34:42 [pg3] info: ISY node server user configuration update required <my 994i ID> vs. <my IoP ID>

I should add that I originally had the units (in Tempest) as "cardinal", e.g. NW, W, etc. and changed them to degrees without actually changing the action statement so maybe that's what caused this.

So I created a new program from scratch (no copying) to do the same thing and it works fine. There's actually a visible discrepancy between the old and the new "action" statement Here's the original action: $sWeatherStation.WindDirection = 'HVAC / Climate / WeatherFlow / ST-00061544' Wind Direction ° And here's the action for the new program: Check out the difference in last character. $sWeatherStation.WindDirection = 'HVAC / Climate / WeatherFlow / ST-00061544' Wind Direction So then I created a copy of the original program and it had the extra character too but when I changed the equation to a different data element and back again, the extra character was no longer there. Guessing this is a 1 in a million occurrence so won't both opening a ticket with UDI support but next time I have difficult to reconcile program logic I'll definitely look for this issue.

The NS config 'Rapid Wind' option is/has been false. I set to true and restarted NS. The wind reports certainly accelerated as seen in NS log updates but the variable doesn't change either automatically or when I 'run then' using this config.

No, running then is no different than runnin if. I have an all in one unit and looked again. don't see any option to change anything related to frequency of wind reports. I do know if the battery goes low, it will reduce itself to conserve energy from 3 secs to 6 secs to 1 min to 5 mins. https://help.weatherflow.com/hc/en-us/articles/360048877194-Solar-Power-Rechargeable-Battery

where do I see / change that? I looked through the settings but didn't find one for this. It looks like it's every 3 seconds just from watching changes. Ok I did that and ran it (if) which ran true and stayed true with no change to the variable. I think if this had been the issue, the timestamp for the variable would not still be the time from the last reboot 8 days ago.

Ok I changed the code and the error doesn't come up anymore, however the variable does not get set when it should. Here's the new program logic (0 is converted to "No Wind") If 'HVAC / Climate / WeatherFlow / ST-00061544' Wind Direction > No Wind Then $sWeatherStation.WindDirection = 'HVAC / Climate / WeatherFlow / ST-00061544' Wind Direction ° Else $sWeatherStation.WindDirection = 0 It evaluates True But the variable has not changed value since last reboot, when if was initialized to 0 Here's a sampling of WINDDIR values over the past few hours - none are 0 Wed 09/28/2022 05:12:34 AM : [ n006_207296 WINDDIR 359 (uom=76 prec=0) Wed 09/28/2022 05:17:32 AM : [ n006_207296 WINDDIR 352 (uom=76 prec=0) Wed 09/28/2022 05:19:30 AM : [ n006_207296 WINDDIR 350 (uom=76 prec=0) Wed 09/28/2022 05:25:27 AM : [ n006_207296 WINDDIR 352 (uom=76 prec=0) Wed 09/28/2022 05:27:27 AM : [ n006_207296 WINDDIR 359 (uom=76 prec=0) Wed 09/28/2022 05:28:30 AM : [ n006_207296 WINDDIR 337 (uom=76 prec=0) Wed 09/28/2022 05:33:23 AM : [ n006_207296 WINDDIR 348 (uom=76 prec=0) Wed 09/28/2022 05:39:21 AM : [ n006_207296 WINDDIR 348 (uom=76 prec=0) Wed 09/28/2022 05:40:20 AM : [ n006_207296 WINDDIR 335 (uom=76 prec=0) Wed 09/28/2022 05:43:47 AM : [ n006_207296 WINDDIR 344 (uom=76 prec=0) Wed 09/28/2022 05:53:43 AM : [ n006_207296 WINDDIR 358 (uom=76 prec=0) Wed 09/28/2022 06:02:37 AM : [ n006_207296 WINDDIR 357 (uom=76 prec=0) Wed 09/28/2022 06:06:35 AM : [ n006_207296 WINDDIR 343 (uom=76 prec=0) Wed 09/28/2022 06:10:38 AM : [ n006_207296 WINDDIR 352 (uom=76 prec=0) Wed 09/28/2022 06:12:32 AM : [ n006_207296 WINDDIR 335 (uom=76 prec=0) Wed 09/28/2022 06:18:29 AM : [ n006_207296 WINDDIR 358 (uom=76 prec=0) Wed 09/28/2022 06:35:20 AM : [ n006_207296 WINDDIR 352 (uom=76 prec=0) Wed 09/28/2022 07:14:38 AM : [ n006_207296 WINDDIR 343 (uom=76 prec=0) Wed 09/28/2022 07:19:34 AM : [ n006_207296 WINDDIR 357 (uom=76 prec=0) Wed 09/28/2022 07:22:34 AM : [ n006_207296 WINDDIR 339 (uom=76 prec=0) Wed 09/28/2022 07:26:31 AM : [ n006_207296 WINDDIR 346 (uom=76 prec=0) Wed 09/28/2022 07:30:21 AM : [ n006_207296 WINDDIR 335 (uom=76 prec=0)

The only thing I do with wind direction is a program is store it in a state variable, i.e. If 'HVAC / Climate / WeatherFlow / ST-00061544' Wind Direction >= -1° Then $sWeatherStation.WindDirection = 'HVAC / Climate / WeatherFlow / ST-00061544' Wind Direction ° Else $sWeatherStation.WindDirection = -1 That said, I see it isn't working. My state variable is '0' - the init value - and it hasn't changed since last reboot. Could it be because it tries to store the "degree" character too?

I'm seeing the following message in event viewer: Mon 09/26/2022 04:22:07 PM : [ n006_207296] WINDDIR 267 (uom=76 prec=0) Mon 09/26/2022 04:22:07 PM : [D2D*CMP 036F] STS [n006_207296] WINDDIR B Cannot convert values (from=0E to=4C) There is data in the GUI and it matches what the tempest shows so I'm not sure what the second message is all about.

Ok, I've restarted the other 2 node servers and will check periodically for full queue messages. This is a bit off topic but I notice that restarting a NS doesn't always update ISY for sometimes quite a while. If I understand correctly it's because the NS' retains the 'old' values and assumes ISY still has those values, and will only change them when it sees a change upstream in the value it has stored, e.g. from OpenWeatherMap. Is that right? If so, that's a bit of a problem when the whole point of a restart is to refresh things everywhere (in ISY too). I realize the benefit of the NS keeping score and not sending data ISY already has, especially at PG3/Polisy restart, but could the logic of doing an individual NS restart (not at PG3/Polisy level) be such that it refreshes the ISY data at startup? Or maybe a new button to call for a manual push of everything, need it or not and regardless of where in the polling delay things are?

So @bpwwer, does this mean the -170001 messages would not be related to queue(s) being full, and the other post is a totally separate thing going on? If so, how can we narrow down the root cause of the issues I ran into? Also, let me know if I should go ahead and start the other 2 node servers that are still stopped. Or maybe run them one at a time for a day or two each or something? Thanks.

So as suggested I stopped the 3 NS connecting to IoP, restarted IoP, waited a bit and started OpenWeatherMap NS (only). Here are the error log entries: Time User Code Message Mon 1900/01/01 12:00:00 AM System -170001 <s:Envelope><s:Body><u:GetSystemTime xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetSystemTime></s:Body></s:Envelope> Sun 2022/09/25 03:41:07 PM 0 -170001 <s:Envelope><s:Body><u:GetSystemOptions xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetSystemOptions></s:Body></s:Envelope> Sun 2022/09/25 03:41:08 PM 0 -170001 <s:Envelope><s:Body><u:GetNetworkConfig xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetNetworkConfig></s:Body></s:Envelope> Sun 2022/09/25 03:41:20 PM 0 -170001 <s:Envelope><s:Body><u:Reboot xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:Reboot></s:Body></s:Envelope> Sun 2022/09/25 03:41:23 PM 0 -5 Start Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/TMP Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/LOG Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/WEB Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CODE Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF/D2D Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF/MAIL Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/USER Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/USER/WEB Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF/NET Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF/SEP Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF/OADR Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF/BILLING Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF/DEF Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/GLOBAL Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/GLOBAL/i1 Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/GLOBAL/i1/nls Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/GLOBAL/i1/editor Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/GLOBAL/i1/nodedef Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/f1 Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/f1/i1 Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/f1/i1/nls Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/f1/i1/editor Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/f1/i1/nodedef Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/DEF/f1/i1/emap Sun 2022/09/25 03:41:23 PM 0 -110026 ./FILES/CONF/DEF/f10 Sun 2022/09/25 03:41:45 PM 0 -110022 ./FILES/CONF/INSTENG.OPT Sun 2022/09/25 03:41:45 PM 0 -110012 ./FILES/CONF/INSTENG.OPT Sun 2022/09/25 03:52:37 PM 0 -170001 <s:Envelope><s:Body><u:GetISYConfig xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetISYConfig></s:Body></s:Envelope> Sun 2022/09/25 03:52:41 PM 0 -170001 <s:Envelope><s:Body><u:Authenticate xmlns:u="urn:udi-com:service:X_Polisy_Service:1"><name>jean</name><id>11111</id></u:Authenticate></s:Body></s:Envelope> Sun 2022/09/25 03:52:41 PM 0 -170001 <s:Envelope><s:Body><u:GetStartupTime xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetStartupTime></s:Body></s:Envelope> Sun 2022/09/25 03:52:42 PM 0 -170001 <s:Envelope><s:Body><u:GetSysConf xmlns:u="urn:udi-com:service:X_Polisy_Service:1"><name>/CONF/INTEGER.VAR</name></u:GetSysConf></s:Body></s:Envelope> Sun 2022/09/25 03:52:42 PM 0 -170001 <s:Envelope><s:Body><u:GetSysConf xmlns:u="urn:udi-com:service:X_Polisy_Service:1"><name>/CONF/STATE.VAR</name></u:GetSysConf></s:Body></s:Envelope> Sun 2022/09/25 03:52:42 PM 0 -170001 <s:Envelope><s:Body><u:GetVariables xmlns:u="urn:udi-com:service:X_Polisy_Service:1"><type>1</type></u:GetVariables></s:Body></s:Envelope> Sun 2022/09/25 03:52:42 PM 0 -170001 <s:Envelope><s:Body><u:GetVariables xmlns:u="urn:udi-com:service:X_Polisy_Service:1"><type>2</type></u:GetVariables></s:Body></s:Envelope> Sun 2022/09/25 03:52:44 PM 0 -170001 <s:Envelope><s:Body><u:GetNodesConfig xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetNodesConfig></s:Body></s:Envelope> Sun 2022/09/25 03:52:47 PM 0 -170001 <s:Envelope><s:Body><u:GetSystemTime xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetSystemTime></s:Body></s:Envelope> Sun 2022/09/25 03:52:47 PM 0 -170001 <s:Envelope><s:Body><u:SetDebugLevel xmlns:u="urn:udi-com:service:X_Polisy_Service:1"><option>1</option></u:SetDebugLevel></s:Body></s:Envelope> Sun 2022/09/25 03:52:47 PM 0 -170001 <s:Envelope><s:Body><u:GetSystemOptions xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetSystemOptions></s:Body></s:Envelope> Sun 2022/09/25 03:52:48 PM 0 -170001 <s:Envelope><s:Body><u:Subscribe xmlns:u="urn:udi-com:service:X_Polisy_Service:1"><reportURL>REUSE_SOCKET</reportURL><duration>infinite</duration><send>F</send></u:Subscribe></s:Body></s:Envelope> Sun 2022/09/25 03:52:48 PM 0 -170001 <s:Envelope><s:Body><u:IsSubscribed xmlns:u="urn:udi-com:service:X_Polisy_Service:1"><SID>uuid:28</SID></u:IsSubscribed></s:Body></s:Envelope> Sun 2022/09/25 03:52:49 PM 0 -170001 <s:Envelope><s:Body><u:RefreshDeviceStatus xmlns:u="urn:udi-com:service:X_Polisy_Service:1"><sid>uuid:28</sid></u:RefreshDeviceStatus></s:Body></s:Envelope> Sun 2022/09/25 03:52:49 PM 0 -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetSystemStatus></s:Body></s:Envelope> Sun 2022/09/25 03:52:52 PM 0 -170001 <s:Envelope><s:Body><u:GetDisclaimerStatus xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetDisclaimerStatus></s:Body></s:Envelope> Sun 2022/09/25 03:53:31 PM 0 -170001 <s:Envelope><s:Body><u:GetErrorLog xmlns:u="urn:udi-com:service:X_Polisy_Service:1"></u:GetErrorLog></s:Body></s:Envelope> Right off the bat a bunch of -170001 errors, but no full queue messages Also, I should mention that the last time I did an 'upgrade package' (using IoP AC button) was about 10 days ago. Others seem to be mentioning very recent updates as maybe being part of the problem. Should I just go ahead and start the other NS' or is there something I should test (or wait to see) before I do that?

I'm not quite seeing the resemblance because I don't have any zwave devices or dongle (or Insteon PLM) so how could there be any events related to either? Plus I'm getting full queue messages. The error log for the other problem has none of those messages. That said I do have a lot of -17000 messages too (like the other one) so I will try was you suggested there, namely: and I'll keep tracking the other thread to see how that one evolves.

I've been testing my Polisy's IoP in preparation for migrating from 994i when the new Zwave/Matter dongle arrives along with the zwave migration tool in about 6-8 weeks. IoP is only running 3 node servers: OpenWeatherMap, Weatherflow and ST-Inventory. It has no PLM and no Zwave dongle connected to it, and the are no programs enabled/running so the only thing happening is that the Node Servers are doing their device updates. Yesterday I noticed the error log had been getting polluted with "UDQ: Queue(s) Full, message ignored" errors, which happened constantly between about 4 AM on Sept 21 until 11:30 PM yesterday (24th), when Polisy was restarted. I've been seeing 'full queues' on my 994i for past couple of years occasionally when it has been overloaded, mostly during restarts, but never continuously like as been occurring for past couple of days on IoP. I've attached IoP log, and error log. I can provide the PG3 log file for yesterday if it helps but be warned that the 62MB file also has a ton of messages related to the 5 NS used by my 994i and I don't see a way to easily separate them out from the IoP related entries. My usual method of importing into Excel and filtering on a column doesn't work well with these logs. (If you know how I could easily do that with Windows, please let me know.) Why would IoP event queue(s) have gotten overloaded and remain that way for 3 days with nothing but device updates from 3 NS? I can certainly report the problem to UDI but figured I would start here first to rule in/rule out a PG3 issue before reporting this as an IoP issue. Any info would be appreciated. IoPLogs.zip

Hi, I'm trying to list the configuration of a NS on my 994i in PG3 in one browser (Chrome) to copy/paste the config to same NS on IoP in another browser (Firefox) but things won't stay where they are. i.e. if I change the ISY I point to in PG3 in one browser it changes the page in both browsers. This happens even when I'm using different PCs. Is there a way to make things stand still (for lack of a better word) in one browser while I load what should be technically a different page in another browser? Or, I guess, is there a way to stop the push to all browsers that seems to happen? Shouldn't each browser (and even browser tab) be it's own special place independent of other browsers (browser tabs? It's interesting that some things don't change when they should (because of browser caching, I think) but then a page I'm on changes by itself because of something I'm doing in another browser. It's magical but not desirable.

There was a message this morning about the new version and that I needed to restart. I did so and am now at the latest version and see that the wind direction is now working. Thanks.

Thanks @Michel Kohanim. Will I have to exclude/include devices after migration to take advantage of the new features, e.g. S2, scenes, or anything else? I'm guessing yes for S2 as I understand it to be a comms security setup feature, although I'm not quite sure if I should care about it - should I if I'm not worried about my neighbors turning my stuff on/off? I do care about scenes, though. And other stuff. I have a lot of problems with zwave devices that the vendor blames on ISY 994i (lack of) support for it, and others I have that will just take so much effort to document that I haven't bothered asking vendor because I suspect it may be either an ISY 994 issue, a zwave 500 issue, a zwave 500 to 700 issue, or an 994i processing overload issue. Any info would be appreciated.

ok, thanks. not seeing 3.0.24 in the node server store. Tried closing and reopening browser still only see: