bpwwer

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.

The isyAccess flag is still not working for me. The 'Backup' node server will require this, but when I set the checkbox in to indicate that the node server will need the user to grant permission, the request for user permission never shows up in the configuration tab of the node server once it's installed. Another issue is that I can no longer re-install node servers by going to the Purchases page. Instead, I have to search through the full node server store listing to find the node server I want to re-install. Why was this feature removed? The new developerMode lets me set it for any node server I have a license for, not just the node server's I created.

I had some time so I did some work to make a version with the fix applied. Version 1.0.10 is in the store now and has the proposed fix for the recalculateGroupVolume() crash. I have no way to test this, but the node server does install and run for me.

Sorry, apparently with Python you can indent comments wrong. Try 2.0.10

I just pushed version 2.0.9. I added polling support. So now at the poll interval it will attempt to query the zone power status for all zones. The default interval is 60 seconds (short poll) but you can change that to whatever you think is best. I also updated the query support so that now if you query a zone, it should actually query the controller for the zone info and update that. I removed the source status from the main controller node. Now that chained controllers are supported, the number of sources is variable (and even with the RIO controllers, it varies) so having a fixed number of source states there doesn't make sense. I could attempt to make that dynamic, but that's not easy with the way IoX nodes are defined and I'm not sure it's all that valuable. I could also create a node for each source, which might make more sense as with RIO there's more source info available. Let me know if you have any thoughts.

Ok, I'll add something to do that. Just the C3 and C5? How many different models do you have to test with?

Sorry, that was my fault. I last tested with RNET and missed updating one of the functions for RIO. Should be good with version 2.0.8 which I just submitted.

I just submitted version 2.0.7. This has support for chained controllers. It should detect you're second controller and add the sources and zones for it. To make this work, the zone addresses changed, so you might want to delete version 2.0.6 and install 2.0.7 instead of re-installing. It was a pretty massive change to support multiple controllers this way so hopefully I didn't break it too bad. I think I fixed the source selection bug too.

So the MCA-C5 is a 8 zone, 8 source controller. The RIO docs don't mention it so I wasn't sure. Version 2.0.6 will assume it's 6 zone, 6 source controller so expect that. I'll fix it so it's 8 zone, 8 source in the next release. The main goal with this release is to make sure it does create the 6 zone nodes and does show the sources you have configured (at least up to 6). Zone commands should work now too as it should no longer get stuck trying to access the source names. If you use the 'Refresh Store' button, it should show the new version. Otherwise you could have to wait up to 8 hours for it to show up automatically.

Version 2.0.1 does the unit conversion to metric for the day, month, and year nodes.

Thanks @garybixler! I'll have to look into the issue with the second controller. This node server was designed to support multiple-controllers but it doesn't recognize that they are linked so you have to add each one individually in the config. At least that's how it works for RNET based controllers. I'm looking through the log now and it looks like you clicked the "Add Controller" button for a second controller, but didn't configure a second controller. The log shows Processing controller {'port': 5000, 'nwprotocol': 'TCP', 'protocol': 'RNET'} Which fails. I don't think this is causing any other issues, but you probably should fix the configuration. The next thing I see is that your controller is reporting it's type as MCA-C5. I don't see that listed in the Russound RIO documentation, it only mentions MCA-66, MCA-88, and MCA-C6. The node server assumes that since it's not a MCA-88 that it's a 6 zone, 6 source controller. Is that correct? The problem was that the node server is waiting for the response to the get source name command but I had formatted the command wrong so it never got the source name, just an error response. It was sitting there waiting for the first source name. This should be fixed in 2.0.6 which is in the beta store now.