johnnyt

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

I did enter the same id for both and got the error. i also heard back from tempest tech support and there isn't a separate station ID for forecast. only the one associated with the weather station. In an urban setting one generally only needs one station. certainly I don't need 2 stations. will you be fixing things for those of us with only one station or is this NS only for people with more than one station?

I'm new to the tempest so i may be missing some key info but I can say I'm getting both the data from my station and forecast info on my app and when pointing to the web page for my station and this is with having bought only one station. I'll email tempest support to see if maybe I have two separate stations ID to provide - one for spot data and one for forecast info

Installed this NS for my new Tempest Wether Station yesterday and am getting the following error: 2022-07-02 08:39:22,072 Thread-730 udi_interface ERROR weatherflow:forecast_query: local variable 'value' referenced before assignment I'm a bit confused about the idea of putting my station ID in twice but if I don't put it in as local I get a message that at least one must be entered. Below are my settings (I deleted token for screenshot but there is one and am not getting any error messages about that). What am I not understanding needs to be done?

just moved to PG3 NS from PG2, which was working fine. It says connected but also has message saying: Hostname or IP address for EnvisaLink device missing in configuration ip address and password are fine and I can browse to the device - see further below.- but none of the devices are seen by ISY (my programs are all messed up)

Hi @JimboAutomates. Just wondering if this is still something you're planning to do?

My question is not about where PG3 is running. it's about what ISY instance it's pointing to.

So if I go explore a PG3 store it links the purchase to the un-configured IoP instance I'm not yet using. This might be because I haven't linked the ISY994i yet (actually I de-linked it so it's not talking to my ISY994i until I need it to.) I can add the ISY994i and link to that, but this display nuance suggests I'm getting a license for a particular ISY instance So can you/someone please confirm I can just change the ISY instance I point to later, e.g. move license from 994i to IoP?

if I buy/install a PG3 NS on my ISY994i then make the move to IoP a couple months from now, will I need to buy the NS again to link it to my IoP or will I be able to transfer the license over?