bpwwer

From the admin console go to the Node Severs menu -> Configure -> slot 1-20 -> [pick a slot with an unmanaged node server]
You'll get a dialog box with a delete button.  Use that.
Do that for all of the unmanaged node servers and after about 5 minutes they should all be gone from the PG3x dashboard.

"Unmanaged" means that PG3x doesn't have those installed and can't control them in any way.  They were installed by a different instance of polyglot.

Version 3.1.6 adds the icon url

The short answers are no but that's not very helpful.
The formatted values are set by the IoX and this is one of the quirks of it.  After installing the node server, you have to restart IoX before it will send out the formatted values that are text based.  It's not something the node server can control, but at least the solution is fairly simple.
For the second question. First, that's a great idea but not currently possible.  The poll values are really PG3(x) configuration values for the node server in that slot.  That's why they're separated out from the other configuration parameters.  So again, the node server doesn't control the poll intervals, PG3(x) does.  Having a polling schedule vs. just the two values is a great idea, but that's something UDI would have to add to PG3(x).

Version 2.1.0 of the PurpleAir plug-in is now in the plug-in store.
This version adds the ability to configure the plug-in to query the sensor directly instead of using the API to query the cloud servers.   
I also optimized the API call to just request the fields being used.

The Myq log won't really help  
When the node server starts, it gets the units from WeatherFlow.  So first thing to try is to simply restart the node server.  If that doesn't change anything, then check your settings on the Weatherflow app and make sure you have the right units selected for windspeed. 
If that looks right attach the log that includes where you restarted.  Or better yet, set the log level to debug, restart the node server, then download the log and attach that.

I'm not sure what's returned in the data request.  It may be that the app is doing something with the data and you'd have to create programs on the ISY to mimic that behavior.

I think I fixed it, try 2.1.6

When the IoX sends a command to PG3x, it does so by sending an http request (as defined in the UDI Node Server REST API docs).  PG3x does require a username/password for authentication.  When PG3x creates the node server entry on the IoX, it provides it with a username and password.   If that gets changed on the IoX, then PG3x fails to authenticate it which is what looks like is happening here.
To fix this try:
From the Admin Console go to the Node Servers -> Configure -> <slot number range for Kasa node server> -> Kasa menu and then click the Delete button. 
This will delete the node server configuration from the IoX
Then re-install the Kasa node server using the PG3x re-install option from the Node Server Store -> Kasa -> Install, midway in the dialog box there should be an option to re-install to the same slot.
The re-install option won't delete any of your existing configuration options and shouldn't impact any existing programs or scenes that use Kasa nodes.  These two steps should refresh the node server configuration on the IoX and allow it to authenticate when sending commands to PG3x.

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.

I can't do anything about #1, that is a limitation of what the IoX will accept for node names.
I can fix #2.  I'll change it so that it looks like:
 

This also changes the drop down so that the options are "Set Shade Position" and "Set Shade Speed" instead of both being just "Set Shade".

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.

It's certainly possible that they've changed something in newer Roomba's that breaks the way the node server attempts to access it.  Everything related to connecting to Roomba's is based on reverse-engineering how they work as there isn't a public API to do this.
Given that it's unable to connect to the Roomba because it is denying the connection attempt, you may need to do something to the Roomba to enable that.  
Ah, yes, the issue has been reported and it looks like the way to get the password is different for the j7+ and that method is not easily integrated into the node server.

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.

That's not really possible.  Node servers and the associated installation are tied to the hardware.  With PG3x, PG3x and the IoX are essentially tied together as one entity. 
If you try to move the configuration from the Polisy to the eisy, it will get very confused because it will still attempt communicate with the IoX on the Polisy, for some things and will be communicating with the IoX on the eisy for others.  In addition, none of the node server will work because the license for the Polisy is invalid for the eisy.
The only way to "migrate" would be to first get all the node server licenses transferred (by contacting UDI and telling them you want to transfer licenses from the Polisy UUID to the eisy UUID).  Then start the eisy (and make sure it's updated), and install and configure each of the node servers.
Any node server's with a free license don't need to be transferred as you can just get a new free license that works with the eisy for those.
 

Using the AC, select Node Servers from the menu then select Configure, then goto the slot range and select the slot that has the node server you want to remove.  You'll get a box with the node server configuration and at the bottom is a "Delete" button.  Click the Delete button and a few minutes later it will disappear from the PG3x dashboard.

If I remember correctly you need to install the development tools for eisy.
One of the python packages that it uses is only available in source form, so when the node server is installed and attempts to install the python package, it tries to build it from source (using a 'c' compiler).  The build fails because the 'c' compiler is not installed on the eisy.
Use the admin console and click the "Install Dev. Packages" button on the configuration tab.  After those are installed, try installing the node server again.

To close out the discussion on NC rain, the latest WeatherFlow release now creates a node for nearcast rain values.
I made this a separate node for a couple of reasons; there is a limit to how many values a node can have and the main tempest node is approaching that limit and also, NC rain data is only available from the server so currently the station has to be configured for REMOTE data and not LOCAL to get NC rain data.  So anyone wanting to use the local data that hub provides won't have access to NC rain data.
And to provide some info on the business aspect of doing this.  It took about 20 hours to add this feature.  The average hourly rate for this type of work (where I live) is $60, so the business cost to add this was $1200.  This means I'd have to get 120 new sales because of this feature just to break even. Sales of the WeatherFlow node server run about 4 per month (or $40).  So it will take about 30 months just to recover the expense of adding this feature.

It should not start on boot/restart of PG3 if it was previously stopped by you.   Once you "stop" a node server, the only way to get it running again is if you specifically "start" it manually.

It's not real clear what you're actually running.
PG2, which runs on a RPi and on a UDI Polisy is no longer supported.  However, it should continue to run.  Most of the PG2 node server are also no longer supported.  There is a WeatherFlow node server for PG2, but it may or may not work. Again, if the node servers continue to work, you're fine for now.
PGC was discontinued and is no longer active, this includes all the node servers for it of which WeatherFlowPGC is one.
PG3 and PG3x are the latest versions of Polyglot.  These will only run on a Polisy or eisy controller from UDI.  So you can't install it on a Raspberry Pi. PG2 node servers are not compatible with PG3(x) and many are no longer free.
The transition from PG2 to PG3(x) has been happening over the past 2+ years.

Yes, I agree, they shouldn't crash.   You can help by reporting the issues to the node server authors.
And there's a good chance that some of them may be my node servers, I know many/most of mine don't handle lose of network connectivity well and it's on my list of things to fix eventually.

Thanks!  I reviewed the log and see the problem, there's a bug in PG3.  I've provided Michel with the steps needed to work around it so you should be good after the remote session.

I don't believe so. But you can install the node server in multiple slots with each using a different gateway.

Ah, I understand.  Don't change anything there.  Polyglot based node servers configure everything on the IoX automatically.
From the Polyglot website, you should now have a dashboard view that includes the Caseta node nodeserver, click the details there and you'll see something like this:

Click the Configuration button and you'll see a field where you can enter the IP address of Caseta Bridge.  Once you enter that and save it, you should get a notice prompting you to press the black button to pair. 
It should pair in a second or two.  Once it pairs it will query the bridge and add nodes to the IoX for each device it finds.
When it's done, you'll have to restart the Admin Console so it can read the new created nodes properly and display the correct fields and status.

So far, all of the reported issues involving missing files on install have happened on PG3.  After migrating to PG3x, the issue no longer happens.
We have been unable to determine the root cause.  So the current recommendation is to migrate to PG3x.

I just submitted version 1.0.8 of the plug-in to the store.  
Go to the Node Server Store and click the Refresh Store button.
Select the Caseta node server
Click "Install" for the trial (I'm assuming you're running the trial)
You should then have the option to re-install to the same slot, click on that and the node server will install the new version and restart the node server.
The button press events for the configurable Pico buttons should now work.