bpwwer

Yeah, that was the problem with PG3. Sometimes it wouldn't unzip all the files from the package and sometimes it would end up unzipping only part of the file. In your case, it looks like it didn't unzip correctly so the files wasn't complete or was corrupted. I think I might have this fixed but UDI isn't releasing new versions of PG3, only PG3x.

The PG3 log or the node server log? Since the node server isn't starting, there isn't a node server log to display, so that's expected to say not found. If there's no PG3 log, then PG3 isn't running and that's a very different problem When PG3 tries to start the node server, it should report any errors to the PG3 log. So you may want to attempt to start the node server and then switch to the PG3 log (Log menu, not the Log tab on the node server details page), download the log and PM or attach here. I'll take a look.

when the node server queries the Ambient server for data, what it gets back is not valid data. The node server then marks the station as offline until a query responses with valid data.

Testing is going well. Here's a bit of preview: The PG3 log might shed some light on why the node server's not starting. There is a known issue with PG3 where it will occasionally fail to install all of the node server files and that will typically cause the node server to not run. Since no new development (or even bug fixes) are happening to PG3, the current recommendation from UDI is to migrate to PG3x. Having access to your station's data has been a huge help so thanks again for that.

I see in your PG3 log a lot of messages like this: 8/22/2023, 12:26:24 [pg3] error: IoX Response: [MAX TRIES EXCEEDED] [00:0d:b9:53:2a:30] :: [null] :: 5009.897306ms - http://127.0.0.1:8080/rest/ns/profile/12/upload/nls/en_us.txt 8/22/2023, 12:26:24 [pg3] error: Error: POST http://127.0.0.1:8080/rest/ns/profile/12/upload/nls/en_us.txt Failed :: null 8/22/2023, 12:26:24 [pg3] info: ProfileUpload: upload of en_us.txt for slot 12 failed. Mostly, they seem to be related to uploading the profile files and if the profile files for a node server don't get uploaded, the AC may not display any updates from the node server. PG3x makes multiple attempts when it sends anything to the IoX. In general, it should succeed on the first attempt but in your log, the first, sometimes the second and even the third attempt are failing. A few people are also seeing this same thing. I don't know if it's something in PG3x or something in IoX that's causing it, but I'd suggest opening a support ticket.

It looks like a number of the commands had a delay of about 10 seconds. That corresponds with the PG3x send timeout of about 5 seconds meaning that the first two attempts PG3x made to update the IoX status timed out. You can verify this in the PG3x log by looking for lines that start with [Try 2] and [Try 3] If you're seeing those then that's the problem. I'd suggest submitting a ticket as this seems more like a PG3x or IoX problem than a node server problem.

You probably looked at it many times and it looked correct Sometimes it just takes a different set of eyes to see something like that.

geocode sounds like it may be referring to location. Make sure you have a valid location configured.

It re-runs the discovery process which is the same thing it does at startup. The use case would be when you add a new device, run discover instead of restarting the node server.

The '/' in the "Garden / Rec Rm" name is an invalid character for IoX. Thus the IoX never adds the node.

Don't know, you'd have to ask UDI. Seems like the first time you installed the node server it didn't or wasn't able to add nodes to the IoX. Without seeing the PG3x logs we'll never know. You always have to restart the AC after installing a new node server. The AC only reads the node definitions from IoX when it starts so to pick up the definitions for any new nodes added by node servers, it must be restarted.

The AC doesn't control Polyglot, hasn't ever controlled any version of it so none of the AC's node server menu items do anything for Polyglot based node servers. Orignally there were non-polyglot based node servers and those menu items where used with them, but most of those have been abandoned years ago. Now that you've messed with the node server configuration on the AC, nothing will work unless you can put it back exactly the same way it was originally. You may have to delete the node server both from the AC (using the delete button on that configuration screen) and deleting the node server in PG3x. The node server will create the nodes automatically on the IoX. If it doesn't, then PG3x will log the issue.

Good suggestion. The permission change was part of the security improvements made in PG3x. So, yes, the logs are more secure (not sure that's a good thing or not). Yes, the log file is rotated so that it only holds 24 hours work of log messages, from midnight to midnight. However, it does keep 14 days worth of logs for each node server (and PG3). They're just not accessible by any means other than the command line. Maybe adding a drop down selector to select which day's log you want to download from the UI would be helpful.

That's up to the developer to fix. They control what shows up in the store and what the node server reports as it's version. Unfortunately, we don't have any way to link those so the developer must make sure they both match.

The purchases page is showing what node servers you have a license for. If a beta version of a node server is using a different id from the production version then it is considered a separate node server and there is no way for PG3 (or UDI even) to know that they may be related. When the original multi-store feature was enabled, every store entry had to have a unique ID so there wasn't any way to link a beta version with a production version. That's no longer true, but is up to the developer to decide if they are linked or are total separate node servers. I think the recent change to the purchase page was to separate out the entries by store which is probably why you're seeing separate lines for the beta and production versions now. I think the only way to remove a node server license record is for someone to manually do that.

Update is triggered on a difference between the installed version and version listed in the store. It's a simple string comparison so yes, 1.0.00 is different from 1.0.0 and thus there's an update available (per the logic in PG3x).

The node server log viewer is different on PG3x than on PG3. PG3 shows both real-time entries and historical entries. The PG3x log only shows real-time entries. This means that when you navigate to the node server log page in PG3x, it will only show log entries that are written after you navigate there. So if you're navigating to the log page and away and back, it will always be empty when bring up the page. The log files are in each of node server's directories at /var/polyglot/pg3/ns/<nodeserver>/logs You can also use the "Download Log" button to download the entire log file.

Where does it list "Install"? The node server details page should show "Install" for the purchase option that you have a license for. Selecting install then gives you the option to either re-install it to an existing slot or do another install to a free slot. The Purchases page should have a button to "Re-install" if it currently installed. If you're seeing "Install" here, that would be a bug.

The query to the OpenWeather server is failing. If you turn on debug level logging, it should show what URL it is using to do the query and you can paste that into a browser address bar and see what the server is returning. My guess is that it's an invalid API key. OpenWeather seems to have a couple of different types of API keys and they aren't interchangeable.

Have you registered your Polisy/eisy with the UDI portal? It must be registered for the store functions to work.

@stevehoyt I can look at public stations with the website, but I can't access them via the API. I believe that if a station is "shared" then I can access that station's data via the API. When I look at a station there's a link at the top to share and uploads When I click on that it has a search for username to share the station with. I think that if you share your station with me, it will show up in my list of stations (which is currently empty). Otherwise, I think you'd have provide me both your API secret and API token which you're not really supposed to share.

I agree that having the update button when there's not an update is confusing. At one point I had changed it to show install -> node server not currently installed re-install -> node server currently installed update -> an update to the node server is available It was just a conditional check in the UI to make sure the right text was displayed, in all cases, I believe the button does the same thing, i.e. takes you to the store entry details page which gives the options of re-install to same slot or install to new slot.

@stevehoyt Would you be willing to share your station's data with me? I'm attempting to use the WeatherLink V2 API, but I don't have any way to test anything. Possibly sharing a station with me will allow my WeatherLink account to access the data via the new API and I'll be able to test. My WeatherLink account username is "bpaauwe".

Previously, I could go to the Purchases page and I had the option to install or re-install a node server I had a license for. If the node server was currently installed, I could re-install it. If the node node server wasn't currently installed, I could install it. Now I can only install it if it's not currently installed. The only way to re-install a currently installed node server is to do so through the node server store page. It's much easier to find the node server to re-install on the purchases page than the node server store page. It shows without an install button so no way to do anything with it from the purchases page. The node server is already installed and no, it's not one that I developed.

I could, but that would hide the problem. The problem is that you're searching for a store record only by nsid and picking the first one that matches. So when there's both a production store entry and either a beta or local store entry with the same nsid, you only use the isyAccess flag from the production entry. You should be looking up the store entry by both nsid and store so that you get the proper store entry. I really want to test changes to the node server using my local store entry before I make any changes to the production node server, including the store entry for the production node server.