bpwwer

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.

I just tested it myself and everything worked exactly like I expected. Changed password on admin account using AC Restarted AC to verify that I had to use the new password PG3 was reporting lots of 401 (authentication failed errors) which is to be expected since it is still using the old password. ISY -> edit current ISY, change password to new password and hit save PG3 stops reporting errors and starts communicating properly with ISY. All the node servers have continued to operate without any issues throughout this. I'm not sure what @Michel Kohanimmeant, but the only reason to delete and reinstall a node server would be if you changed to a different ISY. The node server doesn't know the ISY username or password so changing that will not effect the node server. (in general, there are some node servers that communicate directly with the ISY, those may need to restarted to get the new username/password) There may be something else going on with this that I'm not aware of so I can't say for sure that an uninstall/re-install wasn't required, but just changing the ISY password does not require node servers to be uninstalled/re-installed. @BumbershootIt sounds like there was something wrong with the credentials you entered in PG3. Possibly not even your fault. I seem to remember there being certain restrictions on what could be entered for the ISY password so that maybe what you actually typed wasn't what it ended up being set to. An example of this would be if the ISY limited the length of the password to 8 characters. The AC knows this limit so it always truncates what you type to 8 characters. PG3 doesn't so it would send the longer version and fail to authenticate.

If the password was changed on the ISY and PG3 was not updated with the new password, PG3 will report the errors in it's log (probably lots and lots of 401 (failed to authenticate) errors. You should just be able to update the ISY account info in PG3 under ISY -> Edit Current ISY. If that didn't work, it's a bug. There shouldn't be any need to restart anything let along delete and re-install.

That's been the main goal of PG3. A lot of the node servers for PG2 seem to have been developed but then abandoned since the time it takes to maintain them can quickly become larger than the initial development time. The expectation is that by being compensated for the effort, they'll be more likely to continue maintaining and supporting their node servers. At some point, the default configuration on a Polisy will switch to PG3 being installed and PG2 not being installed by default. Eventually, PG2 may be removed, but that will be a while. Since PG2 is an open source project, how long it remains viable to run on something other than an Polisy will be up to the "community".

In general, the PG3 and/or the node server log will provide information to help understand what is happening.

You'd want to do it from PG2. The PG2 delete will delete the configuration in PG2 and delete the configuration and nodes on the ISY. The delete on the AC will only delete the configuration from the ISY.

You're welcome. There actually is an issue entered to restore individual node servers from PG2. Right now, resources to work PG3 features is limited. A feature like that is a convenience for the initial migration and will likely never be used after that. So it's hard to justify spending resources on something like that.

Wake-On-Lan node server now in the PG3 node server store.

No, it's probably not an ISY thing, I must still have something wrong in the profile files or you don't have the most recent profile files loaded in the AC. Here's what I see on mine: Try the "Upload Profile" button on the PG3 node details page and then restart the AC.

No, the restore is kind of an all or nothing. As part of the restore, it changes the configuration on the ISY to point back to the PG3 version. If you then delete the PG3 version, it will delete the node server from both PG3 and the ISY. The PG2 version will no longer work. Possibly you could then delete the PG2 version and re-install the PG2 . If you just want to partially move to PG3, I'd recommend not trying to use the restore from PG2 backup and just delete the node server from PG2, install the PG3 version in the same slot, re-configure and fix anything that broke. That's the cleanest way and you can concentrate on making sure each one works correctly before moving on to the next.

There was a typo in one of the OpenWeatherMap files. I've fixed so the latest version 3.1.3 should show connected/disconnected