bpwwer

From the log it looked like it was recognizing the license, but it should have an "Install" button instead of a purchase button so maybe not. I would think it would show up under the Purchases screen as well. So before you do anything else, can you do something from a ssh command line? If you can run the following: sqlite3 /var/polyglot/pg3/pg3.db Then, from the sqlite prompt type: select name,nsid from Node Server where name="DysonPureCool"; This should show one line that looks something like: DysonPureCool|c8cca282-ba32-47a7-b56a-abbc8e25904c But the ID string will be different. I need to see that ID string. To exit sqlite, type ".ex" and it will return the normal ssh command prompt

It found your license so that's a good thing. But since it's a new entry in the store and has new purchase options, your PG3 can't figure out which purchase option was used to purchase it initially so can't auto-update it. You should be able to go to the node server server store, select the "Install" for the DysonPureCool node server and you'll have an option to re-install it to the existing slot. That should get you the latest version and then PG3 should now which install option was used for future updates.

Looks like @glarsendeleted it from the store. He also seems to have removed the node server from github.

The log shows authentication failures every time it tries to connect to the ISY. So most likely you need to reset the username and/or password in the ISY menu.

@oneklakes, not PG3 but the UDI portal (https://my.isy.io). Thanks for the log, I'll take a look and let you know what find there.

For some node servers, auto-update and re-install fail on PG3x. The effected node servers are those that use the 'git' method of distribution. With the current version of PG3x, the only way to get them to update is to remove and then install.

The license information comes from the portal so first step would be to check that. Log into the portal and select Connectivity -> node servers from the "More Tools" option. It should list all the node servers you have licenses for. That's information PG3 should be using to determine if the license has expired or not. If that looks correct. Switch the PG3 log to debug level, let it run for 2 or 3 minutes, switch it back to info, download the log and PM it to me.

No, there shouldn't be. It should allow you to rate anything that shows up on your Purchases page. I do see that a number of folks have rated multiple node servers.

Logging for node servers is done using a Python logging library. I don't believe it had support for compressing the old logs back when first used. I've changed it now to only keep 14 days, but this type of change will only really effect new node server installations, not existing one. I'm looking into compression to see if that's been added to the library.

I wrong about the logging. The node server logging for PG3 node servers was copied from PG2 and has been configured to rotate daily and, I believe, keep 30 days of old logs. It's been like this for about 3 years (I.E. before PG3 existed). It doesn't compress the logs. As @Geddysays, there's no good reason to leave the level set to debug as some node servers can be very chatty when set to that. Having a 10G quota on the PG3 directory seems like a new(ish) thing too.

No log data is stored in any database. However, it does keep a fair amount of log info and debug logs can get quite large. Most of the log data should already be compressed and I believe cleared once it's older than 2 weeks. Also, even if the Kasa log exceeded some limit, it shouldn't be effecting PG3x's ability to start and run. I'd need more information on what PG3x is doing, how you're determining that it's log file related, etc.

Yes, there are bugs related to auto-updating node servers on PG3x. They'll be fixed in the next update.

I know @Jimbo.Automateswas sort of joking when he said get a new router, but really, a wireless router has one main job and that's to route wireless network traffic. If it stops doing that after a few days, it's broken. The node server probably should be able to handle a router reboot. But I have a number of devices on my network that need to be restarted after a network disruption. It would drive me nuts if I had to restart them all every 4 days.

The log shows that PG3 is crashing shortly after starting which is what I suspected from your initial post. It's crashing with a host unreachable error, but the host looks like a IP v6 address so it's not clear what host it is trying to connect to. error: uncaughtException: connect EHOSTUNREACH 2606:50c0:8000::154:443 Based on where it crashed, I'm guessing it was either trying to check for updates to the node servers or trying to check the licenses. Prior to this it was able to connect to the node server store without any issues so it isn't a general connectivity problem. I haven't seen this particular issue so I'm not sure if it's because of IPv6 or something else. If you can, switch the log level to debug before it disconnects and then download the log after it re-connects. I think that would tell me if it was the license check or not.

Maybe. The i994 UUID was the same as the ethernet port mac address. But with the Polisy having 3 network interfaces (and the pro having wifi too) which mac address is used as the UUID? The eisy has 2 mac address so same thing. I don't know how it determines which mac address (and I'm assuming it still uses one of them) is the UUID. PG3(x) simply queries the running IoX instance to get the UUID. It's possible that how the UUID is determined has changed over time too, I just don't know. But that could explain why there's a phantom UUID in the database.

Most likely the Polisy IoX was already in the database with 5.4.5 firmware and then when you upgraded it got added again with the updated firmware. I'm about ready to remove the auto-detect option as there's almost no reason to ever use it.

Yes, running the package upgrade will upgrade everything to the latest versions. This is what UDI has recommended, but I understand your hesitation. It is possible to limit what gets updated using the command line tools but this may cause other issues either now or with later upgrades which is why it isn't recommended. sudo pkg update sudo pkg install pg3 However, installing the latest PG3 may also pull in other dependencies which may or may not work with the existing versions of packages on your system. You may be better off sticking with the version of PG3 that you have until you're ready to do the full upgrade.

Hello Everyone, This is the support thread for PG3 v3.1.18

Hello all, We are very happy to introduce PG3 v3.1.19 with bug fixes and new features, see changelog below. To upgrade PG3: In the Admin Console, click on Configuration, Upgrade Packages (note, this can take many minutes, depending on how long it's been since you last updated.). After the upgrade is complete you will need to restart PG3. From PG3 select System-> Restart Polyglot 3. Once PG3 has restarted, reload /refresh the browser page. Changelog for 3.1.19 - Force python udi_interface update to get version that fixes missing version on node server. Changelog for 3.1.18 - Add a rating system for node servers. Users may rate node servers they have purchased from the Purchases page. - Display node server average rating on node server Info page. - Remove "Log Out Of Portal" buttons. Too many things won't work if logged out of the portal. - Add a button to the node server info page that links to the node server software license. - Don't assume that output on stderr means the node server has crashed. - Add support for developers to add/edit devd configuration information for node servers - Update oauth2 via cloudlink support. - Verification of the node server user config on IoX was wrong resulting in excess node server configuration updates. - Developers can now specify which controllers a node server works on (Polisy and/or eisy). By default, it's both. - Add local store backup/restore feature fro node server developers. Support Thread:

3.1.17 is the latest production version of PG3 for Polisy. 3.1.18 is in pre-release testing.

What happens if you right click on the ST-Inventory node in the AC and select query? Does it populate the values then? When I re-installed and start it, I saw the same thing you did, just the total nodes, node server nodes and error log entries populated. As I tried to debug, I noticed that everything was working but it wasn't sending the other values to IoX which is actually correct for the way it was written. It should only send values that have changed and none of the values were changing so they were never sent. A query forces it to send all values. So I'm not sure if this is a bug or not. It seems to be working as designed, but I'm not sure the design is correct. A better design might be to always send the values even if they haven't changed.

Yes, that changed happened almost a year ago and according to the logs, before the 1.0.0 release of the node server. Prior to that change, there wasn't any code to update the online status so as far as I can tell, that value would never change.

Looks like the event viewer reports the UOM in hex not decimal so 11 would be temperature which makes sense, that's how the node ST value is defined. The moisture sensor status is defined as the moisture level. Everything in the node server looks correct to me, I don't know what you want to me to "fix".

It looks like programs are trying to convert the boolean value of the status for those nodes into something else. 11 is deadbolt status and 16 is european macroseismic (whatever that is). The conversion is failing (which makes sense) Check the programs with IDs 0251 and 0245

We implemented the testing phase after all of the recent problems with upgrades, but this was after I had added the upgrade check in PG3(x) so it's detecting the upgraded version in testing now.