bpwwer

Can you paste what you see in the purchases list?

The instructions for upgrading PG3 are posted with every release announcement: If something isn't clear about that, please let me know what you think would make it better. We're still trying to figure out why you're having issues upgrading YoLink. The node server store has been evolving over time as developers have asked for additional options for node server purchases. This has caused some confusion for both users and developers. What appears to have happened is that the production version of YoLink was entered as a new node server instead of an update to the beta version. What that means in this case, is that PG3 thinks you have YoLink(beta) installed in slot 1 so it can't install YoLink(production) there. It also looks like you have a license for YoLinkI(beta) but not a license for YoLink(production).

Version 3.0.63 of PG3 will no longer receive updates to node servers automatically. You need to update

The PG3 log should show why it's failing to upgrade. We need to see what's in the log after you stop and restart the node server.

Can you check if a copy of the node server is already running? Based on the line in the log that says it's already connected, I suspect that you have a copy running so it won't allow you to start another. Since you're expecting to run two copies, when the one installed on IoP is not running you should only have one active, if you have two, then you probably have a stuck/hung copy occupying slot one and can't start another copy

No, PG3 knows nothing of z-wave so it just backs up the installed node servers.

The point I was trying to make, was that when you do "update packages", it updates all packages that have an update available, not just PG3. Since there is zero interaction between PG3 and Z-Wave, it is far more likely that some other package update caused the problem than it is that the PG3 package update cause the problem. I understand that you did the updates specifically to get the new version of PG3 so that it appears that the PG3 update is a factor in the issue with z-wave. But until we really know what caused your issue, we shouldn't be attributing blame to any one component.

To be clear, "update packages" applies all pending updates, not just PG3. Those errors are coming from IoP and I believe there was also a recent update to IoP.

You should submit a ticket. Unfortunately with the current "upgrade packages" you get all pending updates, not just PG3. It's highly unlikely that upgrading PG3 would effect z-wave. But it is very possible that some other update would.

The uptime display in the footer isn't very useful. There are really two separate components to PG3; the server side running on Polisy and the UI running on your browser. The UI will pull the current uptime for the server when you first log in and then it continues to increment that. It isn't constantly polling the server to see what the server uptime is. If you restart the server, it doesn't restart the UI and the UI simply continues along, incrementing the uptime. That should probably be fixed at some point to periodically check the server and update the uptime, but things like that are pretty low on the priority list.

This issues is fixed in version 3.1.12, see the release announcement for the list of fixes in this version. It is available now.

Hello all, We are very happy to introduce PG3 v3.1.17 which is a minor update to work with Node version 19.5 To upgrade PG3: In the Admin Console, click on Configuration, Upgrade Packages (note, this can take many minutes, depending on how long it's been since you last updated.). After the upgrade is complete you will need to restart PG3. From PG3 select System-> Restart Polyglot 3. Once PG3 has restarted, reload /refresh the browser page. Changelog for 3.1.17 - Update to run with Node version 19.5 Changelog for 3.1.16 (December 9, 2022) - Change IoX discovery process so that it only looks for the IoX on Polisy/eisy - Remove "Running on Polisy" from footer (can only run on Polisy/eisy) - Make node server verification errors more verbose - Add log info for starting udi_interface module install - Add log info for IoX UUID query - Check for updates of PG3. If a new version is available you'll see a notice in the footer - Set autocomplete in login screen for username and password - Fix the re-install process from the Purchases page. It now shows the available install options and makes you choose instead of guessing - Move account management to System menu (use to be Settings -> Profile) - Move backup/restore option from Settings menu to System menu and remove Settings menu - nodeExists shouldn't fail if it can't get node status - Fix store name / module name conflict - Fix updateStores() to work if network is down - Don't update node name to 'undefined' during initial node verification Changelog for 3.1.15 - Ignore multiple clicks of start/restart button - [internal] Change checkDrivers to nodeExits - Allow addnode to rename a node. - Update the purchase option ID if missing. - Update PG3 database with node names from ISY. - [internal] Clean up error reporting in getNode. - Add text to typed parameters delete buttons. - [internal] Include name in renamenode results. - [developer] Fix submit for new node servers - Clean up log messages - Rework store change / version change detection code - Trap error when clearing notices (node server auto update bug) Changelog for 3.1.14 - Remove "Reboot ISY" option from menus. It doesn't work and isn't needed here. - Add some color to the footer badges. Makes it more obvious when things are connected/disconnected - Use isy enable field for connection status. Display the connection status to the current ISY in the footer. - Purchased list improvements: show store(s) that node server is available in, better detect which option user has license for. - Trap error if IoP service is not running and report error. PG3 requires that IoP be running and using the default port of 8080. If it is unable to detect the IoP, it will fail to run. Changelog for 3.1.13 - Add a (re)install button to the purchased node server listing so you don't have navigate back to the store to install - Force the use of SSL for node server to PG3 communication - Convert error messages to info/debug when inserting new node servers to store - Remove version column from node server lists. Now that we support having multiple versions available a single version makes no sense - 3.1.12 broke the notification of new node server versions available, it is now fixed. Changelog for 3.1.12 - Node server configuration error message improvements - Don't overwrite custom parameters when re-installing a node server. - Remove 'Software Management' section from settings, it wasn't being used. - Clear notices when a node server is updated. - Unicode characters in date/time string would cause backup and log downloads to fail. - Get Polisy ID from IoP instead of using current network adapter mac address. Support Thread:

Thanks for letting me know about the poll interval. I wasn't expecting that to be reset so I'll look into it.

You can, but at this point, there isn't any difference between the two. Future updates (if any) will only be available on the production version. If you attempt to install the production version, it should give you the option to re-install in the same that has the beta version installed. This will update your installation to point at the production store entry. I don't believe it will effect anything else.

If the version shown on the dashboard/details for the node server matches the version shown in the store listing, you can delete the update notice and it should go away.

This has not been resolved yet. I'm working on it but I've been unable to reproduce the issues on my end.

I don't have this node server installed and don't have any Sonos devices, so I may be completely off base here. Typically the commands a node server can send to a device are predefined. To use them in a program you go into the program interface and select 'Control' for the 'then' part of the program and select the specific node server as the device. It should then have a drop down list of the commands you can send to the device. Following the links to the node server documentation https://github.com/simplextech/pg3_docs/tree/main/ST-Sonos says it supports all the functionality of the API which lists the following: The actions supported as of today: play pause playpause (toggles playing state) volume (parameter is absolute or relative volume. Prefix +/- indicates relative volume) groupVolume (parameter is absolute or relative volume. Prefix +/- indicates relative volume) mute / unmute groupMute / groupUnmute togglemute (toggles mute state) trackseek (parameter is queue index) timeseek (parameter is in seconds, 60 for 1:00, 120 for 2:00 etc) next previous state (will return a json-representation of the current state of player) favorite favorites (with optional "detailed" parameter) playlist lockvolumes / unlockvolumes (experimental, will enforce the volume that was selected when locking!) repeat (on(=all)/one/off(=none)/toggle) shuffle (on/off/toggle) crossfade (on/off/toggle) pauseall (with optional timeout in minutes) resumeall (will resume the ones that was pause on the pauseall call. Useful for doorbell, phone calls, etc. Optional timeout) say sayall saypreset queue clearqueue sleep (values in seconds) linein (only analog linein, not PLAYBAR yet) clip (announce custom mp3 clip) clipall clippreset join / leave (Grouping actions) sub (on/off/gain/crossover/polarity) See SUB section for more info nightmode (on/off/toggle, PLAYBAR only) speechenhancement (on/off/toggle, PLAYBAR only) bass/treble (use -10 thru 10 as value. 0 is neutral) Is there something beyond that you need help with?

The example station ID's are actually my station ID's. There isn't a fixed number of digits for the station id. As they sell more units, the station id assigned are getting larger. Some of the very first units might even have single digit station ID's,.

I'm working on this issue right now. I don't know why, but in some cases, it seem to fail to replace a space (' ') character with a '_' and then fails because the space is considered an invalid character. Same thing will likely happen if you try to download a log file.

Yes, http. https will only work if you configure IoP with a valid SSL certificate obtained from a known certificate authority. The PG3 log file is the best source of debugging info when having trouble like this. If PG3 is unable to communicate with the IoP (or ISY), the log will show it making multiple attempts (TRY 1, TRY 2, TRY 3) and eventually throw an error saying max retries exceeded. It will also show the URL that it is trying to use to connect to the IoP/ISY. If it is connecting the IoP/ISY but being rejected with a 401 error, that means the username/password is incorrect. I've tried to make PG3 behave a bit better when it can't communicate with the IoP/ISY, but it is still not very good about popping up errors and aborting the node server install in this case.

Yes, you should be able to use 192.168.1.255 as the IP address. It is supposed to work with the default IP of 255.255.255.255, but something in the FreeBSD network stack doesn't like that and it fails to send out the broadcast.

If PG2 installed those node servers on the IoP then only that instance of PG2 can delete them. PG3 only knows that something else installed them on the IoP, it can't do anything with them. To remove them from the IoP, you're close with your screen shot. Simply use that same menu to select the node server and you'll have a button called "Delete" that will remove the node server from the IoP. After about 5 minutes, PG3 will see that it was removed and the dashboard should be clear of those node servers. If when you install a node server on PG3 and it does not show up on the IoP, it means that PG3 is unable to communicate with the IoP. Check the ISY configuration in PG3 and make sure the IP address, username, and password are correct for the IoP. If the IP address changed because you have the Polisy getting a dynamic IP address, you'll have problems every time it changes. You can set the IP address field to 127.0.0.1 which will always work for the IoP since both IoP and PG3 are running on the same Polisy. Then it won't matter if the external IP address changes.

IoP and PG3 need to be able to communicate between them. To do this, they each are configured with information about the other. This includes the network address. Based on the description of what happened, I'm guessing that you have the Polisy configured to get a dynamic IP address without a static reservation. What this means is that when you moved the Polisy, and restarted it, it was assigned a different IP address from what it had before. If this happens, everything that was configured using the previous IP address will no longer work. I.E. IoP and PG3 can't communicate with each other because they are using the wrong network address. We're working to make this better and more seamless, but changing the designs is a long term project so it will take a few more releases before we're there.

Unmanaged means that it is/was not installed by that instance of PG3 but it was detected on the ISY/IoP the last time it queried the ISY/IoP. It queries the ISY/IoP every 5 minutes so it take up to 5 minutes for it to go away once removed from the ISY/IoP. However, it is also possible that if it gets an empty list of node servers from the IoP when before it was getting a non-empty list, it may think something is wrong and ignore that empty list. This is because you may be planning to restore the IoP from a backup and it doesn't want to update it's database and lose all the node server's configured if that is the case. Basically, PG3 doesn't know why it is now getting an empty list from the IoP so it does nothing. If this is the case, then as soon as you install a node server on the IoP, the list won't be empty and PG3 will update it's database to correctly reflect what is installed on the IoP.

It looks like there's already a copy of it running on that slot. Probably when you updated and restarted PG3, PG3 wasn't able to stop the node server so now it won't let you start another copy. Either ssh to the polisy and kill the existing rainmachine node server process or reboot the Polisy.