bpwwer

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.

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