bpwwer

PG3 can be restarted using the shell: sudo service pg3 restart So that assumes you have a way ssh to the Polisy remotely. With the current version of PG3 there isn't any way to restart node servers other than through the PG3 UI.

@TJF1960I'm not able to really debug issues with upgrades. I just make the new PG3 packages available. I know there has been a lot of issues with the upgrade process. Both of my Polisy's hung while trying to update and required manual intervention to get them working. I had to ssh into the Polisy and run 'sudo pkg install -r udi pkg' as reported elsewhere and that seemed to get it unstuck and it then finished the update. There may be a more official fix, but I'm not aware of it at this time.

My Magic home lights got into a state last night where they were controllable from the Magic home app but I was getting failed connection from the node server. It seemed to be something wrong with the lights themselves as I had to power cycle the lights to get them to work from both the cloud and locally. You might want to see if the Govee lights work with the MagicHome app and if so, if they can work both with the cloud and locally. If they can be configured to work locally, then they should work with the node server.

@sjenkinsYou should be able to do re-installs via the node server store, select the node server, select install for the purchase option and then you have the option to re-install to the same slot it is currently installed in. From the purchases page, it tries to guess what you would select in the last step above and will fail a lot of time. 3.1.16 changes the re-install on the purchases page to follow the same steps as the process from the node server store.

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.

No, it's up to the node server developer to determine how it is handled. It varies for a couple of reasons: 1) PG2 forced the node server to manage the connection state, while PG3 handles that internally. So PG2 node servers that were ported without making any changes here will continue to try and manage it themselves and are probably only partially effective at it (like WeatherFlow) 2) The ability to configure PG3 to report the connection status to a specific node/driver was added after a number of node servers had already been ported and not all authors have gone back and updated the node server to take advantage of this. I'm certainly guilty of #2 as I ported a lot of node servers over early. As I make updates, I try to remember to make that change as well.

Are you PG3 3.1.16 or something a little older? Starting with 3.1.16, the re-install from the purchase page and the store should work exactly the same. Prior versions would fail from the purchase page if it didn't know which purchase option you had originally made. When the ability to support multiple versions of a node server was introduced, it made it difficult for PG3 to determine which version had been installed previously. The result is that things like auto-update can't always figure out what version should be used to update. When you do a re-install, you have to manually select which version to install so there's no guesswork on PG3's part. In your case, it looks like the auto update failed because something was modified in the node server directory that cause the deploy method to fail. That's probably a node server issue if it is modifying files that shouldn't be modified.

Some node servers set up a status value that tracks the status of the connection between the node server and PG3. So when the connect is stopped, PG3 should send a update to the ISY/IoP with updated status. But not all. WeatherFlow sets the status as on-line when it starts but doesn't send any updates when it is stopped. It was written before PG3 was updated with the ability to automatically track the connection status.

I don't think deleting and installing will do anything unless it's just configured wrong. Are you sure it's getting data from the Ambient network? They're not known for their reliability. Switching the node server to debug level logging may provide more information than what was in the log you attached earlier.

There are no errors being reported for the Ambient node server in either log. From what is is in the logs, everything appears normal and working correctly.

I used "same slot" because you could have a situation like this: where the node server was installed in more than one slot so you have to pick the correct slot to re-install from (4 or 15 in the example above).

From the admin console: Node Servers -> Configuration -> slot# -> Delete

PG3 queries the ISY/IoX device for the node servers installed on the device. It then compares those with what it has in it's own database of installed node servers. If it doesn't find the node server in it's database, then it assumes something else installed the node server on the ISY/IoX device and marks it as "Unmanaged". The node servers have to be deleted from the ISY/IoP to free up the slots. That can only be done by the same polyglot that installed them or by deleting them manually using the node server menu on the Admin Console. For node servers that were installed by PG3 before you replaced the SSD, you should be able to go through the node server store and re-install them to the same slot.

I just realized what the problem is with auto-upgrades. When PG3 3.1.x was released, it included the ability to support multiple different versions of the same node server in the store. Prior to this, there could only be 1 version of the node server available. This change caused a change in the format that the version information is maintained. While PG3 3.1.x is able to work with node servers installed by prior versions those versions don't have the information available to know which version was installed when comparing against the new node server store format. The version of Airthings that you have installed was 0.0.6 and that used the old style version information. Version 1.0.0 of Airthings uses the new style version information where there could potentially be other versions available too. Because of this difference, PG3 doesn't really know if version 1.0.0 is an upgrade to 0.0.6. I've been working with the new style version info for so long now that I don't have any test cases like this. But now that I understand what is happening I can probably tweak the logic to handle this better. In the mean time, the easy solution is to just re-install the node server to the same slot. That will update the node server on your system to the new style version.

Should be fixed in PG3 3.1.16

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

The error in the log doesn't appear to have anything to do with rain or temperature. It looks like it is trying to update the forecast information for a forecast node that doesn't exist. Either a forecast node didn't get created or the query is returning forecast data for more days that it should.

The node server API in the ISY/IoP has never had the ability to track node server state. Everything that has been done in both PG2 and PG3 has been a bit of hack to try and provide that information, typically for use in programs. First you have to define what it is you want. If you take a high level view, a "node server" is really supposed to be just a bridge between the ISY/IoP and a device. So do you want the status of the bridge or the status of the device? (or more likely both). In an ideal world, the bridge status should be irrelevant as it should never fail, but in the real world that's pretty much never true. The ISY/IoP is basically a rules engine with Insteon and Z-Wave node servers built it. Where's the status for the built in node servers? With all of that, PG3 does track connection status for the node servers and PG3 does have an API that allows node server developers to expose this connection status if they want to. Like @Goose66I believe the right solution would be to add node server status to the ISY/IoP API and have a system variable for each node server that can be used in programs. But the priority to add something like that is very low right now.

It's expecting a response with JSON data and whatever it got back wasn't what it expected. It's calling https://api.weatherlink.com/v1/NoaaExt.json?user=001D0A004ADE&pass=<your password>&apiToken=<your token> So you can enter that URL into a browser and see what it does. My guess would be that one of the parameters is wrong and it's returning an error message instead of the data.

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.

Every application/channel installed on the roku has an app ID. The node server queries the Roku for the list of apps when it first starts. That message means the Roku is reporting it's active application is the one with idea 562859 but that application id is not on the list of applications the node server originally received. I think this is because of a somewhat recent changed in the Roku firmware related to screen savers where it doesn't list them in the application query. I haven't really looked into it.

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.

The on-line status is for the node server to PG3 connection, not the node server to WeatherFlow device connection. WeatherFlow doesn't provide any method to query if it is on-line or not. It simply broadcasts data over your network and it uses a method that doesn't allow for any type of acknowledgement that the data was received by anyone. The seconds since seen is how many seconds have elapsed since the node server has seen a broadcast message from the hub. The hub sends out a couple of different messages at different intervals the main message being the one with the actual weather data in it. The main data message should come every 60 seconds. Rapid wind messages are every 3 seconds (or not depending on the state of the batter charge). And there are a couple of other messages it sends out. Since broadcast message can be lost or temporarily blocked on the network, there's no specific time. The value is going to vary depending on network load, when the hub was started, when the hub starts getting data from the Tempest device, the state of the battery charge. With all that being said, if the time since last seen gets above 2 minutes, chances are pretty good that something is wrong.

When the Polisy reports a uuid of 00:00:00:00:00:01 or something like that, it means that some component of the Polisy didn't start or is missing. You can attempt to run the "Upgrade Packages" option from the admin console another time (or two) to see if it corrects it. The process can take a while (like 20+ minutes) so don't start an upgrade process and then reboot/power cycle the Polisy shortly there after. If you can't get the upgrade process to run or running a twice doesn't fix the issue, you'll have to enter a support ticket at support@universaldevices.com

No, I'll clean up the change and push it to the production store.