johnnyt

PG3 is reporting an error updating WeatherFlow NS RAINRT value 11/30/2022, 08:34:05 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 352.140541ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/RAINRT/0.07758000000000001/46 11/30/2022, 08:41:05 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 357.517191ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/RAINRT/0.8210999999999999/46 11/30/2022, 08:43:03 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 356.864566ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/RAINRT/0.43776000000000004/46 This seems similar to a previous post I made that I can't find right now where I think the NS was receiving a number in a format it couldn't handle (number of decimals, I think). Strange that I didn't see this particular one when I saw the other ones. I guess I just haven't looked my logs when it was raining... Here's what the NS shows right now - seems to only accept 5 decimal places when it's getting lots more How come there isn't an error entry in NS log, only in PG3 log? here's the 08:43:03 entry in NS log: 2022-11-30 08:43:03,802 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: RAINRT to 0.43776000000000004 UOM 46 Is the PG3 error an error?

I restarted what is a 2nd instance of the this NS (with separate API as first instance) after several weeks of not using it. One of the airthings device that was fine before, was labeled as "undefined" instead of the name I gave it in Airthings. The data seems to be coming through to ISY okay and I was able to rename it on ISY side but it's stuck as 'undefined' in NS. I tried deleting it on ISY side to see if the process of re-adding it would clean things up. It appeared to go through a process that I thought would have re-added it but without doing so. It then sent data to the node even though it no longer exists on ISY 2022-11-28 09:01:52,847 Thread-339 udi_interface INFO Controller:shortPoll: enter 2022-11-28 09:01:52,849 Thread-339 udi_interface INFO Controller:_query_all: enter 2022-11-28 09:01:52,849 Thread-339 udi_interface INFO Sensor:shortPoll: enter 2022-11-28 09:01:52,850 Thread-339 udi_interface INFO Sensor:query: enter 2022-11-28 09:01:53,806 Thread-339 udi_interface INFO Sensor:query: exit 2022-11-28 09:01:53,807 Thread-339 udi_interface INFO Sensor:shortPoll: exit 2022-11-28 09:01:53,808 Thread-339 udi_interface INFO Sensor:shortPoll: enter 2022-11-28 09:01:53,809 Thread-339 udi_interface INFO Sensor:query: enter 2022-11-28 09:01:54,168 Thread-339 udi_interface INFO Sensor:query: exit 2022-11-28 09:01:54,169 Thread-339 udi_interface INFO Sensor:shortPoll: exit 2022-11-28 09:01:54,170 Thread-339 udi_interface INFO Sensor:shortPoll: enter 2022-11-28 09:01:54,171 Thread-339 udi_interface INFO Sensor:query: enter 2022-11-28 09:01:54,449 Thread-339 udi_interface INFO Sensor:query: exit 2022-11-28 09:01:54,450 Thread-339 udi_interface INFO Sensor:shortPoll: exit 2022-11-28 09:01:54,451 Thread-339 udi_interface INFO Sensor:shortPoll: enter 2022-11-28 09:01:54,452 Thread-339 udi_interface INFO Sensor:query: enter 2022-11-28 09:01:54,789 Thread-339 udi_interface INFO Sensor:query: exit 2022-11-28 09:01:54,790 Thread-339 udi_interface INFO Sensor:shortPoll: exit 2022-11-28 09:01:54,791 Thread-339 udi_interface INFO Sensor:shortPoll: enter 2022-11-28 09:01:54,792 Thread-339 udi_interface INFO Sensor:query: enter 2022-11-28 09:01:55,217 Thread-339 udi_interface INFO Sensor:query: exit 2022-11-28 09:01:55,219 Thread-339 udi_interface INFO Sensor:shortPoll: exit 2022-11-28 09:01:55,219 Thread-339 udi_interface INFO Controller:_query_all: exit 2022-11-28 09:01:55,220 Thread-339 udi_interface INFO Controller:shortPoll: exit 2022-11-28 09:02:01,537 MQTT udi_interface.interface INFO interface:_message: Successfully set s_2930133779 :: CO2LVL to 501.0 UOM 54 2022-11-28 09:02:01,578 MQTT udi_interface.interface INFO interface:_message: Successfully set s_2930133779 :: BARPRES to 998.4 UOM 56 2022-11-28 09:02:01,580 MQTT udi_interface.interface INFO interface:_message: Successfully set s_2930133779 :: GV3 to -37 UOM 56 2022-11-28 09:02:01,582 MQTT udi_interface.interface INFO interface:_message: Successfully set s_2930133779 :: CLITEMP to 22.7 UOM 4 2022-11-28 09:02:01,584 MQTT udi_interface.interface INFO interface:_message: Successfully set s_2930133779 :: GV2 to 1669644043 UOM 56 2022-11-28 09:02:01,620 MQTT udi_interface.interface INFO interface:_message: Successfully set s_2930133779 :: GV4 to 125.0 UOM 56 I restarted the NS and that resulted in recreation of the device in ISY as "undefined" Seems like a bug that the NS isn't using the device name that I gave it in Airthings in first place, and then isn't self correcting, though maybe the latter is more of a feature than a bug assuming this doesn't stem from an Airthings device defect - is there a way to tell? It looks fine on my Airthings Dashboard: I haven't tried unpairing device from hub then re-pairing it. I may do that later as another potential workaround. For now I've just renamed it in ISY

It's come to my attention that the WeatherFlow NS log does not report errors that are reported in PG3 log. Below are two examples from this morning (using latest 3.0.25 version of NS, with log level set to "Info"): Example 1: PG3 Log entries 11/23/2022, 10:15:04 [pg3] warn: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [ECONNABORTED] :: 5036.919286ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/GV4/1.94/32 11/23/2022, 10:15:04 [pg3] warn: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [ECONNABORTED] :: 5015.150309ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/GUST/1.94/32 WeatherFlow log entries: 2022-11-23 10:14:56,819 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: DEWPT to -2.5 UOM 4 2022-11-23 10:14:57,567 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: GV0 to -1.4 UOM 4 2022-11-23 10:14:57,610 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: ATMPRES to 1023.223 UOM 118 2022-11-23 10:14:58,738 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: CLIHUM to 75.7 UOM 22 2022-11-23 10:14:58,741 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: BARPRES to 1013.24 UOM 118 2022-11-23 10:14:59,447 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: SPEED to 1.94 UOM 32 2022-11-23 10:14:59,490 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: BATLVL to 2.371 UOM 72 PG3 error occurs here for next two updates but Weatherflow log gives appearance of successful update 2022-11-23 10:15:08,898 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: GV4 to 1.94 UOM 32 2022-11-23 10:15:08,940 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: GUST to 1.94 UOM 32 2022-11-23 10:15:09,278 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: LUMIN to 15778 UOM 36 2022-11-23 10:15:10,019 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: SOLRAD to 131 UOM 74 2022-11-23 10:15:10,061 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: UV to 1.29 UOM 71 2022-11-23 10:15:10,764 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: GV3 to 297 UOM 76 2022-11-23 10:15:10,807 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: WINDDIR to 297 UOM 76 2022-11-23 10:15:25,789 MQTT udi_interface.interface INFO interface:_message: Successfully set controller :: GV4 to 7 UOM 57 Example 2: PG3 log entries: 11/23/2022, 10:25:03 [pg3] warn: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [ECONNABORTED] :: 5036.783711ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/UV/0.54/71 11/23/2022, 10:25:03 [pg3] warn: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [ECONNABORTED] :: 5015.511116ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/SOLRAD/61/74 WeatherFlow log entries: 2022-11-23 10:24:56,556 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: CLIHUM to 75.05 UOM 22 2022-11-23 10:24:57,663 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: GV4 to 0.0 UOM 32 2022-11-23 10:24:57,705 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: SPEED to 0.0 UOM 32 2022-11-23 10:24:58,398 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: LUMIN to 7227 UOM 36 2022-11-23 10:24:58,440 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: GUST to 0.0 UOM 32 PG3 error occurs here for next two updates but Weatherflow log gives appearance of successful update 2022-11-23 10:25:07,861 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: UV to 0.54 UOM 71 2022-11-23 10:25:07,901 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: SOLRAD to 61 UOM 74 2022-11-23 10:25:08,242 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: WINDDIR to 0 UOM 76 2022-11-23 10:25:08,613 MQTT udi_interface.interface INFO interface:_message: Successfully set 207296 :: GV3 to 0 UOM 76 2022-11-23 10:25:25,578 MQTT udi_interface.interface INFO interface:_message: Successfully set controller :: GV4 to 7 UOM 57

I'm confused by this: First, to be clear, I only have one instance of this NS actually running/connected but I do have two installations of it: one for ISY and one for IoP. Not only did I think this was okay because of this prior message: But also because I did have three node servers running fine for both ISY and IoP as same time, namely Airthings, WeatherFlow, and this one as long as I put them in the same slot (which they are now, but the slot issue was a problem with this NS and us what started this thread) I'm now on PG3 3.1.14 and wasn't at that point when I reported this so probably the PG3 bug is no longer an issue if that's what was the issue. Since I now know how to avoid the problem, I'll leave it to you and @simplextech to determine if there are any fixes needed (to whatever) to avoid problems in future. I'm not going to be using this NS much once I move to IoP (just waiting for new dongle and zwave migration capability). I'm only using it periodically (I start then stop it) to check the number of programs I have on ISY because I'm close to the maximum allowed.

Any idea why the same three nodes or subnodes (not sure what they're called), namely SPEED, GV4, and GUST, are always involved in 404 errors? It's not like those calls don't succeed sometimes - I do see the values change in ISY. It's also not like there are no other nodes that get a 404. it's just that when there are 404's these three nodes are always involved from what I've seen. 11/18/2022, 02:55:13 [pg3] error: No code in error response 11/18/2022, 02:55:13 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 348.399805ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/SPEED/0.5760000000000001/32 11/18/2022, 02:55:13 [pg3] error: No code in error response 11/18/2022, 02:55:13 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 68.046758ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/GV4/0.5760000000000001/32 11/18/2022, 02:55:13 [pg3] error: No code in error response 11/18/2022, 02:55:13 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 22.453674ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/GUST/0.5760000000000001/32 11/18/2022, 02:56:03 [pg3] error: No code in error response 11/18/2022, 02:56:03 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 36.875933ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/SPEED/0.14400000000000002/32 11/18/2022, 02:56:03 [pg3] error: No code in error response 11/18/2022, 02:56:03 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 16.920775ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/GUST/0.14400000000000002/32 11/18/2022, 02:56:03 [pg3] error: No code in error response 11/18/2022, 02:56:03 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 56.705772ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/GV4/0.14400000000000002/32 11/18/2022, 02:57:02 [pg3] error: No code in error response 11/18/2022, 02:57:02 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 33.619906ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/SPEED/0.036000000000000004/32 11/18/2022, 02:57:02 [pg3] error: No code in error response 11/18/2022, 02:57:02 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 17.546125ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/GUST/0.036000000000000004/32 11/18/2022, 02:57:02 [pg3] error: No code in error response 11/18/2022, 02:57:02 [pg3] error: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [404 - OK] :: 57.084195ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/GV4/0.036000000000000004/32 Also, am really struggling to understanding why I get these errors when response times are fine. I get your point that an overloaded (or defective) ISY is bound to cause problems but these problems are happening without an obvious overload. Attached is PG3 log for today (up to now). As you'll see this NS (#6) results in the most errors. While for sure it is the one that gets the most activity and therefore opportunity for errors, my Airthings NS (#8) updates every 5 minutes, Envisalink-DSC every 6.5 mins or so, and OpenWeatherMap every 10 mins or so. There are a few but not that many Airthings errors and I didn't see any errors from the other ones. pg3-Nov18.log

Thanks for info on different meaning for controller variables/sub nodes (not sure what you call those) Note that Server Status asks for a number when used in a program, not true/false. I assume '0' means false and anything else means true but would be better if it said true/false (or adjust documentation)

@bpwwer, is this something on your radar? Do you need any more info from me?

Thanks. I did notice there were some airthings cloud issues yesterday. After this is fixed and the cloud returns 403, am I right to think it will change the NoderServer Status to "Unconnected" in ISY? And/or would it change the Server Status? I'm a bit confused about the difference and what events change them. Sometimes they are blank for me for a while - I think after an ISY restart. Also do you have timeline for when you will provide a new version? It looks like there are 9 open issues going back to July, most of which do affect my setup. Not critical, of course, although this latest one, while hopefully a rare event, did result in the NS crashing without any notification, i.e. my program notifying me when NS Status is "unconnected" did not trigger. Thanks again. I really like the ability to get my Airthings data into ISY.

I recently upgraded to PG3.1.14 and, today, after noticing a value in ISY was not getting updated, I check NS logs and it had stopped working at 02:03AM after a number of occurrences of errors I haven't seen before. 2022-11-17 01:48:36,971 Thread-693 udi_interface ERROR udi_interface:write: Exception in thread 2022-11-17 01:48:36,973 Thread-693 udi_interface ERROR udi_interface:write: Thread-693 2022-11-17 01:48:36,973 Thread-693 udi_interface ERROR udi_interface:write: : 2022-11-17 01:48:36,974 Thread-693 udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2022-11-17 01:48:36,975 Thread-693 udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.9/threading.py", line 980, in _bootstrap_inner 2022-11-17 01:48:36,979 Thread-693 udi_interface ERROR udi_interface:write: self.run() 2022-11-17 01:48:36,980 Thread-693 udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.9/threading.py", line 917, in run 2022-11-17 01:48:36,983 Thread-693 udi_interface ERROR udi_interface:write: self._target(*self._args, **self._kwargs) 2022-11-17 01:48:36,984 Thread-693 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Controller.py", line 149, in handler_poll 2022-11-17 01:48:36,986 Thread-693 udi_interface ERROR udi_interface:write: self.shortPoll() 2022-11-17 01:48:36,987 Thread-693 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Controller.py", line 153, in shortPoll 2022-11-17 01:48:36,988 Thread-693 udi_interface ERROR udi_interface:write: self._query_all() 2022-11-17 01:48:36,989 Thread-693 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Controller.py", line 183, in _query_all 2022-11-17 01:48:36,990 Thread-693 udi_interface ERROR udi_interface:write: node.shortPoll() 2022-11-17 01:48:36,991 Thread-693 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Sensor.py", line 104, in shortPoll 2022-11-17 01:48:36,993 Thread-693 udi_interface ERROR udi_interface:write: self.query(force=False,authorize=False) 2022-11-17 01:48:36,993 Thread-693 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Sensor.py", line 113, in query 2022-11-17 01:48:36,995 Thread-693 udi_interface ERROR udi_interface:write: st = self.controller.api_get(f"devices/{self.serial}/latest-samples") 2022-11-17 01:48:36,996 Thread-693 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Controller.py", line 202, in api_get 2022-11-17 01:48:36,997 Thread-693 udi_interface ERROR udi_interface:write: res = self.session.get( 2022-11-17 01:48:36,998 Thread-693 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/pgSession.py", line 65, in get 2022-11-17 01:48:37,000 Thread-693 udi_interface ERROR udi_interface:write: return(self.response(response,'get')) 2022-11-17 01:48:37,000 Thread-693 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/pgSession.py", line 88, in response 2022-11-17 01:48:37,002 Thread-693 udi_interface ERROR udi_interface:write: self.logger.error("Forbidden: %s: text: %s" % (response.url,json_data['message']) ) 2022-11-17 01:48:37,002 Thread-693 udi_interface ERROR udi_interface:write: KeyError 2022-11-17 01:48:37,003 Thread-693 udi_interface ERROR udi_interface:write: : 2022-11-17 01:48:37,004 Thread-693 udi_interface ERROR udi_interface:write: 'message' The node value that I noticed not getting updated was GV4 for device s_2930027997. There may be others too - I didn't go fishing for others. A restart of the NS seems to have fixed things for now. Attached is log for today, including entries after the restart. If needed I could SSH into Polisy to pull out older log files. Let me know if that would help at all. Thanks.

So I'm working with UDI support on possibility of ISY or Polisy network interface issue. As part of fathering more data I restarted the WeatherFlow NS with PG3 log level at debug and I'm seeing things that to me suggest issues that may not be related to network, including unhandled errors, "REPORT THIS" messages, and a ton of these: 11/16/2022, 09:33:53 [pg3] debug: 207296 is LOCKED by addnode(), waiting... I would also mention that it's not like I don't ever see normal response times from ISY. There are plenty of responses that are well below 100ms when I'm not restarting a NS or PG3. I've attached a chunk of logs from yesterday when ISY was obviously not busy to show this. I guess I'm wondering if every error is really a network problem or is there are other things going on that would continue to happen even if I got all new hardware? Or is there anything in the debug logs that would help UDI troubleshoot the problem? I've already sent a bunch of stuff and don't want to send more at this point unless it would be helpful. Thanks. PG3Debug-WeatherFlowNSrestart.zip

Ok, I've reported this to UDI. So the messages are for this NS and I see the nodes that are reported as not there in ISY so it's strange. How do I force a reload of the nodes? Restarting NS doesn't do it. I also tried "Load Profile" but it just sits there "clicked" and does nothing. see screenshot.

So I moved the 994i and Polisy off the unmanaged switch I was using and connected them directly to my main managed switch. I then ran a cable test and it returned "normal" (ports 11 and 12 below). Port 9 shown is connection to unmanaged switch so cables being used aren't the problem. I also don't see any Tx / Rx errors on those ports on the switch monitoring page. Finally, I did some packet capturing at router of 994i and Polisy routing calls and traffic to/from my PC to them and there were no errors reported. I'm still, however, getting roughly the same errors in PG3 when I stop/start WeatherFlow NS after the switch changes. So I think I'm now trying to figure out whether 994i or Polisy NIC might be struggling/failing. Is there a tool I can use at Polisy OS level to test the Polisy NIC to see if it's failing? I don't believe there's anything I can run on 994i, but if you know of something, please let me know. Also, I'm wondering if the following message is an error or "OK". Normally http 404 code is an error but this entry also says "OK" so I'm confused. 11/15/2022, 13:24:49 [pg3] error: ISY Response: [Try: 1] [myISYid] :: [404 - OK] :: 32.008351ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_207296/report/status/SPEED/2.7720000000000002/32

I'll play with network path to see if there's an issue with switches connecting 994i and Polisy to router (both are on same switch now). I should mentioned that I often get sub-100ms responses so it's not clear to me I'm having a general network issue. In the meantime if you don't know what ECONNABORTED who would? Cause I get those all the time. Also I just upgraded PG3 from 3.1.12 to 3.1.14, which required a PG3 restart. Below is a chunk of the PG3 logs I got at startup. There are a number of unhandled errors, a couple "REPORT THIS" messages, several driver errors, and, of course the pretty normal "ECCONNABORTED" messages. Other than the unhandled errors, would the other errors be due to network problems or failing ISY, or could there be something else going on? If changing switches doesn't fix the problem I will reach out to UDI support but want to be sure I've ruled other possibilities out. Node 6 is WeatherFlow NS and node 8 is Airthings NS. Attached is screenshot of the PG3 Dashboard for my 994i 11/15/2022, 09:43:57 [pg3] error: Error: GET http://192.168.200.251:80/rest/nodes Failed :: ECONNABORTED 11/15/2022, 09:43:57 [pg3] error: [<my ISY ID>_6] checkDrivers failed :: TypeError: Cannot read properties of undefined (reading 'data') at Object.checkDrivers (/var/polyglot/node_modules/@universaldevices/pg3/lib/modules/Node server/status.js:269:64) at async /var/polyglot/node_modules/@universaldevices/pg3/lib/modules/Node server/command.js:144:13 at async Promise.all (index 0) 11/15/2022, 09:43:57 [pg3] info: [<my ISY ID>_6] adding node forecast_8 to ISY 11/15/2022, 09:44:02 [pg3] warn: ISY Response: [Try: 1] [<my ISY ID>] :: [ECONNABORTED] :: 5020.398338ms - http://192.168.200.251:80/rest/ns/8/nodes/n008_controller/report/status/GV2/1/56 11/15/2022, 09:44:07 [pg3] warn: ISY Response: [Try: 1] [<my ISY ID>] :: [ECONNABORTED] :: 10003.68036ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_forecast_8/add/forecast?primary=n006_controller&name=Forecast%208 11/15/2022, 09:44:10 [pg3] error: No code in error response 11/15/2022, 09:44:10 [pg3] warn: ISY Response: [Try: 2] [<my ISY ID>] :: [400 - OK] :: 2459.073208ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_forecast_8/add/forecast?primary=n006_controller&name=Forecast%208 11/15/2022, 09:44:10 [pg3] error: No code in error response 11/15/2022, 09:44:10 [pg3] warn: ISY Response: [Try: 3] [<my ISY ID>] :: [400 - OK] :: 42.763673ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_forecast_8/add/forecast?primary=n006_controller&name=Forecast%208 11/15/2022, 09:44:10 [pg3] error: No code in error response 11/15/2022, 09:44:10 [pg3] error: ISY Response: [MAX TRIES EXCEEDED] [<my ISY ID>] :: [400 - OK] :: 434.252744ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_forecast_8/add/forecast?primary=n006_controller&name=Forecast%208 11/15/2022, 09:44:10 [pg3] error: Error: GET http://192.168.200.251:80/rest/ns/6/nodes/n006_forecast_8/add/forecast?primary=n006_controller&name=Forecast%208 Failed :: 400 - OK 11/15/2022, 09:44:10 [pg3] info: [<my ISY ID>_6] addnode sucessfully added node forecast_8 11/15/2022, 09:44:10 [pg3] error: unhandledRejection REPORT THIS!: [object Promise], reason: TypeError: Cannot read properties of undefined (reading 'status') 11/15/2022, 09:44:10 [pg3] warn: node forecast_0 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node forecast_1 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node forecast_2 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node forecast_3 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node forecast_4 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node forecast_6 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node forecast_5 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node forecast_7 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node forecast_9 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node s_2930037297 on profile 8 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:11 [pg3] warn: node s_2930027997 on profile 8 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:12 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:44:12 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:44:12 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:44:12 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:44:12 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:44:12 [pg3] warn: ISY Response: [Try: 1] [<my ISY ID>] :: [ECONNABORTED] :: 7534.005203ms - http://192.168.200.251:80/rest/nodes/n006_207296 11/15/2022, 09:44:12 [pg3] warn: node 207296 on profile 6 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:17 [pg3] warn: ISY Response: [Try: 1] [<my ISY ID>] :: [ECONNABORTED] :: 5007.305041ms - http://192.168.200.251:80/rest/ns/6/nodes/n006_forecast_9/report/status/GV1/-5.0/4 11/15/2022, 09:44:23 [pg3] warn: ISY Response: [Try: 1] [<my ISY ID>] :: [ECONNABORTED] :: 5020.107423ms - http://192.168.200.251:80/rest/nodes 11/15/2022, 09:44:28 [pg3] warn: ISY Response: [Try: 2] [<my ISY ID>] :: [ECONNABORTED] :: 5027.978098ms - http://192.168.200.251:80/rest/nodes 11/15/2022, 09:44:33 [pg3] warn: ISY Response: [Try: 3] [<my ISY ID>] :: [ECONNABORTED] :: 5015.460456ms - http://192.168.200.251:80/rest/nodes 11/15/2022, 09:44:36 [pg3] warn: node s_2930071732 on profile 8 already exists, no nodeDef or driver changes detected 11/15/2022, 09:44:38 [pg3] error: ISY Response: [MAX TRIES EXCEEDED] [<my ISY ID>] :: [ECONNABORTED] :: 5010.138324ms - http://192.168.200.251:80/rest/nodes 11/15/2022, 09:44:38 [pg3] error: Error: GET http://192.168.200.251:80/rest/nodes Failed :: ECONNABORTED 11/15/2022, 09:44:39 [pg3] error: [<my ISY ID>_8] checkDrivers failed :: TypeError: Cannot read properties of undefined (reading 'data') at Object.checkDrivers (/var/polyglot/node_modules/@universaldevices/pg3/lib/modules/Node server/status.js:269:64) at async /var/polyglot/node_modules/@universaldevices/pg3/lib/modules/Node server/command.js:144:13 at async Promise.all (index 0) 11/15/2022, 09:44:39 [pg3] info: [<my ISY ID>_8] adding node s_2930029938 to ISY 11/15/2022, 09:44:41 [pg3] error: No code in error response 11/15/2022, 09:44:41 [pg3] warn: ISY Response: [Try: 1] [<my ISY ID>] :: [400 - OK] :: 2917.629801ms - http://192.168.200.251:80/rest/ns/8/nodes/n008_s_2930029938/add/Sensor?primary=n008_controller&name=Main%20Floor 11/15/2022, 09:44:41 [pg3] error: No code in error response 11/15/2022, 09:44:41 [pg3] warn: ISY Response: [Try: 2] [<my ISY ID>] :: [400 - OK] :: 17.414811ms - http://192.168.200.251:80/rest/ns/8/nodes/n008_s_2930029938/add/Sensor?primary=n008_controller&name=Main%20Floor 11/15/2022, 09:44:41 [pg3] error: No code in error response 11/15/2022, 09:44:42 [pg3] warn: ISY Response: [Try: 3] [<my ISY ID>] :: [400 - OK] :: 13.28028ms - http://192.168.200.251:80/rest/ns/8/nodes/n008_s_2930029938/add/Sensor?primary=n008_controller&name=Main%20Floor 11/15/2022, 09:44:42 [pg3] error: No code in error response 11/15/2022, 09:44:42 [pg3] error: ISY Response: [MAX TRIES EXCEEDED] [<my ISY ID>] :: [400 - OK] :: 35.297172ms - http://192.168.200.251:80/rest/ns/8/nodes/n008_s_2930029938/add/Sensor?primary=n008_controller&name=Main%20Floor 11/15/2022, 09:44:42 [pg3] error: Error: GET http://192.168.200.251:80/rest/ns/8/nodes/n008_s_2930029938/add/Sensor?primary=n008_controller&name=Main%20Floor Failed :: 400 - OK 11/15/2022, 09:44:42 [pg3] info: [<my ISY ID>_8] addnode sucessfully added node s_2930029938 11/15/2022, 09:44:42 [pg3] error: unhandledRejection REPORT THIS!: [object Promise], reason: TypeError: Cannot read properties of undefined (reading 'status') 11/15/2022, 09:44:55 [pg3] warn: ISY Response: [Try: 1] [<my ISY ID>] :: [ECONNABORTED] :: 5004.806641ms - http://192.168.200.251:80/rest/nodes 11/15/2022, 09:45:00 [pg3] warn: ISY Response: [Try: 2] [<my ISY ID>] :: [ECONNABORTED] :: 5007.780992ms - http://192.168.200.251:80/rest/nodes 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver 11/15/2022, 09:45:01 [pg3] error: addnode add driver error: UNIQUE constraint failed: driver.uuid, driver.profileNum, driver.address, driver.driver

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