bpwwer

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.

Typically, once you exceed a daily limit it won't reset until the next day and all calls to the service will fail until then.

@Goose66No, I don't think that would help. However, the node server can be re-installed to get the new version. From the store or from the purchased list, select install and there should be an option to re-install it in the existing slot. This will install the latest version without removing any existing nodes or resetting the configuration parameters.

It is a bug in 3.1.14. There are a couple of different issues related to how it tries to determine if an update is available. To enable support for multiple versions of the same node server a number of things had to change both in the store entries and in PG3. It's having issues dealing with node server that were installed from old style store entries detecting updates that now have the new style store entries. I believe I have the issue above fixed and am working some of the other issues.

It's a bug in the latest version of PG3.

I get this when I try to launch AC via cloud: java.io.FileNotFoundException: https://isy.universal-devices.com/iox/5.4.4/admin.jnlp

I'm still working on getting the update available notifications working but I'm getting close, I think. However, the auto update on restart should have worked. If you can, can you check the PG3 log and see if you can find where it tried (and I assume failed)? I'd like to know why it failed.

PG3 version 3.0.36 was probably an alpha release, none of the current information is probably valid for that version. Try the "Upgrade Packages" from the admin console again. For really out of date systems, it can take two attempts to get everything updated properly. Also note that it can take a while to update. 10+ minutes is not unreasonable. After the update is complete, you may have to reboot the polisy (use the reboot button in the admin console). If that doesn't clear things up you'll probably have to submit a ticket.

It's certainly possible they reduced the number of calls that can be made for the free plan. It currently says: 500 calls / per day 25 calls / per hour 3 calls / per second Which really means can't call it more than about once every 3 minutes or short poll needs to be 180 or larger.

When adding support for additional types of purchase options, the format of the entries in the node server store has changed. The latest version of PG3 can still install node servers entries that are in the old store format, but it can't detect the version change for node servers installed using old format. I'm working to make the detection a bit better. So node server store entries will need to transition from the old format to the new format and node server installations will need to be updated as well before the new version detection will work. However, the automatic update on restart should be able to detect the version update and automatically update on restart.

All the HTTP request to the WeatherBit servers are coming back with no response. The node server is probably not configured correctly.

Or if you're already running 3.1.12+, this might be bug in PG3.

A just releases a new version (2.0.7) that should fix the issue. The problem was that @jkosharek's station is reporting battery data that I had not seen before and the data parser ended up generating two battery drivers with the same name in the node. The ISY doesn't like that and the node was not really valid, hence it wasn't able to display it properly in the admin console.

What shows up in the log files for the node servers?

I don't have an Ambient station or account so I'd need access to your data to test and debug. It sounds like something could be wrong in the profile files created for your data. It should log what it is creating for the node definitions if you enable debug level logging. So first do that and send me the log.

@TechmanThat would imply that PG3 is not able to connect to whatever ISY is configured as the current ISY. The PG3 log should provide more info on why it's not connecting. Typically, it fails to connect if the username or password is wrong in ISYs->edit current ISY configuration. But it could also be the IP address or port number that is wrong. I just added this feature and it seemed to accurately detect if the ISY was connected or not in my testing, but there could also be a bug and it's giving a false reading.

Did you restart the admin console? You always have to restart the admin console after installing a node server or the admin console won't know how to display the nodes created by the node server.