johnnyt

Correct me if I'm wrong but when you say "sensor" in the issue explanation on github, I think you mean "device", right? I have 7 devices and each one has 6 sensors. Timing for short poll should be 30 X 7, not 30 X 42 (7x6). Is it sending data for all sensors in all devices or just the changed data since last short poll? It looks like it's only changes because I rarely see 42 messages being sent to ISY but I want to confirm in case the reason I'm not getting 42 updates every time is because there's a problem somewhere. For reference I set my short poll to 240 (4 mins). I think devices update the mothership every 5 mins, each on it's own schedule. I haven't seen any rate limit issues since I moved to 4 mins.

Thanks @bpwwer. You make a really good point about how all NS' are starting at once when Polisy/PG3 is restarted. That alone (along with programs it triggers) may overload my 994i, even if it has finished doing its own stuff at startup. I may try what you're suggesting but I'm pretty sure I'll find there's no problem if I simply turn stuff off. I think the situation is just that there's too much being asked of the 994i. Hopefully IoP will resolve that. For now I've turned off WeatherFlow NS as it can send a lot of data in quick succession and I haven't really begun to leverage that data as I just got the device and NS a few weeks ago. So far so good. Bottom line, though, it seems I'm firmly at a point where the only thing that works right now is to not automate stuff I'd like to automate. In the interest of making the Polisy/IoP able to handle problems when they happen (while the humans are at work, sleeping or away) as well as handle the workload demands of up to 2000 programs, I wonder if the following features could be added to PG3 and ISY, where applicable: (I know you don't control either but believe you have influence with the ones who do) ability for ISY to stop/start/restart individual node servers. Not just for working around problems, but also consider that maybe some NS data/functionality is not needed while sleeping or on vacation, while some is only needed when sleeping or away ability to stagger the startup of NS' using a configurable delay by NS/slot or as a single global setting. Ideally there would be a way to select NS startup order, but as a starting point just the ability to manage the bombardment of ISY at startup would be good. ability to throttle the messages being sent to ISY, e.g. make all NS' put stuff for delivery to ISY on a single PG3 queue (if that isn't already the case) and set a configurable delay between each item being sent to ISY. Retries would see the item being added to bottom of queue rather than compounding what may be a processing capacity issue. Ideally there would be a way to set a message (or NS) priority as some NS data is needed faster than other. Also, there would be a way to adjust the throttle via an ISY program. I think this feature could potentially negate the need for #2 as ISY would be able to adjust throttle to a very high delay between messages when it's restarting. To give a bit more context on my set up because my need for more processing capacity and better processing efficiency isn't going away, and because I've had a few people in the past politely suggest that surely better programming on my part would fix my problems. My biggest source of programs (estimated at 70-75%) are related to HVAC. Unlike lighting, there are many more conditions and data points affecting HVAC decisions/functions. It's easy to underestimate all the conditions. Believe me. Especially when there's huge differences in seasons where one lives (I'm in Eastern Ontario, Canada) For example, here's some of the data I have to get and act on: indoor and outdoor temp and humidity, forecasted temp (today and tomorrow), temp differences within the house, temp diff inside vs outside, humidity differences, time of day, season (based on temp, forecasted temp, and time of year), home vs. away vs. on vacation. (OWM provides data that's critical to proper functioning, which is why I'm looking for some self healing tools if things aren't working between it and ISY for whatever reason.) Aside from controlling heat, AC, furnace fan (low/high), HRV (low/high), HEPA filter (low/high), duct fan (low/medium/high), humidifier in winter, two dehumidifiers in summer, and 2 bathroom fans based on the above data, I also have 7 Airthings devices that I use to trigger ventilation when VOC or CO2 levels are high. I also have to deal with humans wanting to manually run something or change the thermostat mode/set point without the automation coming right behind and undoing it, yet eventually taking over again. It's way more complicated than you might think, and certainly than I expected when I started on the journey. Over past 12-18 months, I've tried multiple times (and am always looking) to reduce the number of programs. I've had some successes but not on scale that would be needed. Last year I completely scrapped and started over the chunk controlling my HRV to see if I could lean things up and reduce the number of programs. In the end I ended up with just as many programs, if not more, and probably 40+ hours of my life I would have rather used to add automation not fix what I already had. In the mean time, to cope with overloads at start up and minimize them at other times, I've added different 'wait' commands throughout most programs to help reduce concurrent load to some extent. Of course that's a bit of a guessing game when you have 900 programs. Also in the category of "hours of my life I would have rather used to add automation not fix what I already had", I've had to build a complicated startup sequence for things to work mostly reliably, otherwise I would get "queue full" messages and (unknown to anyone) actions would be dropped. Informal scan suggests it works 60% of the time and that, for the other 40%, there are only a few missed actions that seem to fix themselves later. I never had a startup crash for some reason (maybe because I delay Polisy start?). I've just had stuff not working properly after a startup (most recently the interaction with OWM NS.) Key for a large majority of my programs is that very few things need to be done instantaneously with HVAC and other stuff. A lot of it can easily wait a bit. Most lighting automation needs quick response but even some lighting can wait, e.g. outside light ON when it's dark. What's another 30 seconds when turning on outside light, HRV or Humidifier? I propose the ability to manage work with throttling and prioritization would allow for demand/supply imbalances to be handed gracefully for 1000 programs today and up to 2000 programs eventually. It feels like some of that is already in place within ISY, e.g. backups clearly run at lower priority, but not with respect to the crucial interactions between PG3 and ISY. Personally I think HVAC automation is the next big thing in HA, and HVAC enthusiasts (nerds) like me don't mind and even like programming an ISY, so for the benefit of the ISY and the UDI model, I'm really hoping Polisy/IoP will be able to handle 2000 programs, especially when a majority doesn't need to be processed instantaneously in the interest of being able to do the stuff that does need rapid response and allow for everything one wants to automate. I mention all this believing you have influence in what PG3 (and possibly ISY) is/will be capable of doing, but if I'm barking up the wrong tree, let me know. Thanks again.

For Chrome (my usual choice of browser) I tried closing and re-opening it and the uptime was the actual number. For fun I went to Firefox and got the message that PG3 had be up > 3 months. I assure you I haven't had firefox running for 3 months straight. Heck I've had Windows do update and a restart a couple times in that time. But after I cleared the cache, the actual uptime came up and there was no longer message about PG3 needing restart.

So after investigating and capturing the above info, I went ahead and restarted just the OWM NS and all is fine now. This is good example of how an ISY initiated NS restart function would eliminate the need for the "sledge hammer"/ IoP suicide mission of doing a Polsy power cycle, which actually didn't fix the problem this time (probably my ISY missed something at restart despite the 10 min delay in restarting Polisy) Maybe when I move to IoP I won't have these issues but no one is telling me that (including UDI) so it remains to be seen. Even then, will I be limited in what else I can ask ISY to do for me, if not initially then 2-3 other node servers and 200-300 programs down the road? I won't have the luxury of delaying start of PG3 when I move to IoP unless I buy a separate Polisy just for IoP...

Just for reference the Polisy power cycle is something ISY does when it reboots, and it waits 10 mins after turning the (WebSwitch outlet) for Polisy off before turning it back on so the ISY has time to stabilize. I had to build complicated, multi program startup routine to do things is chunks otherwise I get "full queue" messages and a variety of things don't happen as they should. My startup routine works 60% of the time, and for the other 40%, I think I've been able to minimize the things that don't happen. I digress a bit to provide some context. The problem right now is that the data in ISY has not updated since before the spontaneous reboot at 11:53 (about 7.5 hours ago). Here are the variables that get updated when ISY sees changes in values such as temperature and humidity Here are two programs that should have set these variables to something that's not 0. There are others too that aren't working. Set Current Humidity - [ID 0303][Parent 0330] If '1-HVAC and Backyard / Climate / OpenWeatherMap' Humidity > 0% Then $sHum.Outdoor.Weather = '1-HVAC and Backyard / Climate / OpenWeatherMap' Humidity % Else - No Actions - (To add one, press 'Action') Set Current Temp Weather Service - [ID 00B1][Parent 0330] If '1-HVAC and Backyard / Climate / OpenWeatherMap' Temperature > -50.0°F Then Wait 3 seconds $sTemp.Outdoor.WeatherService = '1-HVAC and Backyard / Climate / OpenWeatherMap' Temperature °C Else - No Actions - (To add one, press 'Action') Interestingly when I saved data from the ISY event viewer and separated out the data for OWM there are regular updates being seen by the ISY. See attached spreadsheet. However the displayed data has not changed accordingly (and shows node server is not online) and even if I run the program for temp update manually, it doesn't change the variable. The program is "True" (green) but either the data is 0 or ISY is badly broken and the program isn't actually performing the action. Here's data right now in ISY that I believe is from before 11:50 this morning. This is very strange. OWM_EventViewerData.zip

Hi, I had an ISY 994i lock up last night so power cycled it and Polisy to recover from that. Recovery did not go so well for OWM NS. I've attached today's log file. ISY lock up occurred at or shortly after 01:33:15 AM last night and was power cycled at 09:53 AM. Polisy turned off as well around 9:53 but only turned back on at 10:10 to let ISY settle. One of my ISY programs subsequently power cycled Polisy around 11:00AM because OWM had not updated ISY data for too long. It was still seen as disconnected as I started writing this but a subsequent ISY program initiated power cycle (about 11:44) fixed it. (As you know in another post I discuss needing ability to restart NS or PG3. This is an example of why it's needed, at least until all NS' can detect and recover from ISY lock ups, restarts and other issues. This weather data affects multiple HVAC related program decisions so I need to make sure the data is fresh enough. I do get notified when these Polisy restarts are called so I can look into them but, until I can fix the root cause, the show must go on and a self healing mechanism needs to be available because I can't always fix issues as soon as they occur. When I move to IoP, these power cycles will become suicide missions for ISY, which is really not ideal) OpenWeatherMap_7-21-2022_115802_AM.zip

I power cycled Polisy to recover from ISY994i lockup and, for some reason, the dashboard reports PG3 has been up for > 5 days. I've attached today's log file. ISY lock up occurred at or shortly after 01:33:15 AM last night and was power cycled at 09:53 AM. Polisy turned off as well but only turned back on at 10:10 to let ISY settle. One of my ISY programs also subsequently power cycled Polisy around 11:00AM because one of the Node Servers had not updated data for too long (a story for another post, maybe. I have to look into that) pg3_7-21-2022_110421_AM.zip

While Java is far from being a real time OS, I find it hard to believe the AC running on a modern CPU is a bottle neck in the AC's loading performance. Just as interesting are backups, which can take well over 6 minutes. Fortunately (though not for the time it takes) I can tell the backup occurs on a low priority because the time it takes varies greatly. This would help explain why I've never seen a crash doing one of those, and I think I would have most certainly seen one by now otherwise. Data wise a backup in my case is 632 KB of uncompressed data (413KB compressed). I don't know how much of that are programs for a straight comparison, but at 6 minutes (when things aren't too busy otherwise) that's 1.7 KB/s throughput, or about equivalent to 14.4 kbps dial up modem speed. So I'm not seeing the problem as related to the amount of data. While I confess I have no idea how things are working in the background, it's really hard to believe my i7 core CPU with hyper threading (4Cores/8Threads) running at 3.4 GHz (turbo up to 3.8 GHz) connected via Gb Ethernet wouldn't be able to support the AC processing waaay more data per second than that. While I'm pretty sure the Polisy does not have close to an i7 core, I was really hoping that both CPU and network speed improvements of the Polisy/IoP were going to mean a HUGE improvement in overall data processing speed - with 2 aspects to this: 1) IoP loading the console, and 2) IoP talking to NS'. Does/will the console loading not benefit from Polisy hardware improvements? Could the first 300ms to load the first 88 programs largely be attributed to the "startup" processing and end up notably more efficient for the next 900, or 1900? Please at least tell me IoP is talking at something approaching internal bus/memory speed to node servers (minus PG3 overhead) and that it will make a noticeable difference? One of my ideas has been to put my lighting related insteon on one ISY (either 994i or IoP) and, on the other, put zwave with some insteon (all HVAC related). I'd rather not have to do that but if I'm deluding myself thinking that Polisy/IoP will fix my issues, I may go there. Your advice would be welcomed.

Hi @simplextech I've decided to leave ST-Inventory off for now after discussing my crash issues with UDI. You'll find the rationale at the post below after I got into talking about ST-Inventory with @bpwwer.

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.