bpwwer

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

Why do you expect them to match? I don't know where the Purple Air sensor is located as I couldn't find it on their map, but the sensor reporting for AirNow seems to be located near the freeway and all the Purple Air sensors I could see on the map are located many miles east of that. Air quality is always much worse near freeways. Also, the AirNow reading seems to be based on PM2.5 and Ozone and I believe the Purple Air sensors just look at PM2.5.

The EPA AQI is probably the equivalent but that site says it's the nearcastAQI. I don't know if nearcastAQI and the EPA AQI use the same formula or not. The EPA AQI Category in the node server corresponds the ranges that the EPA lists (good, moderate, bad, etc.). It looks to be about the same as what's shown on the AirNow site. The Purple Air bases most of this off the PM2.5 level. The Purple Air is reporting that at .7ppm while on AirNow it's listing it as 8 (over 10x as high). Based on that I would expect the AQI values to be different.

It looks like you have a copy of the node server running already so it can't start another. Each installation is assigned an ID, that instance with that ID is only allowed to connect to PG3 at a time, all other attempts are rejected. What probably happened was that when you restarted PG3 after upgrading, it wasn't able to stop the currently running node server for some reason. PG3 does ask each node server to stop when it is stopping but sometimes a node server ignores it and keeps running. Uninstalling and reinstalling will assign a new ID to the new installation. You'll still have two copies running but they'll both be able to connect and you'll probably see duplicate messages in the log and both will be trying to update the nodes on the ISY which could lead to confusion. There are 2 ways to force the original to go away. 1) ssh to the Polisy and run some commands to find the process and manually kill it. 2) reboot the Polisy. If you want to attempt #1 I can provide some examples of how to do that.

Just FYI, there isn't any place on the frontend that shows the connected status of the ISY/IoP. The "connected" badge in the footer represents the frontend UI to backend server connection, not the backend server connection to the ISY. Right now the only way to tell if it is communicating properly with the ISY is by checking the log file. Although adding a connected badge for the ISY isn't a bad idea.

Ah, I think I see part of the problem. It looks like you have two ISY's (or an ISY and an IoP) configured but one of them doesn't have a valid username/password set. That's just making the log file a bit harder to read. The ISY with UUID 00:0d:b9:53:2b:bc and IP address 192.168.0.48:8080 doesn't appear to be configured correctly in PG3 so PG3 is unable to communicate with it. This looks like an IoP UUID. Since it doesn't appear to be able to communicate, it's unclear how any node servers would be working with it. The other looks like an ISY 994 but at a non-standard port 1026. However, it does appear to be communicating with PG3 and it looks like it was able to install the 'Hue' node server per the log. As @JimboAutomatessays, trying to use port 8080 for the hue emulator will cause conflicts with IoP so that to is contributing to the issues.

A 401 error is authentication. So it looks like communication is failing because it can't authenticate with the ISY/IoP. Double check the username and password in PG3 -> ISYs -> Edit Current ISY

@oberkcmake sure you're running the latest version of PG3. There have been a couple of bug fixes since the 3.1.6 version and symptom sounds like one of them.

That's what works for me, but I may have changed some of the restrictions on the polyglot account on my Polisys. I don't know any other way to do that.

@tmorse305If you refresh the store and try re-installing it should work now.

When node servers don't start, the PG3 log will have more information on why they don't start. We just discovered an issue today where if a node server was installed during the early alpha test time frame (before there were multiple node server stores) it can now fail to start because it's missing information in the local database records telling PG3 what node server store it was originally installed from. That's the working theory anyway. If the PG3 log shows a failure with auto update, then it's the same problem. I'm not sure how best to handle this. 1) it's not hard for me to add a check for this condition in PG3 and then assume the node server was installed from the production store. However, there have been other similar changes so it may just fail later because some other piece of info is missing from the database. 2) you can try simply re-installing the node server. With this version of PG3 you can simply click the "install" button in the store for this node server and you will have the option to re-install it to the same slot. This will download the latest version of the node server and update everything. The downside is that it will put the configuration parameters back to the default settings so you have to re-configure the node server. But nothing on the ISY/IoP side will change so programs remain intact.

Looks like the update process failed. This is the second report of this same failure, UDI is looking into why and how to resolve it.

I believe you. I just don't like it when PG3 does something it shouldn't.