bpwwer

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.

From your screen shot above, you need to change the ISY port to 8080 for IoP. That's probably why PG2 can't communicate with the IoP. The message is reporting the typical cause for connection failures, it's not really reporting the actual error. Node servers are managed by a specific instance of Polyglot. Thus, node servers installed by PG2 are not manageable by PG3 nor vice versa.

It doesn't need to be escaped, it needs to be removed. The quote (") is not a valid character for a node name.

Something got installed that shouldn't be I think. One of the Crypto libraries for Python doesn't work with FreeBSD and it's one that the recent version of the Python Vue library requires. You're seeing those errors because it's trying to load that library that doesn't work. I worked around it by creating a copy of the Python Vue library and removing the code that made use of that library. It doesn't effect the operation of the node server but is pretty fragile as if anything installs that library, it breaks. Once a Python library is installed by the polyglot user, it is nearly impossible to remove. Only PG3 or node servers have the right permissions/configuration to manipulate the libraries. It's not something that can be done manually done (at least I don't know how). I believe the problem is specifically the backends for the python-jose package. The Vue node server specifically limits this to one backend (cryptography), but it looks like you now have other backends installed. I think it's the pycrypto_backend that is causing the issue. You'll probably have to submit a ticket and let the FreeBSD experts see if there's a way to remove the package.

1.0.3 is the latest version. You can always compare the version listed in the store with the version you are running. If they are the same, you can delete the notification.

The node server is already running. If you try to start a second copy, it fails because only one node server can be running in a slot. Since node servers are independent processes on the OS, under rare conditions they will continue to run when PG3 attempts to stop them. When that happens, PG3 gets confuses because it doesn't know the node server is still running and lets you try and start it again, which then fails. Possibly, restarting PG3 will clear. If not, then the only way is to either manually kill it via the console or restart Polisy

yes, that should work. But you'll have to manually remove them from the ISY slots because PG2 isn't managing them at this point, it can't remove them. Once you delete them from the ISY (node servers -> configuration -> slot1, click delete), PG2 should show the slots as free in roughly 5 minutes, then you can reinstall.

When something shows up as unmanaged, that means that the node server is installed on the ISY/IoP but the version of Polyglot that you are running does not see that node in it's database so it assumes some other version of Polyglot is managing it. PG2 has no way to fix the database when this happens other than by restoring from a backup.

Currently, the Portal manages the licensing of node servers. So PG3 needs to contact the Portal to verify you have a valid license to install and to run a node server. To do that, it needs valid Portal credentials. I don't know if that means you need an active subscription or not. I'm not involved with any of the Portal administration or development so I don't really know what happens if you end the subscription. I don't believe an expired subscription prevents you from accessing your Portal account which would imply that you don't need a subscription to buy, install, or run node servers. You just need the account.

While one of the goals with PG3 was to minimize the need for Portal access, it has become increasing difficult with the requirements for both network security and to protect node server developer's work. Node server purchases and licensing are managed by the Portal. Node server licenses are tied to the Polisy hardware ID and to the Portal user's account. To get a node server from the store, you need a Portal account. That restriction comes from the licensing scheme that exist in the Portal. PG3 does include the ability to have node servers installed without access to the external store/license. This is currently used by node server developers to develop and test their node server before adding them to the store. Thus it should be possible to package up a node server in such a way that it is added to the local store where it can be installed without a license and run without access to the store or the Portal but no node server developer has attempted to do this.

PID not found is referring to your Polisy ID. The Polisy does need to be registered with the Portal before it can create a node server license for it. My understanding was that it would register it automatically the first time you tried to purchase something but I don't have access to the portal administration so I'm not sure. You may be able to log into your portal account and register your Polisy yourself. The Polisy ID is the actually the MAC address of the network adapter so changing which network interface your using on the Polisy can cause issues. I.E. if you switch from using a wired connection to wireless. If none of this helps or makes sense you'll have to open a ticket to get someone at UDI to investigate what's going on with the Portal.

There should be no difference assuming it works from PG3. I don't think I've ever tried it. That function was there when I took over development of PG3 and I've never looked at it.

There are plans to consolidate some of logins but currently PG3 needs both your portal credentials and your PG3 credentials. The portal credentials are used to determine if the user is a developer and developers get some PG3 features to add and edit their node servers in the node server store. It also needs your portal credentials to access the node server licensing info.