bpwwer

Always check the log files. Most node servers don't try to report errors to the UI and rely on the log files as the main method to report any issues they encounter. If possible, always download a log package and include it when reporting node server issues. Unless the issue is obvious the node server author, they will almost always request the log package. From the description, it sounds like the node server is unable to connect to the CAM (or itach). I don't understand what you are trying to report about programs. A program condition can be an "and" or an "or", there isn't an "if" option.

WeatherFlow doesn't report the actual lightning sensor data to the app. What they report on the app is something they generate by looking at more than just your sensor. The node server, when configured to read data from the local device, reports just what the local device reports. For the rest of the data, this should be the same, it's just the lighting data that can differ. The lightning data is also a bit different in that I think the app shows the last lightning strike data, the node server reports the last thing the sensor reports. From your app above, it shows the last strike was 7 minutes ago, the node server is displaying the current data reported by the sensor (not the data reported 7 minutes ago).

That sounds more like an issue with the API than the node server, but I don't own any Sonos devices and can't attempt to reproduce or test. The node-sonos-http-api library has 161 open issues, if you can reproduce the issue using just the API, you can enter an issue with the library. However, it appears that the maintainer is only updating the library when someone sends an actual bug fix to him so just opening an issue may not get any resolution. If you can trace the issue to something the node server is doing wrong, I can take a look and attempt to fix it. However at this point, I believe the node server is simply calling the join API with the two devices so there's little chance that the node server is doing something wrong. When the node server log is set to debug level, it does output some information about what it is doing when you do the Join. Maybe that would help.

One has an 'x' at the end of the name PG3x started as an experiment to see if we could use an external MQTT broker instead of the internal broker library being used in PG3. There were some reported issues that we believed were caused by bugs in the internal MQTT broker library code. This was basically an internal change with no change in functionality. Once we were certain the external MQTT broker would work, it made it possible to do some things that weren't really possible before. Run node servers under separate/unique user accounts for additional security Allow for remote access (currently used by UD Mobile) to PG3 Allow node servers to access remote authentication mechanisms (Ring) That's really it for differences. Everything else remained the same. As of PG3 version 3.1.23, UDI is no longer maintaining PG3. Bug fixes and new features have only been applied to PG3x. Many of the features are targeted at node server developers but there have been a few UI enhancements in PG3x. I've been maintaining the PG3 code by applying all the bug fixes and enhancements made to PG3x, but since UDI isn't releasing it, it's been just for my personal use.

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.