bpwwer

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.

It failed to build one of the dependencies it needs to run. This was while trying to build the pycryptodome 3.3.1 library. cc -pthread -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fPIC -DLTC_NO_ASM -Isrc/ -I/usr/local/include/python3.9 -c src/MD2.c -o build/temp.freebsd-13.1-RELEASE-p5-amd64-cpython-39/src/MD2.o In file included from src/MD2.c:28: src/pycrypto_common.h:47:10: fatal error: 'stdint.h' file not found #include <stdint.h> ^~~~~~~~~~ 1 error generated. error: command '/usr/bin/cc' failed with exit code 1 [end of output] I suspect that a package is missing on your Polisy that would allow this to build. @Michel Kohanimdo you know which package is needed for this and can it be added to the list of packages that must be installed?

There is also the Eagle-200 (Rainforest Gateway) device that can connect to smart meters and there is a node server for it as well. If I recall correctly, this pulls data from the device locally instead of from the cloud.

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.