bpwwer

Most likely, it's an error in the results sent by Ambient.  You can check that by taking the URL where you redacted the key and cut and pasting that into a browser tab/window.  
If you just generated the key, it may take some time before Ambient actually activates the key and it works.

From the log, the queries the plug-in is making to ambient.net appear to have an invalid API key.  That's the message the Ambient servers are returning when that query is made.
The plug-in can't force Ambient to accept an invalid api key.  Double check that your key is correct and valid.

Ok, I updated my development system and tested the plug-in.  I did have to re-install and then re-pair with the bridge to get it working, but it's working fine now that I've done that.

My fault.  I tried updating the plug-in to use a newer version of the total-connect-client library and apparently the changes in the library are not compatible with the plug-in.   
I've reverted it back so re-installing should fix the issue.

It worked fine, my fears were unfounded.  Version 2.0.5 has been pushed to the store.  This should fix the error.

Done!

@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).