bpwwer

@SHM Ambient's API is not very easy to work with.  They tend to simply add data fields to the query results as by new hardware and don't document it very well.  There's also no versioning.  So stuff just suddenly appears.  There's also no way to know what data fields will be present because they don't provide any type of mapping from a hardware type to data fields.
Given the number of different stations and sensors that are available there are way too many combinations to try and have pre-defined node definitions for each.  So the plug-in looks at the data fields and dynamically creates node definitions to match what's being sent.  There are (again, not well defined) rules they mostly use for naming conventions.  Like the field name will end in 'in' if it is a field for an indoor sensor. 
All this is to say that plug-in is really just making guesses at what it should be creating.
Your station is the first one that has had a field called 'windgustdir'.   Many stations have a field called 'windgustmph' and given that Ambient could start using 'windgustkph'  or 'windgustms' at any time to represent wind gust speed in different units, the plug-in simply looked for a field that started with 'windgust'.    Thus the plug-in thought your station was reporting two windgust speed fields and the AC fails when there are two fields with the same type. 
I've modified the plug-in to recognize 'windgustdir' as a wind direction field and create the appropriate node value for that.  It should work for you now.  The new version is 2.0.12

If they show up in the PG3 interface, first try deleting them there.  That should delete them in PG3 and IoX.  If they're not in the PG3 interface, but just the IoX, then delete them from the admin console.

I didn't know that.  It seems like that's a recent thing as I believe it was working just last month.  I'll update the plug-in shortly.

Version 2.1.3 is in the store now and it should fix the data for the indoor sensor.

No, it doesn't support those buttons.  The list of buttons/commands it accepts will show up in the list when programming.
<cmd id="VOLUME"> <cmd id="SOURCE"> <cmd id="TREBLE"> <cmd id="BASS"> <cmd id="BALANCE"> <cmd id="LOUDNESS"> <cmd id="DND"> <cmd id="PARTY"> <cmd id="MUTE">  

It seemed to be some type of network issue.  At the time it locked up, the node server was also disconnected from PG3. It was able to re-establish the connection to PG3, but the network connection to the Russound was never reported as disconnected so as far as the node server was concerned, it was still connected.

The plug-in is not getting a response from the robot.  Are you sure it's in the charging station and you're able to connect/control from the app?

WIZ048 is a valid zone code
WIC139 is a valid county code
WIZ048/WIC139 is not valid

I accepted the pull request so it should be updated now.  However, I don't own the node server so I can't update the store entry. 

I just publish a new version with a change to do the npm install as part of the node server install.  If you re-install version 1.0.11 it should work now.

Looks like that worked.  I've changed the node server to use that instead.  Version 2.0.2 has been pushed to the store.

Fixed in version 2.0.5

Maybe now fixed in version 3.1.8

That list is really a list of licenses you've obtained for this instance of Polyglot.  For the Notification node server you probably have a license for the free version and a license for the paid version.
Because you have a license for the free version, you could install that version too, but there's probably not any good reason to do that.
This really should be updated to make things more clear to the user, but the priority has been fairly low.

The number of nodes for a Pico varies depending on the Pico model.
For a 3BRL, that's a 3 button with raise/lower and it should have 2 nodes. The main node has the on, off, raise, lower operations associated with it as those are fixed in the Pico design. The second node is for the favorite button and its operation is configurable.
For 2B there is only one node that has the on and off operations associated with it.
In general, the Pico devices have no status, they are control only devices.  The Pico nodes can be used in programs as it can detect the button presses, but there's no "state" saved.  I.E. a pico button can not be on or off.   There's no ability to query a Pico to see what button was last pressed.
The nodes that do have a status, only use that to show how a configurable button is configured in the node, it's not related to any status in the Pico itself.

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".