bpwwer

First off, my comments and reasons for not wanting to allow for automated restarts of node servers/PG3 are really because that tends to be used as a band-aid to handle poorly behaving node servers.  The right way to do things is to get the node servers to not behave badly.
In this case, the node server isn't really behaving badly, it's behaving mostly as intended.  When it can't communicate with Blue Iris, it goes into a disconnected state and waits for someone to take action to resolve the issue.  Now it could and should handle this better.
It should try to re-connect, the code is mostly there, just not the logic to attempt that.
In cases like this, where the author has pretty much abandoned the node server, I'll typically take a look if I have time.  Unfortunately, I don't always have time to dig into someone else code to figure out how it works and what can be done to resolve any issues.   You happened to ask at a time when I'm not real busy so I'm going to try and make some changes. 
Version 2.0.3 should try to re-connect when it fails to query the Blue Iris server.  I have no way to test this.

Seconds.
And you can't slow down data from the local hub.  The local hub doesn't accept queries, it pushes the data to the plug-in at the interval defined in the hub firmware.

The data is displayed in the units that the service returns.   The plug-in doesn't have the ability to do unit conversions.

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.