bpwwer

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.

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.