johnnyt

Thanks for reply and all your good work on PG3 on top of all the NS' you built. Yes, I've been working with UDI on the crashes. While still working to get to the bottom of it, It appears right now that ST-Inventory requesting all my info (most notably the ~980 programs) may be too much for the 994i when a lot of other stuff is going on too. I decided I will only use it 'manually' until I move to IoP (once zwave migration is available). Aside from more horsepower behind IoP, if I heard/understood correctly, I think UDI is considering leveraging that extra horsepower to compress the ISY data so it loads faster in admin console and node servers (since I'm told they use the same API.) I know at this point it's just a 'consideration' but, personally, I'm really hopeful that one day I will not have to wait almost 3 mins to load AC w/ 2:30 of that loading programs. When I think about it, unless one can subscribe to node and program number changes as they happen, 2.5 - 3 mins of sustained draw on (the under-powered) 994i is a huge window of time for it to get overloaded providing ST-Inventory the info it needs while potentially having many other things to do at the same time (hence my decision to leave it mostly off)

it's okay, the values did get updated eventually. if it happens again, I'll grab a relevant chunk of the logs and send it. the log seems to have reset at midnight so the data from yesterday isn't there anymore.

So I had ISY crash 3 times in 2 days right after moving to PG3, another time a few days later, and again today. For sure it hasn't been this bad before but yes, you are lucky. I think it's overloaded and I really really hope IoP will fix my long standing issues with performance. (I have 980 programs and way more programs in my head when I move to IoP where program limit will go from 1000 to 2000) I started by blaming ST-Inventory - see all the gory details here: While it does have to read all my programs (which is taxing) and it did show intermittent errors, I don't think it's really an ST-Inventory issue specifically. For example, for today's crash there was no ST-Inventory activity in its logs at the time of the crash. I'm okay with querying a NS not working quite as I had hoped, but what about being able to call for a NS (or PG3) restart from a program? Even if the need (or hope) for restarts will truly be a rare 'edge' case someday, we're not there today, and it's not like there will never be restarts needed. Power outages are only expected to increase with climate change. I would think there's value in being able to do NS (or PG3) restarts via programs at ISY startup or if something goes wrong (e.g. no data updates for too long). Correct me if I'm wrong but that would reload data into ISY (unlike a query). Not providing a restart capability because an "issue (may not) get reported" is not a good reason. It's not a customer centric perspective for one, but also I believe folks who use ISY - or at least enough of us - will report issues. Who would want crashes/failed node servers and restarts to be part of a weekly or monthly routine?

Today my ISY crashed and since then none of my devices show a status anymore and a couple also no longer show battery status, though I can see other data is changing. This was about 5 hours ago and my short poll/long poll is at 240/480 I tried querying the node but it did not update the data. Should a query work? (Can that be added if it's not there yet?) Is there a command I can send from ISY to restart the NS? I did a manual restart it and it fixed two of them (status went to True) but that isn't foolproof - might there an issue there? (I can maybe look into this closer, and report back separately with more info.)

Thanks for the explanation. I can look for data changes as my indicator that the NS working. I was doing that before but hoping to move to NS Online Status. How come 'blank' = Disconnected, at least according to my program condition (when it wasn't disconnected)? Is there a command I can send to restart this (or any) NS in PG3? And, is there a command I can send to restart PG3? Right now I'm using a sledgehammer to restart Polisy, namely a WebSwitch with network command from 994i to power cycle the outlet Polisy is plugged into, but when I move to IoP that approach will be suicide for ISY so not really one I want to have to ever use - not to mention it's not ideal from the risk of data corruption perspective. Thanks again

Hi, After an ISY restart today I noticed that while the OWM NS is updating data values in ISY it has not updated its status and I can't query it in a program as there is option to do so (only 'Remove Notices') I'm counting on the 'online' status to do (and not do) certain things. In the 'do' category is, potentially, restarting PG3 if things are stuck for too long. I noticed that while the program is true it actually did not run at startup. There's likely some troubleshooting on my part there but I will need to be able to query the NS in a program. So can 'query' be added as a program action? In the meantime, how often is that status sent to ISY? Perhaps ISY was too busy to process it at startup but is it also sent periodically? I know I've seen a value there as I was writing up the program but it's been 2.5 hrs since restart and there's nothing there. Thanks.

Thanks. Good to learn about the Discover button and long poll. might be useful to add to config help in a future update. I'm not so sure the issue is exclusively that ISY is busy. I just ran 4 discoveries in a row and 3 times an error occurred but ISY is really not busy right now - and there's nothing in the ISY error log. Maybe I'm having network issues with NS related network errors presumably not showing up in ISY error log. I'll do a little forensic research and, if I can't tell, send logs to UDI to see if there are indications of abnormal network related issues in other circumstances. 2022-07-18 11:18:45 info: NS: Discovering 2022-07-18 11:20:01 info: NS: Discovering 2022-07-18 11:20:01 info: NS: Discovering Nodes 2022-07-18 11:20:09 error: POLY: getInv() Error: http://192.168.200.251:80/rest/nodes 2022-07-18 11:20:29 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'toString') at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:312:19) at Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:5:59) at _0x242b12.processNodes (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3482) at _0x242b12.onDiscover (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3126) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 2022-07-18 11:20:30 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'node') at /var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3650 at Parser.<anonymous> (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:304:18) at Parser.emit (node:events:539:35) at SAXParser.onclosetag (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:262:26) at emit (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:624:35) at emitNode (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:629:5) at closeTag (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:889:7) at SAXParser.write (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:1436:13) at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:323:31) at Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:5:59) 2022-07-18 11:20:53 info: NS: Discovering 2022-07-18 11:20:53 info: NS: Discovering Nodes 2022-07-18 11:21:00 error: POLY: getInv() Error: http://192.168.200.251:80/rest/nodes 2022-07-18 11:21:09 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'toString') at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:312:19) at Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:5:59) at _0x242b12.processNodes (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3482) at _0x242b12.onDiscover (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3126) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 2022-07-18 11:21:09 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'node') at /var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3650 at Parser.<anonymous> (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:304:18) at Parser.emit (node:events:539:35) at SAXParser.onclosetag (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:262:26) at emit (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:624:35) at emitNode (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:629:5) at closeTag (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:889:7) at SAXParser.write (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:1436:13) at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:323:31) at Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:5:59) 2022-07-18 11:21:31 info: NS: Discovering 2022-07-18 11:21:31 info: NS: Discovering Nodes 2022-07-18 11:22:53 info: NS: Discovering 2022-07-18 11:22:53 info: NS: Discovering Nodes 2022-07-18 11:23:07 error: POLY: getInv() Error: http://192.168.200.251:80/rest/nodes 2022-07-18 11:23:13 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'toString') at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:312:19) at Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:5:59) at _0x242b12.processNodes (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3482) at _0x242b12.onDiscover (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3126) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 2022-07-18 11:23:13 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'node') at /var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3650 at Parser.<anonymous> (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:304:18) at Parser.emit (node:events:539:35) at SAXParser.onclosetag (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:262:26) at emit (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:624:35) at emitNode (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:629:5) at closeTag (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:889:7) at SAXParser.write (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:1436:13) at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:323:31) at Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:5:59)

It's certainly possible my ISY can't keep up. I've had lots of issues with the lack of horsepower over the years, despite efforts to try to keep things lean (including many hours spent redesigning things and asking help from UDI) and using lots of 'wait' commands to slow things down. I'm at 980 programs. 20 short of the max for the 994i so I'm effectively crippled until I move to IoP, which will support up to 2000 programs, but have a lot more ideas things I want to do. I really hope IoP will benefit from the Polisy horsepower and I will need it if I'm going to keep investing in ISY/IoP as my HA controller. For now I have to last until there's stable zwave migration capability to find out. What's not clear to me is why I was getting tons of the errors (and ISY crashes than may or may not have been related - perhaps due to overload) when I first moved to PG3 and now it's down to only a few errors. If anything I've only added to the load by adding an Airthings NS and a Tempest Weather Station NS (which did not have PG2 offerings) - about 20-30 more programs, though they don't do that much. This NS has been running for me with this lower rate of errors for a few days now with no ISY crashes, so not too worried about this anymore at this point. I would ask, though, that if there are things you can do to tolerate slower responses from ISY and/or try again 30 and/or 60 secs later and only report multiple subsequent errors, please consider doing that. There's no major rush to getting this data, with limited use cases (that I can think of) for use in programs. (Maybe a notification when some limit is close to being reached? I only know about the number of program limitation) I can see from the logs the short poll is when ISY is queried. Can you tell me what the long poll does? Is it just a heart beat? Can the long poll be shorter than the short poll? It's not mentioned in the Config help. Thanks

Oops. it was a separately post, and not part of this one. Also had question about the time value

Hi, I had asked before (but think post may have gotten lost in forum crash) if an API call needed to be made 'per device' or if it returned data from all devices linked to my account. I have 7 wave plus devices and am getting repeated messages about API rate limit being exceeded (so I think I know the answer). Is there a way to get more info per call, or, if I need to ask Airthings for a higher rate limit, what number do I need to ask them for? I had short poll / long pol set to 120/240 but bumped them up to 240/480 for now. Here's a short excerpt from log, repeated every short poll until waiting period is over. 2022-07-17 11:30:09,349 Thread-2046 udi_interface INFO Controller:shortPoll: enter 2022-07-17 11:30:09,350 Thread-2046 udi_interface INFO Controller:_query_all: enter 2022-07-17 11:30:09,351 Thread-2046 udi_interface DEBUG Controller:authorize: enter 2022-07-17 11:30:09,351 Thread-2046 udi_interface DEBUG Controller:authorize: Token Expires: 2022-07-17 13:18:09.802246 currently: 2022-07-17 11:30:09.351733 2022-07-17 11:30:09,352 Thread-2046 udi_interface DEBUG Controller:authorize: exit 2022-07-17 11:30:09,353 Thread-2046 udi_interface INFO Sensor:shortPoll: enter 2022-07-17 11:30:09,353 Thread-2046 udi_interface INFO Sensor:query: enter 2022-07-17 11:30:09,354 Thread-2046 udi_interface WARNING Controller:api_get: API Rate limit exceeded, waiting until 2022-07-17 11:31:10.032853 query the Airthings service. 2022-07-17 11:30:09,354 Thread-2046 udi_interface INFO Sensor:shortPoll: exit 2022-07-17 11:30:09,355 Thread-2046 udi_interface INFO Sensor:shortPoll: enter 2022-07-17 11:30:09,356 Thread-2046 udi_interface INFO Sensor:query: enter 2022-07-17 11:30:09,356 Thread-2046 udi_interface WARNING Controller:api_get: API Rate limit exceeded, waiting until 2022-07-17 11:31:10.032853 query the Airthings service. 2022-07-17 11:30:09,357 Thread-2046 udi_interface INFO Sensor:shortPoll: exit 2022-07-17 11:30:09,357 Thread-2046 udi_interface INFO Sensor:shortPoll: enter 2022-07-17 11:30:09,358 Thread-2046 udi_interface INFO Sensor:query: enter 2022-07-17 11:30:09,359 Thread-2046 udi_interface WARNING Controller:api_get: API Rate limit exceeded, waiting until 2022-07-17 11:31:10.032853 query the Airthings service. 2022-07-17 11:30:09,359 Thread-2046 udi_interface INFO Sensor:shortPoll: exit 2022-07-17 11:30:09,360 Thread-2046 udi_interface INFO Sensor:shortPoll: enter 2022-07-17 11:30:09,360 Thread-2046 udi_interface INFO Sensor:query: enter 2022-07-17 11:30:09,361 Thread-2046 udi_interface WARNING Controller:api_get: API Rate limit exceeded, waiting until 2022-07-17 11:31:10.032853 query the Airthings service. 2022-07-17 11:30:09,362 Thread-2046 udi_interface INFO Sensor:shortPoll: exit 2022-07-17 11:30:09,362 Thread-2046 udi_interface INFO Sensor:shortPoll: enter 2022-07-17 11:30:09,363 Thread-2046 udi_interface INFO Sensor:query: enter 2022-07-17 11:30:09,364 Thread-2046 udi_interface WARNING Controller:api_get: API Rate limit exceeded, waiting until 2022-07-17 11:31:10.032853 query the Airthings service. 2022-07-17 11:30:09,364 Thread-2046 udi_interface INFO Sensor:shortPoll: exit 2022-07-17 11:30:09,365 Thread-2046 udi_interface INFO Sensor:shortPoll: enter 2022-07-17 11:30:09,365 Thread-2046 udi_interface INFO Sensor:query: enter 2022-07-17 11:30:09,366 Thread-2046 udi_interface WARNING Controller:api_get: API Rate limit exceeded, waiting until 2022-07-17 11:31:10.032853 query the Airthings service. 2022-07-17 11:30:09,367 Thread-2046 udi_interface INFO Sensor:shortPoll: exit 2022-07-17 11:30:09,367 Thread-2046 udi_interface INFO Sensor:shortPoll: enter 2022-07-17 11:30:09,368 Thread-2046 udi_interface INFO Sensor:query: enter 2022-07-17 11:30:09,369 Thread-2046 udi_interface WARNING Controller:api_get: API Rate limit exceeded, waiting until 2022-07-17 11:31:10.032853 query the Airthings service. 2022-07-17 11:30:09,369 Thread-2046 udi_interface INFO Sensor:shortPoll: exit 2022-07-17 11:30:09,370 Thread-2046 udi_interface INFO Controller:_query_all: exit 2022-07-17 11:30:09,370 Thread-2046 udi_interface INFO Controller:shortPoll: exit

994i, ver 5.3.4

FWIW, some data is getting updated in ISY, The log file (at "info" level) is showing some successes and for sure I've seen the number of programs change as I add some. Probably others too (I see them in the log) but not looking too closely at those in ISY. What's not working or not being updated due to the API error, which is still happening periodically? See attached log file. ST-Inventory_7-16-2022_43224_PM.zip

Didn't take long to report error again (with API, if I understand correctly): 2022-07-15 20:37:08 info: NS: Starting Node Server 2022-07-15 20:37:08 info: POLY: Interface starting 2022-07-15 20:37:08 info: POLY: Getting config from environment 2022-07-15 20:37:09 info: POLY: MQTT client connected 2022-07-15 20:37:09 info: NS: MQTT Connection started 2022-07-15 20:37:09 error: POLY: Config has logLevel: INFO 2022-07-15 20:37:09 info: POLY: Loglevel: info 2022-07-15 20:37:09 info: POLY: Setting node controller driver ST: 1 2022-07-15 20:37:09 info: NS: Config received has 1 nodes 2022-07-15 20:42:08 info: NS: Short poll 2022-07-15 20:42:08 info: NS: Short Poll: Inventory 2022-07-15 20:42:08 info: NS: Discovering 2022-07-15 20:42:20 error: POLY: getInv() Error: http://192.168.200.251:80/rest/programs?subfolders=true 2022-07-15 20:42:23 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'toString') at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:312:19) at Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:5:59) at _0x242b12.processPrograms (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:5651) at _0x242b12.onDiscover (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3227) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 2022-07-15 20:42:23 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'program') at /var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:5801 at Parser.<anonymous> (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:304:18) at Parser.emit (node:events:539:35) at SAXParser.onclosetag (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:262:26) at emit (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:624:35) at emitNode (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:629:5) at closeTag (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:889:7) at SAXParser.write (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/sax/lib/sax.js:1436:13) at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:323:31) at Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:5:59) 2022-07-15 20:47:08 info: NS: Long poll 2022-07-15 20:47:08 info: NS: Long Poll: Inventory 2022-07-15 20:47:08 info: NS: Short poll 2022-07-15 20:47:08 info: NS: Short Poll: Inventory 2022-07-15 20:47:08 info: NS: Discovering

Ok, might be browser caching - all I can think of - because I checked in again about 4 hours later (new browser session) and now the log does show info related to the restart I did 4 hours ago. FWIW I tried doing upgrade from IoP (the recommended way to do it) and it didn't change anything or even do a Polisy reboot, which I assume means everything is up to date. here's the before screenshot: And the after: Anyway, NS is running again. let's see what happens.

I just restarted NS and nothing is being written to the log. I had changed log level to "Debug" yesterday, started NS than stopped it (waiting for more info). I restarted just now (a day later) with log level "Info" (one level above Debug) and there's no data being written to the log - and it took several mins to update node data in ISY. It won't be much use running this NS if there's no log data should ISY crash again (coincidentally or not) I don't know if Polyglot log file is of any help but have attached it here. pg3_7-15-2022_44844_PM.zip

I've uninstalled and reinstalled NS in same slot. Should I have deleted the ISY nodes before reinstalling and/or used a different slot? (I didn't) I'm working with Michel, who's mentioning I may have issues with power supply or PLM from looking at error log entries. But that wouldn't explain the wrong API's being used.

Polisy not new but move to PG3 is new. It is (was) up to date prior to move as far as I know. Below is what I have installed running (on PG3) along with PG3 and ISY version numbers (am still on 994i, not using IoP yet). I have no other ST NS's and nothing running under PG2. I did have ISY inventory installed on PG2 and it wasn't working properly. Would work for about a day than stop working. Would that have any relevance here?

Ok i'll report to UD support but all I did was "purchase" and "install" NS on same day. I didn't think I had to do an update on the same day I installed it. Let's see what UD support says.

I did some packet sniffing on port 50222 (default "listen" port) and the "Destination IP" for the traffic from the hub is 255.255.255.255, which can't really be pushed to another VLAN or translated to the Polisy's IP address. Or at least I don't think it can because what I've tried that's worked in other situations (e.g. NAT'ing 192.168.100.1:50222 to 192.168.200.1:50222, or subnet to subnet) didn't work for this. Unless someone reading this knows more about networking than I do, I think I may have to stick ISY & Polisy on the VLAN with all the insecure IoT devices. I guess they are kind of IoT devices anyway.

I moved to PG3 a couple weeks ago and installed ST-Inventory. My ISY crashed 3 times in 2 days so I decided to stop 1 NS at a time starting with ST-Inventory. Not only did ISY not crash again for the few days I tested but when I restarted it, it crashed again within hours. Attached is ST-Inventory log. Here are the restarts in first round of testing (from ISY log) Time User Log Type Thu 2022/07/07 05:05:03 PM System Start Fri 2022/07/08 02:40:52 AM System Start Fri 2022/07/08 07:14:10 PM System Start And here's the restart time related to the ST-Inventory flood of errors in the attached log file Sun 2022/07/10 01:25:01 PM System Start ST-Inventory_7-10-2022_25135_PM.zip

Oh, I see. I think it's a VLAN issue. I have all my wireless IoT devices (a.k.a Internet of insecure things) on a separate VLAN (100) from ISY - and ISY is on separate (more trusted) VLAN (200) than my regular computers (VLAN 0). I do have firewall rules that allow all VLANs to connect to VLAN 100, but block VLAN 100 from connecting to other VLANs. How does the Node Server connect to the Tempest Hub? I'm wondering about the mechanism the NS uses because I noticed I didn't have to put in an IP address for the hub. I wonder if being able to put in the hub's IP address would solve the problem, and, if so, if you would consider adding that option? As you know, there are many horror stories of IoT devices not getting patched when critical vulnerabilities are discovered so I would think it's important to allow for segregation of those onto their own separate subnet or vlan.

I set log level to debug, restarted NS, and waited at least long poll (600) seconds (I assume). Attached is log. WeatherFlow_7-13-2022_54818_PM.zip

Ignore the question, There is a value field for VOC. I was distracted by the assessment field that's actually labeled "VOC Level" Instead, can you explain what the time value is - and if there's a way to convert it to something meaningful?

Thanks for doing this Node server. I have 7 Wave Plus devices. Does 1 API call return all info about all devices, or does it take one call per reading or per device? All I've done is set things up and one device has no data and the log reports "WARNING Controller:api_get: API Rate limit exceeded, waiting until 2022-07-09 16:45:23.514700 query the Airthings service." I set short poll to 120 secs, for what that's worth. Maybe this is just because of the rush of calls due to set up but for future reference how calls will it "cost" to update my 7 devices? Also, I'm not seeing the VOC level, just a "Clean" report. Can the level be provided instead, or is that all Airthings returns?

So not getting the error anymore (after upgrade) but am also not getting station data, and top node will go from "Hub Seconds Since Seem" of 0 right to 1657295307 and move up from there (since screenshot I took the number has gone up to 1657295727). See screenshots below