bpwwer

PG3 was never designed to allow any type of migration of node servers. When it installs a node server it configures the node server on the ISY to point back to itself and it stores information about the node server in it's database keyed on the ISY UUID. When you migrate from ISY to IoP, the IoP should end up with the node servers installed. But PG3 won't have any knowledge about them since it's database won't have any node servers that use the IoP UUID as the key. Thus, when you switch PG3 to use IoP as the selected ISY, all the node server's will show as unmanaged. In theory, you may be able to change all the database records to use the new IoP UUID but given that it's a key field, I'm not sure it will allow that. You can do a re-install of the node servers which will create new database entries for them without having to delete them from the IoP, thus all programming, etc. on the IoP that use the nodes will be preserved. However, you will have to re-configure the node servers in PG3 so make sure you document their configuration before you do anything. Also, it would be a good idea to backup PG3 just in case you need to go back and look at something. I believe that the following steps should work: 1. Select the IoP as the currently selected ISY in the ISYs menu on PG3. 2. Look up each node server in the node server store and use the "Install" button to re-install it. 3. The install dialog should have a option to re-install to the slot where it is currently listed as unmanaged. Select the re-install. 4. Re-configure the node server and everything should be working as it was before the migration. With your current setup with PG3 configured to talk to both the ISY and the IoP, you can switch it between the two to compare configurations. So I would recommend that you keep it like that and not rewrite the ISY IP/port with the IoP IP/port. Once everything is working with IoP, then you can simply delete the ISY configuration from PG3.

The node server has been available for over a year and you're the first to notice that that the notice messages have the wrong service in them. Pushed out version 2.0.6 that fixes the messages. It's the weatherbit service so it uses the weatherbit.io API key. I'm not sure which documentation you're referring to. The configuration help text says: The WeatherBit.io node server has the following user configuration parameters: - APIkey : Your API ID, needed to authorize connection to the WeatherBit API. - Elevation : The elevation, in meters, of the location. Default is 0 - Forecast Days: The number of days of forecast data to track* - Location : Location to get data for. Can be specified as: - lat&lon Ex: lat=38.123&lon=-78.543 - city,state Ex: city=Raleigh,NC - city&contry Ex: city=Raleigh&country=US - city\_id Ex: city\_id=8953360 - station Ex: station=KSEA - postal\_code Ex: postal\_code=27601 - postal\_code&country Ex: postal\_code=27601&country=US - Plant Type: Used as part of the ETo calculation to compensate for different types of ground cover. Default is 0.23 - Units : M for si and I for imperial. Default is M *The number of days of forecast data and poll times depend on the plan. - Free plan, 7 days max, short poll 1800, long poll 43200 - Hobbyist plan, 7 days max, short poll 250, long poll 21600 - Starter plan, 16 days max, short poll 60, long poll 3600 To get an API key, register at www.weatherbit.io What's not clear about that?

Are you using Wifi to connect to the Polisy? If so, the upgrade probably changed the hardward ID PG3 uses for licenses. You'll have to submit a ticket and get the licenses moved over to the new hardware ID.

I don't see any errors from PG3, just warnings. I've mentioned this before, PG3 makes 3 attempts to send the information to the ISY. Above shows that the first attempt failed, but the second attempt succeeded so that's not an error.

@wrj0I'll have to take a look at that. Both areas should do the same thing but there are currently corner cases where the re-install from the purchases page has to make assumptions. Sometimes it gets them wrong. This should get better as both the node server store entries and as everyone updates to the latest PG3 but it could take a while before that transition is complete.

I think you almost had it right. Try ${sys.node.n001_141766_11.CPW} The address created by the node server has the "n<slot>_" pre-pended to it when added to the ISY

A 404 error from the ISY means not found. As to why it's returning that, I have no idea. I would think that if it really wasn't found it would never update on the admin console. But I don't know anything about the ISY software.

Looking at the log I see that the node server seems to be having problems parsing the ISY error log. So possibly something unexpected is showing up there. However the node server is failing because: 2022-10-31 11:37:42 error: POLY: MQTT Error: Connection refused: Identifier rejected Which means that there is already a copy of the node server running and connected using that same slot and PG3 will only accept connections from one node server per slot. I did recently find a bug where if you pressed restart while a restart was in progress it would cause PG3 to think the first restart failed (which would mark the node server as disconnected, but the node server would stay connected. The second restart would try to start the node server again, but it gets rejected by PG3 because the first is still connected. The message above is what you see when that happens. A restart of PG3 should correct it.

Sorry about that. You didn't do anything wrong. A re-install is not supposed to touch the configuration but that was added to a fairly recent version of PG3 (3.1.12). In my limited testing, it seemed to leave the parameters in-tact when re-installing but there could be a bug.

When did you purchase Polyglot and Pi4 Servers from UDI? The software you are using was not written by UDI. Neither it nor Pi 4 hardware are UDI products. If you're looking for support for Polyglot V2, the git hub is here: https://github.com/UniversalDevicesInc/polyglot-v2 You can open an issue there but won't likely get support for that either as the person that wrote it is no longer actively maintaining it.

The current auto-upgrade process in 3.1.14 is buggy which is why I think he resorted to a re-install. But that's good advice in general.

The PS shows the kasa node server has been running since sometime on Tuesday. So it was running when you tried to restart it today. However, for some reason PG3 thinks it is not running. That's why you got the message that it wasn't running when you tried to restart it. When you re-installed it, it started the kasa node server (copy 2) but PG3 rejects it's attempt to connect because copy 1 is still connected. If you kill copy 1 (4728), it will disconnect from MQTT and if copy 2 is still attempting to connect, it will succeed. If not, it should now start by either pressing Start or Restart.

I'm not sure how many more ways I can say this. PG3 is not getting proper responses back from the ISY. There's nothing PG3 can do to make the ISY respond or respond in a timely manner. In the log you attached, there are many cases where it's taking 10+ seconds before it finally errors out waiting. I also see cases where it's taking almost that long on the third try to get a response. Requests to the ISY that should take less than 100ms are taking 100 times that long and then many are just outright failing. That's why you see so many node locked, waiting messages. That's exactly what PG3 is doing, waiting and waiting and waiting. When you see an unhandled exception / unhandled rejection it meas that something very unexpected happened, likely a compounding of error responses to the point that it doesn't know what to do.

There was a change in how the Polisy hardware ID is obtained. This change effected a small number of licenses. Submit a ticket to UDI and they can move the license from the old hardware ID to the new hardware ID.

Typically when a node server starts it does an update of all its nodes on the ISY. It makes will add any nodes that are missing and it will update the drivers to match what the node server thinks they should be. That's all automatic. However, in your case, PG3 isn't able to communicate reliably with the ISY so some things are properly added and somethings aren't. Because of this you're going to see more problems with node servers that have more nodes and more complex nodes than you will with simple node servers.

404 is not found. So the request was handled by the ISY but the ISY says that node/driver doesn't exist. You're likely seeing this because something earlier failed to configure the node properly on the ISY. I don't know of any tools as I said, my networking knowledge is just basic consumer level. I just know that what you're seeing isn't something that can be fixed in the PG3 software, it's something external to the program that's causing all the issues.

The log shows that two lights were grouped, but no lights were configured. If the node server sees that you entered configuration information, it doesn't try to discover the lights. You can force it to attempt discovery by clicking the Discover button. You need to either let it do discovery on startup or enter valid information about the lights.

All of the errors in your log are because of poor network connectivity with the ISY. PG3 is trying really hard to communicate with the ISY but there are just too many failures so things aren't going to work very well. I'm not a network engineer nor do I have experience with network device drivers. The ECONNABORT is something failing inside the OS level network driver. I don't know what specifically can trigger that. Possibly it is timing out waiting for packets or maybe getting corrupted packets. Googling ECONNABORT didn't really provide any clarity. I will say that don't ignore any component of the network path. I once had issues that I traced to a network cable having gone bad and never did figure out why it went bad. When the ISY is too busy to respond you'll get ECONNRESET errors and those are temporary and the second try by PG3 will then succeed. So all I can really tell you is that this is something else.

Since I have a developer's plan I haven't seen any issues. But it might be worth one of you emailing them and asking why your token is no longer working. Just invalidating it without any notification seems like poor customer service. However, it is possible that because of the new limits, current installations of the node server are triggering some type of violation response where they disable it for a while or maybe you just need to contact them to get it re-activated. Other than signing up as a developer, I don't have any special relationship with them and I don't recall seeing any news from them on the change in limits.

By going to the node server config and re-configuring it.

Based on the errors I'd say you have some significant network issues. This really has nothing to do with PG3 or the node servers. PG3 does have built in limits to how much network traffic it can generate to the ISY and with what you're doing by simply starting a single node server in no way comes close to any of those limits. Just for reference, my test environment currently has 30 node servers installed and I'm constantly stopping and restarting PG3 and I don't see any issues like this. When PG3 is trying to communicate with the ISY it will try up to 3 times for each request before giving up. In you airthings log we see: 11/14/2022, 11:03:58 [pg3] warn: ISY Response: [Try: 1] [<my 994i ID>] :: [HPE_INVALID_CONSTANT] :: 4949.559136ms -http://192.168.200.251:80/rest/nodes 11/14/2022, 11:04:00 [pg3] warn: ISY Response: [Try: 2] [<my 994i ID>] :: [HPE_INVALID_CONSTANT] :: 1991.814428ms -http://192.168.200.251:80/rest/nodes 11/14/2022, 11:04:05 [pg3] warn: ISY Response: [Try: 3] [<my 994i ID>] :: [ECONNABORTED] :: 5012.364673ms -http://192.168.200.251:80/rest/nodes 11/14/2022, 11:04:10 [pg3] error: ISY Response: [MAX TRIES EXCEEDED] [<my 994i ID>] :: [ECONNABORTED] :: 5014.965651ms -http://192.168.200.251:80/rest/nodes The HPE_INVALID_CONSTANT error means that PG3 got back a corrupted response from the ISY. It also took about 5 seconds to get that. I'm not sure what ECONNABORTED means specifically as it's not something I normally see. But it does mean the connection between PG3 and ISY was aborted for some reason. We see that each try is taking quite a while. 5 seconds, 2 seconds, 5 seconds. Normal times would be 5-100ms I will occasionally see ECONNRESET messages which mean the ISY is too busy to handle the request and then on try 2, the request will succeed. All of this points to either a really bad network connection, a failing network device (router/switch) or a failing ISY.

The node server doesn't seem to find any of your devices. node address b4e84255b24c does not exist. {'address': 'b4e84255b24c', 'cmd': 'DON', 'query': {}} I'd suspect that the IP addresses changed.

What shows up in the node server log when you restart it?

I was wrong about the API change. I can't find anything wrong. However, the free plan limits are now pretty low and you do need to have the short poll, long poll and number of forecast days set to stay below those limits. If you try to get more than 7 days of forecast data with the free or hobbyist plans, the node server will fail to start as it will be sit there waiting for more data that it will never receive. This makes things a bit more difficult since the node server doesn't have any way to know what plan you have so it can't auto-adjust the parameters. I've updated the documentation and configuration help to reflect the latest limits.

Looks like they have a completely new API and the old one no longer works. Converting the node server to use the new API is not a simple task so it may be a few days before a new version is available.