bpwwer

There is probably an error in one of the profile files that is preventing the AC from fully parsing the node.  Looking at your profile files, I don't see anything wrong.
The best way to double check is to start the admin console with the java console active, any parse errors will be reported there.

You should update to the latest version of PG3 as this issue has been fixed.
The (Re)Install button isn't really correct.  It should be labeled "Update" and you can only update if you already have it installed. 
Instead, go to the Node Server Store, select the node node server from the list and then click the "Install" button to install.

Critical - not used.
Error - something failed that isn't expected to normally fail.
Warning - something that may need to be reviewed.
Info - messages that track execution.
debug - more verbose execution tracking.
db operations - log all database operations.

Have you restarted ST-Inventory?  Or you may just be able to do a query on the node.
I believe what happened is that when you installed Ring, you also had to enable remote access.  When remote access was enabled it restarted the IoX.   When IoX restarts, it doesn't remember any of the node server values.
ST-Inventory will only send the counts to IoX when they change and most of those values rarely change.  It doesn't know that the IoX was restarted and that it needs to send everything again.

No, the current design is based on the fact that the Roomba broadcast the information needed to connect to it. So the node server has to be able to receive that info to function.   This is mostly a function of how the Roomba works, not the node server.

The is what the server is sending in response:
The plan is restricted and cannot perform this action. Adjust action and try again: endTime cannot be more than 5 days ahead.'
It sounds like you're requesting more days of forecast than your plan allows.  Reduce the number of forecast days to 5 or less.

Some node servers don't currently work if the eisy is on wireless. 
To implement the wireless driver on the eisy, it runs a Linux VM with the wireless driver in the VM and sets up the firewall rules to forward TCP traffic between the VM and the eisy's internal network.  Thus, any node server that relies on broadcasts tend to not work as broadcast type packet don't typically get routed.
For example, the WeatherFlow node server won't work in local mode as it will never see the UDP packets being broadcast by the WF hub.

You may have exceeded the number of API calls your plan allows for in a day.  The free plan is quite limited. Or you may have asked for more forecast data than what your plane allows.
It looks like they may have reduced the number of days of forecast data you can get with the free plan from 7 to 6.  The node server gets stuck if it's looking for 7 days but only sees 6.

Yes, you can run multiple copies of any node server.  So in theory, you can run two copies each linked to a different smart bridge.

Currently the only "feature" difference between PG3 and PG3x is that PG3x is getting remote access support.  We can't do remote access for PG3 which is one of the main reasons PG3x was developed.   There are internal changes in PG3x that make the node servers more secure but that's not something that is user visible.
There are no other plans for PG3x specific features other than those that are enabled because of the remote access framework.  An example is that there is a Ring node server that will piggyback on the remote access framework and thus, will only run on PG3x.
As mentioned above, Polisy is capable of running PG3x and there is a migration path available to switch.  We can migrate from PG3 -> PG3x but we don't have an easy way to migrate back so make sure you make backups of everything before attempting to migrate PG3 -> PG3x.

Disconnected means it was unable to connect to the local (or configured) IoX.  There are only a few different reasons it wouldn't be able to connect and viewing the log should reveal which.
1) the ISY software isn't running.  In this case you also would not be able to start the admin console.  The log would show a connection refused error.
2) The IP address is configured wrong. By default it's using the local address 127.0.0.1:8080 which is the local IoX.  If you didn't change the configuration, then this should be correct.  Again, you'll get a connection refused if it trying to connect at the wrong address.
3) The credentials are wrong. It starts with the default of admin/admin, but is supposed to update them if you log into PG3x with something different.  The log will show 401 (authentication) errors in this case.  You can update the credentials manually in PG3x via the ISYs -> Edit current ISY menu.

PG3x version 3.1.23 was extra chatty as we used that to do some initial testing for PG3x remote access.  That has been removed in the latest version 3.1.24 of PG3x.

3.1.18 hasn't been released to production yet so if 3.1.16 is working then no PG3 upgrade is needed at this time.

Looks like there's a bug in the latest PG3x release that's preventing it from removing node servers.

Some older node servers/older versions of node servers can't auto-update because PG3 doesn't have enough information to know what to update.  In those cases, selecting the correct install option / re-install to same slot should update the node server.

You're close.
Yes, you need to add a custom parameter with the "Port" "key" field and then the value will be the port that you configure in Meteobridge API URL.
If you configure the API URL as "http://10.0.0.56:8045", then you'd set "Port" to 8045
Note, that the IP address in the API URL is the Polisy's IP address.
Note2, notice I didn't use port 8080, port 8080 is already in use by the IoX running on the Polisy so you can't use that.  When you configured the API URL with that, Meteobridge was trying to send the data to the IoX which rejected it.
Note3, I believe the key name is case sensitive so "Port", not "port".

unmanaged, means that they are not being managed by PG3 but by something else. That's why you can't delete them.
In your case, I suspect they are being managed by a previous installation of PG3?  or PG2?  
You can delete them from the Admin Console.  Go to Node Servers -> Configure -> slot number for the node server slot you want to delete and click on the "Delete" button.  After a few minutes they should disappear from the PG3 dashboard.

Yes, there are bugs related to auto-updating node servers on PG3x. They'll be fixed in the next update.

Roku node server version 2.0.5 should fix the errors

@palaymanYes  polyglot.universal-devices.com lists all current node servers and clicking on the node server brings up the details including price(s).

I screwed up the packaging.  You'll have to re-install but it should work now.
Go to the node server store, select refresh store.  Then select the node server, click the install button and use the "Reinstall here?" button to re-install.

You're right. Fixed in version 2.0.8

Use the "install dev packages" option in the admin console configuration tab and then try again. 
If you don't have an install dev packages option, you'll need to upgrade packages first.

Looks like Emporia changed the API slightly.
I updated the node server and it should work now.  Version 1.0.23

The data reported by the node server is what the Ambient servers report.  There's no conversion happening in the node server.