johnnyt

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

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

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

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

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

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

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

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

Hi, I opened a support ticket for this and just got this response back:

I've been delaying the move to IoP waiting for zwave migration functionality because I have too many zwave devices to entertain the idea of re-adding them all in one by one and fixing all the affected programs. I understand that's coming soon, and there will also be a new dongle for the Polisy that will provide better support of 700-series zwave than the Zooz dongle, including OTA firmware updates. I'm wondering if I should get the new board before I do the migration. I did get a Zooz 700-series dongle a while back before I realized all the work that would be needed to move my stuff to IoP, so I've only been using it to do OTA firmware updates before adding a zwave device to the ISY 994i. My IoP questions is, If I move to IoP using Zooz dongle (and the soon to come zwave migration tool), will I be able to swap in the new board relatively seamlessly? If not right away, will there be support for that coming in the not too distant future, e.g. <6 months or so? My next gen question is, if I move to IoP on Polisy and I want to upgrade to the new eisy hardware later, will that be relatively seamless? If not right away, then in not too distant future? Will the dongle I use matter? While I don't want to wait too long to move to IoP as I've certainly outgrown the 994i's processing capacity, I do want to know the cost, if any, of not waiting for new eisy (and the MatterZ board I would get with it) given I will likely get one of those.

Hi @JimboAutomates, just wondering if this is technically possible as a first step regardless of whether or not you would consider doing it for this NS. This is as much a PG/NS 101 question for any NS that calls an API as it is for doing it for this particular NS. If it is technically possible, with respect to the issue of choosing to add support for multiple API's, I'd be fine to pay for each API supported should that be an important consideration. Any info would be appreciated.

so I didn't see any of that. Just went into "Purchases" section out of curiosity and it simply said "expired". I didn't try to restart the affected NS so maybe would have seen something in that case. too late to test that now. sorry. edit: also searched today's log for "expired" and nothing was found

I just tried to purchase a trial version of this NS and have never used it either before. I guess there isn't a trial option for it, so I passed on it. While I think it would be cleaner, I'm just not sure it's going to be better than the reliable (if kludgy) solution I've been using since the pre-PG / 4.x days https://wiki.universal-devices.com/index.php?title=ISY-99i_Generic_Calendar_Using_Programs_and_Variables. I noticed trials I had "purchased" had expired (including your Weatherflow NS, @bpwwer) and I never got a notified (or charged), as I thought would happen. I did pay for them as soon as I realized but it might be worth implementing a reminder. It's an easy thing to forget, and maybe that's why some don't offer trials?

Would it be possible to provide support for multiple Airthings APIs, each with its own separate set of devices? If not within the same NS, can multiple NS instances be deployed on same Polisy or would one have to deploy multiple Polisy's to achieve this?

Yes, I've seen this issue after putting in / restoring a new PLM until I can go over to every battery device and "Write Updates to Device". The only way I know to disable that is by doing it in the AC. Are you referring to a way of doing this in a program that I could run first thing at startup?

Yes, programs are certainly part of the problem. Don't think I haven't look at that. I've got the Admin Console open all the time. It takes so long to start (5 mins, I think) that I don't close it - despite having been told multiple times it's not designed to do that. It crashes sometimes but generally runs for me for several days. I've re-written entire groups of programs to try to streamline/manage the demand. I add lots of waits of different lengths in my programs. I realize that isn't a silver bullet since simply delaying an overload isn't preventing it, but I did used to see race conditions in the past that made it hard just to start the AC and haven't seen one of those for well over a year maybe two. I created a sDISABLEPROGRAMS.all variable set to the top folder that I can call with REST to get out that, if needed, though even that command did not always succeed in the worst cases. I also have SDISABLEPROGRAMS.lots that are peppered over several folders to help manage startups. Yes I had the crashes/reboots that occurred after moving to PG3 and adding Weatherflow, Airthings and ST-Inventory but that was an unusual thing. I've never had 3 crashes in 2 days before like I did in this case. It hasn't happened since I turned off ST-Inventory. And I can manually run ST-Inventory until it updates and things don't crash. It hasn't really helped to disable a group of programs - I've tried that. Yes, it reduces the load but then I've just cut off a whole group of functionality. It just takes a load off that removing any group of programs would do. Certainly I could simply do less with ISY, which is why I'm thinking of getting a second controller. Probably another iSY but I won't lie it's got me thinking maybe I should get something else. The next month or two will be critical to this decision. I don't usually get crashes any more, just some things that don't work or are delayed. I see socket failure messages in AC at random and full queues in error log at startup (a process which I've programmed as much as possible to stagger events and program but can only do so much) That said, you gave me a clue as to what to look for that I didn't have before - or, more accurately stated, that I didn't know/think about before - the time it takes for PG3 to process requests. While it's not inside ISY stuff, it could provide clues so maybe I could get useful info by disabling groups of programs. What I think would be nice is to have the event viewer entries saved to SD like the log/ error log so I could see what's happening just before a crash. Are they and I just don't know where to get them? That said, the log and error log rarely help after crashes so perhaps logging is the first thing to go during an overload situation, meaning I wouldn't get any info from event viewer log either. Another thing I just thought of would be having the PG3 response time in an ISY device that I could save in a variable and periodically append to a web page with a timestamp. Then I could link PG3 load entries, log entries, error log entries, and event viewer entries to maybe get more info to help determine the root cause. To date my issue is that more often than not I can't determine the root cause of specific failures.

I wouldn't want @Michel Kohanim/UDI to spend any time on trying to fix problems that are simply horsepower related (i.e. not enough of it on 994i). I'm very keen to move to IoP and 700-series Zwave for the added hp and because a number of my zwave devices are not working well and the vendor is basically saying its a problem with my controller. So getting the latest dongle and the zwave migration tool are the top priority. That said if UDI (or anyone else) knows IoP will not fix my issues, I'd like to know sooner rather than later. I'm guessing, though, the only way to know is for me to move to IoP to find out. One of the things that hasn't been discussed so far that you might be able to provide insight on, is the delay inherent in communicating with the various devices (insteon and zwave) and how that may (or won't) cause bottlenecks/performance issues in dealing with NS' using IoP. No one can change the fact that the device communication is slow and can be a relative eternity if there are weaknesses in the network connections or lots of incoming and outgoing traffic at the same time. I think the waiting/processing of insteon and zwave events is a factor in my performance problems using 994i. How much of a factor might this be when I move to IoP? Is IoP going to be able to handle all PG3 traffic even while it waits separately for insteon or zwave events to finish? I've heard lots of mention of "I have tons of NS and no problem" but no one (elsewhere either) has yet said "I have (as many or more than) 177 insteon devices and 128 zwave devices and a ton of NS using 994i, and I'm not having any problems." Throw in mention of 900+ programs and that's when I'll know someone's experience is relevant to my situation. It's clear to me I'm an outlier in terms of the demand I put on ISY so not asking you to fix stuff that would be just for me. I might, however, be a canary in a coal mine. I hope so because I'd like to see Polisy gain huge popularity and end up being put to heavy use like I have by many. Thanks again for having patiently addressed my questions and comments.

Looking to deploy Polisy/IoP in another location and am looking to confirm/correct an assumption I'm making. I'm thinking I'd be able to connect one or more others devices to one or more of the 3 ethernet ports on a Polisy PRO such that the other devices can talk to Polisy/IoP *AND* the rest of my network plus the internet, which would all be upstream over the Polisy Pro's wifi connection. If the assumption is correct, will the Polisy Pro be acting like a router - assigning a different subnet to my other connected device and NAT'ing - or a switch/hub? Am I able to choose?

@bpwwer No, I didn't miss your mention of Tempest hub feeding the data to NS every 60 seconds. I just thought there might be the ability in the NS to control when it sends the data to ISY, i.e. store the hub data in NS table then every x seconds (or whatever user sets) potentially with y seconds delay in between send the data to ISY. I don't know what's possible and not possible so I'm just asking. Sorry for my ignorance. Didn't mean to offend or annoy. I'm hopeful the move to IoP will significantly improve things. I am, however, preparing myself for the possibility that I may need a second HA controller. I'm sure separating my HVAC from my lighting would solve my problems even if I stayed with the 994i but two controllers does have several drawbacks and added costs. Thanks for all the info you've been patiently providing.

Darn, I changed the short poll on Weatherflow from 60 to 150 thinking it would delay updates to every 2 1/2 mins but I now see it didn't have the anticipated effect. Any chance you could change that @bpwwer? Attached are sample log entries for both Weatherflow and Airthings for about the last hour. I downloaded the PG3 log, which only includes includes today's entries and I searched it for Try: 2 and Try: 3. Only found one Try: 2. but all the tries (Try: 1) I visually scanned for are taking hundreds and even thousands of milliseconds. Here's a sample. 8/15/2022, 24:00:18 [pg3] debug: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [200] :: 448.735586ms - 8/15/2022, 24:00:19 [pg3] debug: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [200] :: 723.250318ms 8/15/2022, 24:00:19 [pg3] debug: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [200] :: 1021.064203ms - 8/15/2022, 24:00:25 [pg3] debug: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [200] :: 703.886677ms - 8/15/2022, 24:00:25 [pg3] debug: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [200] :: 743.913189ms - 8/15/2022, 24:00:26 [pg3] debug: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [200] :: 1055.351757ms - 8/15/2022, 24:00:26 [pg3] debug: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [200] :: 1103.256553ms - Couldn't attach PG3 log here I think because it exceeds the max for an attachment (it's about 1.5M compressed) but if it would help, I can grab a chunk and provide it. WeatherflowAirthingsLogEntries-sample.zip

So I can see - and I think Bob explained - that all NS events go into a single PG3 queue. That could certainly help manage the push of data to IoP but do IoP events also end up on that queue? If not, IoP could be really busy handling it's own events then have PG3 bombarding it with a steady stream of data (which trigger more ISY events - which is the problem and not the processing of getting the data itself) for extended period of time with no breaks or slow downs, no? I recently turned the Weatherflow NS back on after turning it and ST-Inventory OFF due to multiple ISY overloads to the point of crashing/rebooting when I first moved to PG3 and added it and ST-Inventory (which I now leave OFF), and Airthings NS'. See this post for all the gory details Since I've turned Weatherflow back ON I noticed most of my ISY lighting events are delayed, e.g. motion sensor that triggers lights takes forever to do its thing. Weatherflow is a very chatty NS and also takes 10-12 seconds to update all the data (not blaming the NS for all the data). I just saw an opportunity thanks to multiple Airthings devices to give ISY a break for what is my second most chatty NS. If the Airthings NS needs to call for each device's data one device at a time anyway, that would be an easy place to put in a break, I would think. That said, I get the point that if everything ends up on the PG3 queue and there was a lot of data on the queue, a break might not make a difference. Perhaps that means I need to ask Bob to consider adding a configurable "throttle" for PG3 queue processing? Of course that's not good for things where quick responses are desired. So then we would need to get into message priority setting by NS. The idea of putting a delay in Airthings NS was to make it kind of run at a lower priority, or at least lower speed. For sure I don't know how PG3 and IoP work, separately and together, so I'm no doubt missing a fair amount of the details that may make my suggestions completely 'out to lunch' but am throwing them out there anyway in case they lead to some tweaks for folks like me who love their ISY and have/want to give it as much work to do as possible. I've got plenty more ideas I want to throw ISY's way. I'm just waiting to be able to move to IoP so I can get past the 1000 program limit of the 994i. I just hope I won't be overloading IoP too.

Hi, @JimboAutomates, would it be possible to provide a configurable delay between device reports to ISY? Meaning NS would poll Airthings and send data for each device (6 sensors) to ISY with a configurable delay between each device. I have 7 devices and the update process can take 12-13 seconds under normal circumstances. An eternity in computer terms. I only request updates every 4 mins (what I think should be the default, BTW) to avoid exceeding Airthings rate limit and because updates to the cloud from each device are 5 minutes apart (though not all at the same time, of course). Technically that's 42 sensor readings. I can see from scanning my log files that not all 42 sensors typically end up being updated every 4 mins but most queries update 30 or more sensor readings. Now I do have an overloaded ISY (with close to 1000 programs) and might be the only one, or one of a few (which really surprises me) but please consider adding this in anyway next time you "open up" the NS. The data does not have to hit ISY in real time and allowing ISY to do other stuff in between device readings, if needed, is generally a good idea, IMO. I'm also in the process of planning an Indoor Air Quality automation package to resell a combination of Airthings sensors with a pre-programmed Polisy/IoP and your NS to capture data and automate HVAC functions. Am just waiting to see if the next few months lead to major improvements in terms of ISY Zwave support (and Matter, I'm reading) and, for my own use, a long awaited zwave migration tool from 994i to IoP to confirm a number of things.

yep. use it all the time and do like it. I suppose I could open it up on the side while I'm doing Admin Console related stuff with the Tempest weather station. It's the shear number of fields that comes with the Tempest weather station that's the problem, which is not the worst problem to have.

oh yes, right. Here are my current numbers from yesterday's run:

I caught the following in the event viewer: Sat 08/13/2022 11:41:54 AM : [ n006_207296] WINDDIR 265 (uom=76 prec=0) Sat 08/13/2022 11:41:54 AM : [D2D*CMP 036F] STS [n006_207296] WINDDIR B Cannot convert values (from=0E to=4C)