bpwwer

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.

Once you hit the Purchase button in PG3, everything then becomes the responsibility of the browser and the Portal. When I click purchase for the MyQ node server, I see this in the javascript console: Purchase 3cac3bad-92bb-40f4-966f-3b541e85c898 on 00:0d:b9:xx:xx:xx Navigated to https://my.isy.io/index.htm The first line is PG3 logging the fact that you're trying to purchase a node server for a specific Polisy. The second line is the browser loading the Portal URL's to make the purchase. At this point, your browser would be using the portal web site to make the purchase or cancel. When done, it returns to the PG3 store page. I can only debug issues that happening in PG3, I don't have the permissions to debug anything on the Portal. You'll have to open a ticket with UDI so the Portal support folks can take a look. Browsers have become a lot more security conscience in the past couple of years and will silently block things they think are a security risk. It may be something like that that's happening here.

For each node server in the store you can click on the node server name it should take you to a page with more info. For the various weather service node servers, this page will list what fields each support.

The battery information that Ambient reports is binary, 0 or 1. Currently 0 = OK and 1 = Low. Seems backwards, so maybe it is. I don't know where I got that info. I just checked the api documents and now I'm even more confused battout - Outdoor Battery - OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK) battin - Indoor Battery - OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK) batt1...batt10 - OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK) batt_25 - PM2.5 Air Quality Sensor Battery indication, OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK) batt_lightning - Lightning Detector Battery - 1=Low 0=OK batleak1...batleak4 - Leak Detector Battery - 1=Low 0=OK battsm1...battsm4 - Soil Moisture Battery - 1=OK, 0=Low batt_co2 - CO2 battery - 1=OK, 0=Low batt_cellgateway - Cellular Gateway - 1=OK, 0=Low Who in their right mind would do this????

You're looking at the node address and yes, the ISY limits what characters and how many can make up a node address. The node server is converting the mac address to a node address by stripping out the characters that aren't legal in an address and truncating it to fit the length limitation. If you look at the node server log it should show it sending the packet to the proper mac address.

Ok, I found the problem. You're the first to have a station with a lightning sensor and the lightning batter value was getting parsed as a second main battery causing the main node definition to invalid. I pushed out version 2.0.6 to the store, if you refresh the store and then restart the node server it should now parse the data correctly. You'll also have to restart the admin console after the node server starts to get the updated node definition.

Have you ever successfully purchased a node server? If not, then the "failed to get purchased node servers" error is expected because you have none to get. The PG3 log file won't have any information related to this. The PG3 core program isn't involved in the purchasing process. It is just the UI portion running in the browser and the UDI Portal. The problem is when your browser is told to open a new tab/window with the portal URL, it fails. Either your browser is blocking it or you have some firewall/av software that is blocking the connection to the Portal. The browser's javascript console might provide more information.

The "Load Profile" button won't give any visual indication that it's doing anything. It simply re-sends the profile files to the ISY. You can view the PG3 and verify that it really did upload them. If there are errors uploading the profile files, then that's the problem. If the admin console isn't showing the same values as what you posted above, it's because the admin console doesn't have the updated node definitions. It only reads those files from the ISY when it starts. So you must restart the admin console before it can show the correct values. If you deleted the node from the ISY, you'll have to restart the node server so it can re-create the node.

Since IoP no longer has support for Wake-On-Lan built in, we need a way to schedule and/or trigger systems to wake up. This node server allows you do do that. It is a very simple node server. To configure it you add custom parameters with a host name as the key and the mac address and IP address as the value. The host name is just for display purposes. The mac address and IP address are formatted as XX:XX:XX:XX:XX:XX/192.168.1.1 It's not picky about the separator character used for mac address (or if there even is one). For each custom parameter a node will be created. The node supports one command - send WOL packet to the host. If there are any additional features or improvements, let me know.

Thanks @Geddy!! I know I should let you know when I add new node servers.

Good point. Right now, there are too many different logins. It does need to be consolidated but that's going to take time. And the goal is for it to be possible to assume that node servers will stay running, at least that's one of the goals I have for my node servers. So for anyone that is having to restart node servers, please work with the node server author and let them know it is happening. It may be something simple that they can fix and make things more stable for you. I don't run a lot of node servers in my "production/home" setup, but I can't remember the last time I had to restart one. Usually it is is because of a power outage and when everything restarts that things may need a restart.

I can understand the confusing. For the record, I'd like to get rid of the profile/PG3 login screen and just rely on the Portal login to authenticate anything that needs to be authenticated. The only real use case for the PG3 login seems to be if you expose PG3 externally and I have no idea if anyone would do that or not.