bpwwer

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 just pushed out version 1.0.3 of this node server. I think I managed to work around the problem with the library.

If the version numbers match and it's saying it needs to be restarted, just re-loading the browser should fix it. Apparently 3.0.62 does not equal 3.0.62 sometimes. I suspect that the old version is cached somewhere and that's why it does that, but it should be comparing the same values it's displaying.

No, there's nothing wrong with the node server, one of the python libraries it depends on won't install on a Polisy. I'll see if something can be done to get the library supported on the Polisy.

Whatever information it is getting back from WeatherFlow when it queries for information on the station id is not valid. I took a look at what WeatherFlow was returning and it has 3 incomplete records and 1 correct record for your HUB device. The nod server is failing when it encounters the first incomplete record. Version 3.0.20 of WeatherFlow node server should now skip those incomplete records.

Unfortunately that log doesn't have anything that would indicate what happened. I'd need to see the log where the node server was installed or at least when it was restarted. Have you tried restarting the node server?

send me a log package from the node server logs page and I'll take a look.

You might want to look at the log to see what's wrong. My guess would be an incorrect API code or incorrect station id.

Almost all of the weather services have a free subscription plan. That allows you to at least use the services web site to see what data it is providing and how accurate it is for your location. I tried to make most of the weather service node servers as similar as possible so there really isn't much difference there. It really comes down to finding one that has the data you want and that best serves for your location.

Node server purchases are tied to PG3 not to the ISY. When the ISY is not IoP running on the same Polisy, the UUID's will be different.

Unmanaged means that that instance of polyglot (pg3 or pg2 whichever says they are unmanaged) does not own the node server installation and thus, can't do anything with those node servers. Both versions periodically check the ISY to see what node servers have been installed. I believe this happens about every 5 minutes. This means that deleting a node server from one instance of Polyglot, won't instantly update other instances of Polyglot, it can take up to 5 minutes before the deletion is seen by the other instance.

I'm not sure how it happened, but you have a really old version of PG3 (3.0.43) which no longer works. the most recent version is 3.0.61. see the instructions to upgrade in the PG3 release announcement section of the forum.

Then if you delete the PG2 node server, it will delete the nodes from the ISY and when the PG3 version is installed, it will create the nodes with the default zone names. If you don't delete the PG2 version (but simply stop it). The nodes will remain unchanged in the ISY and the PG3 version should inherit them. This assumes that the PG2 and PG3 versions use the same node address. Also, PG2 will restart all it's node servers if it is restarted so there's no good way to permanently disable a node server on PG2, other than by deleting it. Neither PG2 nor PG3 (yet) were designed to allow for migrations like this. Unfortunately there's nothing we can really do about PG2 at this time so there are no good solutions.

If the zone names are set via the custom parameters then they should carry over. That assumes that the PG3 version uses the same custom parameters as the PG2 version. Also note that the restore from PG2 backup is not selective, it tries to restore all the node servers from PG2, you can't just pick one and say restore this one only.

From the log, the Hue node server installed correctly. It seems to be the node server itself that exits abnormally after starting. We'd need to see the node server log which should indicate why.

Thanks for being so detailed in describing the problems. Typically, when a node server stops and shows disconnected immediately after trying to start it, it means that the node server crashed for some reason. Info on that will show up in the node server log. If there is no node server log, then it was never able to start and those errors will show up in the PG3 log. Both the Hue and Sonos node servers are free node servers. Thus, you haven't actually purchased any yet so that's why you're seeing the error since it really did fail to get any info on purchased node servers. That message should be improved to be a bit more helpful in the next release. With PG3, you can install the same node server multiple times into different slots so even after installing it, you can still install it again. Once you install a node server, the column labeled "Installed" should show the slot number(s) that it is currently install in. We'll need to know what's in the log files to determine what isn't working.

The PG2 version is probably just ignoring the bad response.

I thought I was outputting the results of the query in debug mode, but I guess not. AmbientWeather is not known for their reliability so I still suspect it either returned an error or a corrupted response to the query. There's not really anything else the node server could do. It recognizes that the response isn't valid and continues on, the next query response is fine and the data is updated.

The restore from PG2 option was written for PG3 before I took over PG3 development and as @apostolakislsaid above, it's not an elegant solution. It does sort of work, depending on what node servers are being backed up and restored, but in general, I'd not recommend using it. The process basically goes through the node servers listed in the backup and attempts to find one in store with the same name and install it. It will also try to port the configuration over. It basically overwrites the node server configuration in the ISY for those node servers it successfully installs leaving the PG2 version orphaned. As far as PG2 is concerned, nothing changed. It still thinks it has the node server installed and that it is working. Since PG2 (and PG3) are designed to remove the node server from ISY when it's deleted, doing so on PG2 will very likely remove it from ISY, leaving PG3's version now in limbo. The only real solution is to stop the PG2 version and either never restart it or simply stop PG2 entirely. If you're trying to migrate slowly and or still need PG2 running, it is much better to manually migrate the node servers you can to PG3 by first documenting the config, deleting the PG2 version, installing PG3 and updating the config.

Make sure you add a value to the custom parameters that evaluates to true. Something like key - change_on_pon, value = '1' If you leave the value blank, that evaluates to false and means you don't want that feature enabled.

The connection to the Roomba is handled in a separate thread by the roomba library code developed as part of the Roomba980-Python project. That code waits for updates from the Roomba and stores them. The node server polls that stored data at the poll interval. Thus the node server can look like it is updating frequently when in reality, it is just getting whatever stale data was last received from the Roomba. Also note that if the data is not changing, the node server won't pass it on to the ISY. It only sends data that has actually changed to the ISY.

You can also check the PG3 log as it will show everything being sent to the ISY. If the connection was lost for some reason you should see errors in the PG3 for each attempt to contact the ISY.

I'm not sure what you're looking at but already does New Pr

Maybe set logging to debug to see what's causing the error. It sounds like the server is not sending valid data.

I screwed up the status for the different nodes. It should be fixed in version 1.0.2 so that the Today/Tomorrow nodes show True/False and the main node shows connected/disconnected/failed.