bpwwer

Try logging out and then see if you can log back in.

I finally got around to trying it myself.  The problem is the node server is requiring a very old version of the interface module and that old module doesn't support PG3x MQTT.
@Javiin the requirements.txt you have udi_interface == 3.0.32.  Version 3.0.32 is a very old version of the file. The latest is 3.0.51.  You should probably use udi_interface => 3.0.51 and update the store entry version.
@garybixlerOnce the node server is updated to use the latest udi_interface, you'll need to do a re-install (note, not delete and install) for it to pick up the change.

No, it can't.  The admin console has full control over how the content is rendered. The node server (via PG3(x)) simply sends the value (numeric value).  
The only control the node server has is over values that are represented with text.  The node server creates the numeric value to text mapping that the admin console uses.
 

The node server is probably already running, just not connected to PG3.  
ps auxww | grep weatherstation.py  and see if it shows up in the list.  If so, then it needs to be killed before you can start it from PG3.   

No, beyond just that increasing the log level results in more log info.
If set to Critical, you'll probably see nothing, ever.  I'm not sure if there are any messages at that level.  If there are, it is very few.
error and warning are just as they say.  Error messages and/or warning messages only are output to the log.
info are messages that report what PG3 is doing.  This is the default and generally provides enough information to figure out what PG3 is doing at any given time.  
debug provides even more detail on what is happening.  It tends to be used for things that might be nice to see when debugging but generate so much log output that it can make the log harder to read.
db operations adds all the reads/writes to the PG3 database into the log.  This generates a huge amount of log info and is only going to be useful when trying to track what is being read or written from/to the database.
In general, there's no real reason to change from the default unless you're working with support and they request that you do so.

The error message means there's a browser running the UI that is not longer authorized to connect to PG3, but continues to try.
The connection between the UI running on the browser and PG3 is only good for about a week and and then it expires.  When it expires you need to log out and log back in to the UI (and maybe reload the page in the browser). 
I see this a lot because I'll sometimes have multiple tabs open to PG3 and forget about one.  That one will expire (or I'll restart PG3) and the forgotten tab will keep trying to communicate with PG3 and get rejected with that error.

Your current installation of Kasa is too old to support automatic updates.  The information needed for PG3 to determine what you purchased didn't exist when you did the initial install of Kasa.
You need to either upgrade PG3 to 3.1.16 which will then allow you to re-install from the purchase page or go through the node server store and re-install the node server that way.
In either case, you'll need to select the proper install option and re-install.  A re-install will keep all your current configuration and nodes so you won't lose anything by re-installing.

Yes, I'm the author but UDI handles all the payment and licensing.  You'll have to open a support ticket.  

Yes, the hub will broadcast messages even if the Tempest battery dies.  It just won't broadcast the Tempest data.
The hub has a fixed schedule that it broadcast data on and the node server is doing reporting on a fixed schedule so unless something changes (I.E. restarting the hub) the value shouldn't vary. 

It's clear but it's not the node server doing the grouping that way, it's Volumio.  The node server does a browse at the top level and creates the entries based on the order it see sources in that browse.
Given that what is available in the list of sources will vary for each Volumio device and the order may even depend on the order sources where added to Volumio, that's a fairly complicated ask.

The cause seems to be that "api.emporiaenergy.com" isn't being resolved. 
It could be a temporary thing where their servers when off-line for a while or it could be something regional/provider related where they aren't able to contact root DNS servers.   Or it could be a local issue (I.E. your internet connection was down).
I'm able to resolve the name here and I'm able to access the server. 
You can try with a browser using https://api.emporiaenergy.com and it should respond with an authentication error.
The main error is "<urllib3.connection.HTTPSConnection object at 0x8052eb820>: Failed to establish a new connection: [Errno 8] Name does not resolve"
It does make multiple attempts and then reports that max re-tries exceeded.
Then the node server throws a bunch of errors because it didn't get any data from the servers.

I think I see the problem.  This is the first "roku" device it finds: http://192.168.1.134:40000 which doesn't look like a roku device at all.  So something else is responding to the roku discovery broadcast.
I just uploaded a new beta that may resolve the issue.  All it really needs to do is skip this non-roku device and continue and it should find the real roku devices.

The (re)install button is a brand new feature of 3.1.13 and it appears that there are some bugs that still need to be worked out.  Please go to the Node Server Store and select the iAquaLink node server.  In the detail purchase page, it should show an install button there and that button should allow you to install using your existing license.
However, before you do that, please verify that PG3 is really able to communicate with the ISY.   If it is, then you've tripped one of PG3's features that tries to prevent accidental node server removal.
If PG3 has node servers listed in it's database for an ISY, and it queries the ISY and gets back that no node servers are installed, it doesn't really know if there are no node servers as maybe you reset the ISY and are restoring it from backup. So it basically does nothing.  As soon as you add a node server to the ISY, PG3 will then realize that the list coming from the ISY is valid and will clean up any slots in it's database that don't match what's on the ISY.

PID not found is referring to your Polisy ID.  The Polisy does need to be registered with the Portal before it can create a node server license for it. 
My understanding was that it would register it automatically the first time you tried to purchase something but I don't have access to the portal administration so I'm not sure.  You may be able to log into your portal account and register your Polisy yourself.
The Polisy ID is the actually the MAC address of the network adapter so changing which network interface your using on the Polisy can cause issues.  I.E. if you switch from using a wired connection to wireless.
If none of this helps or makes sense you'll have to open a ticket to get someone at UDI to investigate what's going on with the Portal. 

It's not the node server it's the ISY/IoP that won't accept the precision.  The node server is converting units and the conversion results in more decimal places than the ISY/IoP can handle.
Fixed in version 3.0.26

There was a support ticket with the same issue (uuid = 00:00:00:00:00:01). In that case a reboot of the Polisy resolved the issue.
I suggest you try that first.  If that doesn't resolve the issue, then file a support ticket as something may be preventing the Polisy from fully initializing on startup.

I made the change to comment out the pushover import since I do have access to the repository.  A re-install should get a working version now.

I don't see any errors from PG3, just warnings.
I've mentioned this before, PG3 makes 3 attempts to send the information to the ISY.  Above shows that the first attempt failed, but the second attempt succeeded so that's not an error.

It's on my list to add RIO support to the PG3 version, just need to find the time.

Unless it's a Roku TV, no.  the node server only controls Roku devices.

Yup, that helps.  
I just uploaded version 2.0.1 of the Roku node server to the store.   Refresh the store and then restart the node server and see if that adds your Master Bedroom Roku.

I updated the link in the store listing so it should work now.

I think you almost had it right.  Try ${sys.node.n001_141766_11.CPW} 
The address created by the node server has the "n<slot>_" pre-pended to it when added to the ISY

I was wrong about the API change. I can't find anything wrong.  However, the free plan limits are now pretty low and you do need to have the short poll, long poll and number of forecast days set to stay below those limits.
If you try to get more than 7 days of forecast data with the free or hobbyist plans, the node server will fail to start as it will be sit there waiting for more data that it will never receive.   This makes things a bit more difficult since the node server doesn't have any way to know what plan you have so it can't auto-adjust the parameters.
I've updated the documentation and configuration help to reflect the latest limits.

A just releases a new version (2.0.7) that should fix the issue.
The problem was that @jkosharek's  station is reporting battery data that I had not seen before and the data parser ended up generating two battery drivers with the same name in the node.  The ISY doesn't like that and the node was not really valid, hence it wasn't able to display it properly in the admin console.