bpwwer

1.0.3 is the latest version. You can always compare the version listed in the store with the version you are running. If they are the same, you can delete the notification.

The node server is already running. If you try to start a second copy, it fails because only one node server can be running in a slot. Since node servers are independent processes on the OS, under rare conditions they will continue to run when PG3 attempts to stop them. When that happens, PG3 gets confuses because it doesn't know the node server is still running and lets you try and start it again, which then fails. Possibly, restarting PG3 will clear. If not, then the only way is to either manually kill it via the console or restart Polisy

yes, that should work. But you'll have to manually remove them from the ISY slots because PG2 isn't managing them at this point, it can't remove them. Once you delete them from the ISY (node servers -> configuration -> slot1, click delete), PG2 should show the slots as free in roughly 5 minutes, then you can reinstall.

When something shows up as unmanaged, that means that the node server is installed on the ISY/IoP but the version of Polyglot that you are running does not see that node in it's database so it assumes some other version of Polyglot is managing it. PG2 has no way to fix the database when this happens other than by restoring from a backup.

Currently, the Portal manages the licensing of node servers. So PG3 needs to contact the Portal to verify you have a valid license to install and to run a node server. To do that, it needs valid Portal credentials. I don't know if that means you need an active subscription or not. I'm not involved with any of the Portal administration or development so I don't really know what happens if you end the subscription. I don't believe an expired subscription prevents you from accessing your Portal account which would imply that you don't need a subscription to buy, install, or run node servers. You just need the account.

While one of the goals with PG3 was to minimize the need for Portal access, it has become increasing difficult with the requirements for both network security and to protect node server developer's work. Node server purchases and licensing are managed by the Portal. Node server licenses are tied to the Polisy hardware ID and to the Portal user's account. To get a node server from the store, you need a Portal account. That restriction comes from the licensing scheme that exist in the Portal. PG3 does include the ability to have node servers installed without access to the external store/license. This is currently used by node server developers to develop and test their node server before adding them to the store. Thus it should be possible to package up a node server in such a way that it is added to the local store where it can be installed without a license and run without access to the store or the Portal but no node server developer has attempted to do this.

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.

There should be no difference assuming it works from PG3. I don't think I've ever tried it. That function was there when I took over development of PG3 and I've never looked at it.

There are plans to consolidate some of logins but currently PG3 needs both your portal credentials and your PG3 credentials. The portal credentials are used to determine if the user is a developer and developers get some PG3 features to add and edit their node servers in the node server store. It also needs your portal credentials to access the node server licensing info.

The purchasing process is a multi-step process. When you click on "Purchase", PG3 redirects you to a UDI purchasing portal. From the purchasing portal you make a purchase (or cancel). Once that is done the purchasing portal then redirects back to PG3. When PG3 sees that you have a valid license for the node server it will display an "Install" button instead of the "Purchase" button and that is used to install the node server. To activate a Trial it uses a similar process except that it doesn't redirect to an interactive purchase portal and instead just requests a free trial license. When PG3 sees that you have a valid trial license it will change the "Activate" button to "Install". Since you say nothing happens, I'm guessing you mean the purchasing portal is never displayed? If that's the case, it is something on your end that is blocking that. Either your browser or your firewall.

By real-time info on the dashboard do you mean the nodes tab is showing the actual real-time device data? If so, the node servers are working correctly. Do you have any other node servers running? The PG3 log file will likely provide some information on what is going on. If you just have the two node servers and the node server are reporting data to PG3 but PG3 is not reporting the data to IoP then it is likely because the IoP configuration under ISYs -> edit current ISY is wrong. Either the IP address, port or password is incorrect.

To be clear, it's not the PG3 update that is having issues, it's the overall Polyisy update that was (is) having issues. I thought the process was fixed, but I don't have confirmation on that.

I think it complaining that wind direction can't be compared with -1° so it does nothing.

Maybe a program is trying to compare winddir with something it can't convert wind direction into.

@tlightneTake care and I hope you make it through without any damage. Keep safe.

No, it's not right. When a node server starts it should send the current values to the ISY. However, this is up to the node server so all of them may not do this. Node server startup can also take a while depending on how many nodes it creates and how many values are associated with each node. Depending on the node server, the start up time could be anywhere between a couple of seconds to minutes.

@Michel Kohanimthe expert on what the messages mean. So when the error log is showing lots of those messages, what does it mean? @johnnytin your case, we're more concerned about the queue full messages so if you're not seeing those yet, keep starting node servers.

I believe -170001 messages are related to the queue being full. That was the connection I made between all these cases. Issues with z-wave devices not updating, Insteon devices not updating, PG3 node server devices not updating, programs not triggering could all be caused by the same root cause, something hung and the new tasks not being pull from the queue and thus the queue filling up.

For some things, the pkg update commands can still be used, but the admin console update packages is doing some additional stuff to make sure everything is right and dependencies are correct (don't ask me what, I don't know).

Yes, this is a known issue. For a period of time, the update wasn't updating one of the dependencies (that library it complains about). It should be fixed now if you do another update. The recommended way to update is to use the "Update Packages" button in the Admin Console configuration screen.

This appears to be related to

@tlightneYour ISY log is filled with -170001 errors. That seems to correspond to the internal queue being full. That would make sense if something was blocked/stuck and could cause all the symptoms described. Unfortunately, almost anything could cause this. PG3 does do a lot of communication with the ISY/IoP when it starts. So it is possible that something it sends, or even the amount that it is sending, on startup triggers something to block. One test would be to disable (stop) all of the node servers and then reboot. PG3 will remember the last state of the node servers so it should start with all node servers disconnected (not running). Then slowly start them manually one by one giving it a minute or two to stabilize between each. If it works, that tells us something. If it starts showing the same symptoms after one specific node server is started, that tells us something. I suspect that your PG3 log is just too large to attach here. The log is reset a midnight each day so the earlier in the day you are able to do any testing, the shorter the log will be and you'll have a better chance of it attaching here. If you still have problems, you can PM me and I'll send you my email address and we can see if email can handle the size.

Yes, using 127.0.0.1 (the local address) should be a bit quicker, but probably not something you'd notice.

There are communications both ways between the IoP and PG3. When a node server is installed in a slot on the IoP, part of that configuration is the ip address of PG3 so the IoP can query the node server and send commands to the node server. Since PG3 is designed to support multiple ISY/IoP's it can't assume that the ISY/IoP is on the same host as PG3 so it uses the real IP address for that. Thus if the IP address of PG3 changes after the node servers are installed, that communication channel is broken. The node server will still be able to send updates to the ISY/IoP so it may not be obvious.

It doesn't look like they're measuring the same things. If I enter 20158 in AirNow and check the box for PM2.5 most of those near that area disappear the ones that are left drop in value to below 10. It looks like the sensors you're looking at in AirNow are measuring Ozone. I don't believe the Purple Air monitors can measure Ozone, they are just PM2.5 and PM1.0 monitors. PM2.5 and PM1.0 refer to the size of the particles that the monitor can detect. Even two monitors next to each other in the same physical location will not match exactly. There are a lot of variables that go into calculating a AQI value and most inexpensive (like Purple Air) sensors are not very accurate. Not compared to sensors that cost 10-100x. The Purple Air monitors can give you a good representation of the air quality within a very small radius of the sensor (probably a couple of hundred yards) for the pollutants it can detect. You might want to read through this: https://www2.purpleair.com/community/faq#hc-how-do-purpleair-sensors-compare-to-regulatory-particulate-matter-sensors