johnnyt

good idea. would this adapter work? It would be a bit cheaper (in Cdn $) and get to me faster. It reads like it would also be compatible with more SSDs... https://www.amazon.ca/gp/product/B075FR3ZD4/ref=ox_sc_act_title_1?smid=A1X7UA978W3K5N&th=1 The one in previous post says: "only supports mSATA SSD (3cm*5cm), and does not support SATA Mini PCIE/PATA mini PCIE/RAID MINI PCIE SSD." while this one says "Support full size mSATA ssd 51mm(L) x 30mm(W) x 3.8mm(H). Supports 3.3 Volt Mini PCI-e SSD mSATA Module" Is this one compatible with more SSDs than the one above, or is this comparing an apple to an orange and it won't even work with Polisy SSD?

Thanks @IndyMike. Very interesting to see you were getting 8-16 errors a week for 8 weeks, and no less than 1-2/week the rest of the past 5 months (without a PLM replacement I assume.) If my 4 PLMs can last at least 6 months each once the errors start coming up, and retries make them benign from a functionality perspective (though I don't know if that's the case), that would give me 2 years to plan/execute my move off insteon. I can probably live with that. Also very interesting that you wonder if it isn't because of heavy ISY load. I began to see my ISY overloaded (underpowered) at least 2-3 years ago. And despite multiple efforts at rewriting entire segments of programs with generous "waits" and constant considerations for timing of actions, I continue to intermittently but repeatedly suffer with slow response and even spontaneous reboots suspected to be because of overloads. Today, with 173 insteon nodes, 152 zwave nodes, and 990 programs, I don't think I can go 2 weeks without some kind of problem (crash, spontaneous time changes to 2 years in the future, spontaneous reboots, etc.). While I don't believe all my problems are overload related, I'm really hoping the move to IoP will eliminate many of my problems. (Just waiting for the zwave migration to be there, which, unfortunately, suffered another setback last week.) All that said, I'm seeing less than 5 errors/week. If it was an overload issue I'm thinking I would be seeing at least as many as you, if not more. You also made me curious and I went back looking for old error log files and with dngrep (for Windows) and excel, plus some internet how to's, I pulled together a historical view of -10 errors. I wasn't able to figure out how to do a chart by week when my data was by day for a straight apples-to-apples comparison but here's what I have between June 2019 and May 2021. Except for one day in Dec 2019 and a period between April and June 2020 I'm not seeing that many -10 errors. I'm guessing I likely replaced a PLM in that time period but I can't confirm exact dates when I've replaced PLMs. Fall 2022 was pretty consistent with the above, and never more than 1-2 in one day for the latter. I'm still left wondering if -10 errors recover with retries (i.e. are they generally benign) and how long / how many -10 errors I can take with a PLM before it needs to be fixed or replaced. Also, for that matter, what the fix for -10 errors is, e.g. capacitor? comms? processor? etc. Thanks again for your insights.

Yes there's a reinstall button but given the following preamble that suggested 0.0.6 was really old and missing basic stuff that would even allow PG3 and/or the NS to react properly to a "normal" reinstall using the button you mention it, plus the comment that the "easy solution is to just re-install the node server to the same slot. " suggested to me that a "fresh" install was needed. My bad. Won't happen again. In my defense, you and Bob have likely done more installs, reinstalls, and uninstalls than you even remember so it's all pretty obvious to you. Next time I do this (using reinstall button) it will be my first time doing it.

ok I tested this with another NS and it did delete the related ISY nodes. I guess it's been a while since I've deleted a node server. For sure pre-PG3 and maybe even when I was running node servers on separate boxes (not Polisy)

For future reference by qualifying that the re-install needed to be implied having to select the slot at install time. The only time one can physically select a specific slot when installing a NS is when there is nothing in that slot. Otherwise the slot is not shown in the drop down list.

In new v1.x I see the addition of a configurable option to "rename" nodes when they change in Airthings and wanted to check something. I ran into a glitch upgrading to v1.0.0 that resulted in all my nodes disappearing from ISY. In all my past dealings with any NS I haven't seen ISY lose nodes even if I uninstall a NS. I've always had to go back and delete the nodes in ISY if I was truly uninstalling something for good. This time, however, all my nodes were deleted by the upgrade. Is that because of the renaming feature, which I had set to True? Or was it related to one of the confirmed bugs in either v1.0.0 or PG3? I want to make sure I know the risks involved in enabling that feature. Also, if it is a risk, I'd like to suggest it be mentioned in explanation for this feature on configuration page. Thanks for putting an update out for this NS.

did the upgrade to 1.0.1 and all the nodes in ISY were restored and my programs see them properly. phew. all good now. thanks.

this is not an "easy solution". I just did uninstall/reinstall of another NS and my nodes have all disappeared in ISY and its hosed all my programs depending on those nodes (6 per device X 8 devices)

how do I go back? I lost all my airthings nodes in ISY and my programs are all have Node Status [null entry] Then Wait 2 seconds $sAQ.CO2.MasterBedroom.Value = Node Status [null entry] $sAQ.CO2.MiddleBedroom.Value = Node Status [null entry] $sAQ.CO2.NWBedroom.Value = Node Status [null entry] $sAQ.CO2.SWBedroom.Value = Node Status [null entry] $sAQ.CO2.MainFloor.Value = Node Status [null entry] $sAQ.CO2.RecRoom.Value = Node Status [null entry] Wait 1 second $sAQ.VOC.MainFloor.Value = Node Status [null entry] $sAQ.VOC.MasterBedroom.Value = Node Status [null entry] $sAQ.VOC.MiddleBedroom.Value = Node Status [null entry] $sAQ.VOC.NWBedroom.Value = Node Status [null entry] $sAQ.VOC.SWBedroom.Value = Node Status [null entry] $sAQ.VOC.RecRoom.Value = Node Status [null entry] Wait 1 second $sTemp.MasterBedroom.Airthings = Node Status [null entry] $sTemp.MasterBedroom.Airthings *= 100 $sTemp.MiddleBedroom.Airthings = Node Status [null entry] $sTemp.MiddleBedroom.Airthings *= 100 $sTemp.NWBedroom.Airthings = Node Status [null entry] $sTemp.NWBedroom.Airthings *= 100 $sTemp.MainFloor.Airthings = Node Status [null entry] $sTemp.MainFloor.Airthings *= 100 $sTemp.RecRoom.Airthings = Node Status [null entry] $sTemp.RecRoom.Airthings *= 100 $sTemp.SWBedroom.Airthings = Node Status [null entry] $sTemp.SWBedroom.Airthings *= 100 Wait 1 second $sHum.MainFloor.Airthings = Node Status [null entry] $sHum.MasterBedroom.Airthings = Node Status [null entry] $sHum.MiddleBedroom.Airthings = Node Status [null entry] $sHum.NWBedroom.Airthings = Node Status [null entry] $sHum.RecRoom.Airthings = Node Status [null entry] $sHum.SWBedroom.Airthings = Node Status [null entry] Wait 1 second $iAQ.Pressure.MainFloor = Node Status [null entry] $iAQ.Pressure.MasterBedroom = Node Status [null entry] $iAQ.Pressure.MiddleBedroom = Node Status [null entry] $iAQ.Pressure.NWBedroom = Node Status [null entry] $iAQ.Pressure.SWBedroom = Node Status [null entry] $iAQ.Pressure.RecRoom = Node Status [null entry] Wait 1 second $sAQ.Radon.MainFloor = Node Status [null entry] $sAQ.Radon.MasterBedrm = Node Status [null entry] $sAQ.Radon.MiddleBedroom = Node Status [null entry] $sAQ.Radon.NWBedroom = Node Status [null entry] $sAQ.Radon.RecRoom = Node Status [null entry] $sAQ.Radon.SWBedroom = Node Status [null entry] $sAQ.Radon.UtilityRoom = Node Status [null entry] Wait 1 second $sAQ.HRV.Hum = Node Status [null entry] $sAQ.HRV.Radon = Node Status [null entry] $sAQ.HRV.Temp = Node Status [null entry] $sAQ.HRV.VOC = Node Status [null entry] Wait 1 second Send Notification to 'jean' content 'IAQ - Raw Data - HRV' Run Program 'Calc AQ Averages and add Weather data' (Then Path) Else - No Actions - (To add one, press 'Action')

@Jimbo.Automates Am getting errors after uninstalling and reinstalling to get v1.0.0, per this workaround: 2022-12-12 21:03:19,507 Thread-19 udi_interface DEBUG Controller:add_node: Adding: Guest Bedroom 2022-12-12 21:03:19,508 Thread-19 udi_interface ERROR udi_interface:write: Exception in thread will PM log to you

Bought a new SD card that's 32GB and, when I double checked the instructions on how to replace it, it says "ISY supports up to a 16GB SD card". See https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Replacing/Formatting_an_SD_Card It's a bit old so thinking it's outdated, and I wasn't able to find anything smaller than 32GB. Is it just a case that it won't format/use more than 16GB (no big deal), or will using a bigger SD card actually fail?

Thanks for the update! Did a restart of the Node Server after seeing message that a restart was needed but it still says v 0.0.6. This is *after* PG3 upgrade to 3.1.16, which I think was supposed to fix this issue with another NS:

very interesting. thanks for posting, @IndyMike. It's UDI support that brought the -10 errors and what they mean to my attention when looking into something else. Even the ebay guy that refurbished 3 of the 4 PLMs I have is a little surprised that all three of my refurbished PLMs are seeing "so many problems". The reality is that I'm not noticing any problems in real life. There may be a bad/missed command at the time of the -10 that recovers thanks to retries? Overall, though, my insteon is working as well as it has been in general. While I don't understand why devices (mostly KPLs) end up with bad links over time, hey, I've been living with it for more than a decade now so that's Situation Normal AFU. So what is this problem really? is it it a 994i issue, will any repair one can do today fix it? Also, does the PLM/ISY recover from it, meaning they are really just warnings, if that? Also, if it is a warning sign of a degraded unrepairable PLM, could it still function for another year or two? Looks like it has worked fine for you for 3 years! Maybe just having 4 spares with good capacitors will allow me to continue using Insteon until I can move off it (which is the plan, but I did want to drive my multi thousand dollar insteon device investment into the ground)

oh yes. before I posted here. The answer I got that way was basically the second post above.

Thanks! Interesting other post, especially about the repair service in Toronto area (more than just PLM too) as I'm in Canada. Missing info on what one gets for how much, and history/depth of feedback compared with NY-based ebay service I've used but will keep close eye on that. RE: 994i serial port. Interestingly I replaced the 994i I was using just last weekend with an older one to fix unrelated issues but I still see -10 errors with this other one. Would be even more rare to see that problem with two separate units.

A couple days ago, on your suggestion, I replaced the cable to the PLM with a brand new cable that I first tested using my managed switch 'cable test' function. While the old cable also tested okay, I was nonetheless hopeful about the new cable because I took the opportunity to check/restore all my keypadlincs (about 8 of them), which almost all had some bad links (common after a while or when replacing PLM, which I did 3 days ago). I figured that was a good stress test and no errors were reported. But, alas, last night I got hit with a couple -10 errors during query all, which is when majority of them occur. I think I'll send one back to refurbisher see if the comms repair was the issue I should have sent them in for in the first place...

I went through error logs going back to before I got the PLMs refurbished. In about a month of testing 4 PLMs prior to refurbishing 3 of them, I saw about 23 "-10" errors in about 3 1/2 weeks. After the refurbishing, the first refurbished one I tested (a v 1.7) simply would not hear anything anymore. While it may have had some -10 errors, it was hearing insteon events before I refurbished it. I expect I will sent it back but waiting to see what else I might need to send in again. The second one I tested (v 2.6) has now been in production for at least 6 weeks and I found 29 "-10" errors in that time, so about 4.8 errors per week. That's more than I thought was happening. It seemed less frequent when I was spot checking things. I've replaced it (today) to see if the third one I had refurbished (a v1.C) does any better. I do see the ebay PLM fixer has a "Communication Repair" service that I did not think was my situation since things were working in general (I actually really notice anything not working). Before I go potentially throw out good money after bad, would the -10 errors fall into this category? (The first part was done as part of the refurbishing so the part after "Also" is the key stuff I didn't get done.)

wouldn't refurbishing them fix this?

I occasionally get -10 errors in ISY error log. I was told it indicates a defective PLM. The official error code description is "-10 UNEXPECTED DEVICE RESPONSE". It has occurred intermittently with 4 different PLMs of different vintages that I've gone through with no noticeable issues. It's possible I just missed the issues when they happened but the point is that overall my different PLMs have been working. Furthermore I've had 3 of the four PLMs refurbished to upgrade the capacitors and other components designed to make them last longer by this ebay service with positive feedback and it didn't eliminate the errors. The guy who did the refurbishing didn't really know what this ISY error meant. He was familiar with ISY but not a user of it himself. Does anyone know what they mean in practice? Why wouldn't upgrading capacitors and other pieces not fix them? Any info would be appreciated.

same here. No rain expected for another couple days so can't say if the issue is fixed but I assume it is.

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

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

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

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

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