bpwwer

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.

There are a couple of non-errors that can cause that error message. If you haven't purchased any node servers yet, the list is empty and it reports that message. It may also report that message if your portal login token has expired, in that case it will refresh the token but it doesn't get the new token until after it's tried to get the list of purchased node servers. A Sync Purchases should work to get the list. It tried to re-direct you to the portal but it looks like something blocked it. That would be something on your end (AV software, maybe pop-up blocker). The flash is the browser trying to open a new tab/window to go to the portal purchase URL, but then something shut it down immediately.

Most likely it is because the query to Ambient Weather returned an error instead of data (or no data). They aren't known for their reliability. It looks like the AC hasn't read the profile files. If it hasn't read the profile files, it doesn't know how to layout the data so it uses whatever the last node viewed's layout. The main layout should have a lot more values. Restarting the AC will cause it to re-read the profile files. If that doesn't help, re-send the profile files using the Upload Profile button on the PG3 node details page and then restart the AC again after that.

@Bumbershoot I think the problem is that you changed the wrong credentials in PG3. You said: The username/password on the Profile tab are the credentials that the UI will use to talk with the PG3 server side and aren't related to the ISY at all. That exist to allow you to restrict who can run the PG3 UI. The ISY credentials are under the ISYs menu by selecting the Edit Current ISY option. That shows the ISY IP Address, port, username, and password. The username/password here needs to match what you set the IOP username/password to. @jkrausDeleting the ISY and re-adding could cause problems with existing node server installations. That probably causes it to recreate security tokens so it ends up looking like a new ISY. I don't believe I've had to delete an ISY and re-add it, at least not in a very long time so I'd have to dig through the code to see what that really does internally.

That certainly seems legit. Monitor the PG3 log after the update. There should be a lot of 401 errors before you change it in PG3, but they should stop almost immediately after changing it.