bpwwer

PurpleAir recently discontinued the API that was being used by the node server. Version 2.0.2 updates the node server to use the current API supported by PurpleAir. The new API requires an API key to access the public sensor data. Anyone can request an API key. To use verson 2.0.2 of the node server, you will first have to send email to contact at purpleair dot com and request a READ API key. Use the API key they proved to configure the node server. A Custom Parameter called "APIKey" (note case) must be created to hold your API Key. You should be able to add this custom parameter after upgrading or delete version 2.0.1 and re-install version 2.0.2 (make note of the sensor ID's you previously configured as you'll need those).

PG3 3.0.62 works with Node 17.x PG3 3.0.63 works with Node 18.x If you update the packages on the Polisy, it should update both PG3 and Node so they are in sync. If you force it to update only one, PG3 will not work. There is no difference between versions 3.0.62 and 3.0.63 other than updating the dependent Node libraries to work with Node 18.x

Hello Everyone, This is the support thread for PG3 v3.0.63

I'm not sure. No one reported any issues when the time change happened last fall. This issue was reported by someone who was messing around with the system time on their Polisy. That's a good point and I'll have to elevate the priority to check that.

I was just about to post here that I pushed out a new version, updated to work with node 18. But I see you noticed. Thanks for letting me know that it's working.

Hello all, We are very happy to introduce PG3 v3.0.63 which is the first production release of PG3. To use the latest version of PG3, you should also be running the latest version of IOP. Follow the instructions in the IOP release announcement to upgrade IOP to the latest version. To upgrade PG3: - In the Admin Console, click on Configuration, Upgrade Packages. After the upgrade is complete you will need to restart PG3. From PG3 select System-> Restart Polyglot 3 Bug fixes: None (This version is identical to release candidate #2 (v3.0.62) Enhancements: Updated to work with Node.js version 18.2 (latest version). Make sure you have (or will have as part of the upgrade) Node.js 18.2 Support Thread:

Yup it does. It appears that PG3 (or rather one of it's dependencies) doesn't work with the new version of Node.js. You'll have try rolling back the version of node to 17.x or wait until I can get PG3 updated to work with node 18.

Looks like it installed correctly. The node server author will have to take a look at it to figure out why it's not working.

You could try deleting and re-install the node server again. It looks like the required "govee-api-laggat" python library didn't get installed. If that doesn't help, then you'll need to post the installation errors from the PG2 or PG3 log file.

Where is it showing "Disconnected"? Is it the Admin Console or the PG3 dashboard or PG3 node details page? If it's the one of the PG3 screens, you may want to just refresh the browser, sometimes the browser caches stuff and what you see is the cached status instead of the current status. If it's the Admin Console, have you re-started it after the latest version of the node server installed? It could be that the Admin Console needs to re-read the profile files to display correctly.

Both versions use the same (now removed) api so neither should be working. I've contacted Purple Air to try and get the information needed to use the new API, I'm waiting to hear back. Based on what I've read in the API documents, it may be a lot more difficult to use with PG2 and even for PG3 will require the main code for the node server to be re-written. I won't know more until they actually respond.

Looks like Purple Air has discontinued the API that was being used by this node server. From a recent forum post: That was dated May 26th which is roughly the same time mine stopped working.

I'd need to see the logs, it sounds like it crashes just after starting.

There could be issues with the way it's being broadcast as well. How FreeBSD does network broadcasts is different from how it's done on Linux and the Python library being used to do the WOL in the node server was probably written to work on Linux. In general, the IP address shouldn't be needed when sending out WOL, but without it, it didn't work at all on FreeBSD. If there are too many problems getting this to work, I may have to abandon using the library and just write the code to handle the FreeBSD broadcast directly in the node server.

Unfortunately, it's not that simple. Even to start a node server we rely on information from the store. Most of the information is cached locally so it should work without cloud access, but there are features that depend on the data in the store being up-to-date. Node servers that make use of those features may not work without cloud access. I'm continually working to make sure we don't end up with a system that won't work if it doesn't have access to the cloud.

I've thought about that. In fact, I planning to test doing just that soon. My concern is that there probably should be a way to access it when you don't have access to the portal.

Based on my past experience with Ambient I don't think they care. Their API is already a mess and this is just one problem with it. I'll have to make a bunch of changes to make the battery values correct for all the different sensors. With everything else I'm working on, I'm not sure when I'll get around to it.

There are more things than just the node server store that require the portal access token. And there are future features that will require it also. Rather than putting buttons on all the various screens that require it, I decided to try incorporating it into the initial login.

There are some connections that PG3 makes that are using SSL for a secure connection. The connections between PG3 and the node servers are secure. You can make use of secure connection between the UI and PG3 (but you have to manually trust the certificate). Right now, the http client that PG3 uses wants to validate the certificate by default, but because you don't interact with PG3 core directly, you can't tell it to trust the ISY's self signed certificate. Also, if your ISY had a certificate that was issued by a known certificate authority, then it could be authenticated by PG3 automatically and the secure connection would work.

PG3 doesn't yet have a way to reset the username/password to defaults. You should probably file a ticket with UDI and someone will have to remote into your Polisy to fix it.

I understand that the label isn't indicating state. If you look at the different sensor's battery reporting, for some sensors 0 means good but for other sensors 0 means low. You'd think that "0" would mean the same thing for all sensor battery reports. Even if the sensor hardware is different, the API should correct that and make it consistent. I guess we should be thankful that they always use 0/1 and don't have some sensors that report the actual battery voltage. It's going to take a lot more work to replace the generic parser code that says if sensor has a battery field, create a node value for it. To having to actually look at what type of sensor the battery field is form and map that to the correct battery logic for that sensor.

It looks like you're trying to use https://192.168.0.120:8443 for the ISY IP address. This should be http://192.168.0.120:8080 Trying to use a secure (https) connection from PG3 to the ISY won't work unless your ISY has a valid SSL certificate. By default the ISY uses a self-signed SSL certificate for secure connections but most things will reject that now as self-signed certificates can't be validated. Which is what happened here. PG3 attempts to connect to the ISY, sees the self-signed certificate and aborts the connection since it can't verify that the certificate is legit.

Right now, all of those have their own authentication credentials. The default for PG3 is admin/admin unless you've changed it. While these are the same values as the default for the Polisy, they are not linked in any way.

I don't know why it stopped updating. I did find a problem with the way it was starting and that's what was causing the "Error getting credentials: (invalid_grant) Bad Request". It would do this for any restart after the initial authentication. I just pushed version 1.0.3 to the store that fixes it.

You don't show enough of the log to be sure, but my guess is that there are a lot of 401 errors in there. Which means that the ISY credentials in the PG3 ISY config are wrong. Go to the ISY -> Edit Current ISY menu and update the ISY username and password then hit save. You'll have to delete and re-install the node servers as PG3 currently thinks they are installed on the ISY but they aren't.