bpwwer

PG3 has dependencies on other components on the system and if those aren't yet fully operational when PG3 tries to start, it can cause login failures. There are a few different reasons why logging in can fail. 1) Clicking the login button and nothing happens. This usually means that the component that does actual authentication check is not working right. This could be because it isn't fully started yet or it could mean it has hung. If it isn't fully started, it should eventually and then things will work. If it's hung, the only solution is to reboot the system 2) Clicking the login button and an error 401/unauthorized message pops up. This happens when the component that does the authentication returns something other than success. Most likely because the username or password is incorrect. 3) Clicking the log in button and an unknown error message pops up. This happens if PG3 is unable to connect to the component to do the authentication. It may not be running or it failed while starting up. The only solution is to reboot the system.

And you've tried restarting PG3? From the PG3 menu: System -> Restart Polyglot 3x

Typically, not being able to get the list of purchased nodes means that PG3 does not currently have the access rights to do so. PG3 needs an access token for your portal account in order to query for the node server's you've purchased. Normally if it doesn't have the access token, it will send a command to the WebUI asking it to get the token for it, since that is an interactive process it needs to be done via the UI. @DennisC's suggestions are good. I'd also add that you may want refresh the browser page and then log out and log back in first and see if that prompts you for the portal authentication.

Probably because the WeatherFlow app is showing adjusted values vs raw sensor values. I'm working on adding the adjusted values to the node server but it's not done yet.

PG3/PG3x now does a pretty good job of recovering from network issues without it causing any visible issues. If node servers loose their connection to PG3(x), they'll keep trying to connect until they succeed. If PG3(x) looses network connectivity or crashes, in most cases it will recover transparently. But the way the notification feature in PG3(x) works is that it now detects these issues and reports them. Chances are very high that these disconnections/connection events where happening all along and you just didn't know until it started sending the notifications. In general, these types of events are being caused by external factors so the node servers and/or PG3(x) can't do anything to make them stop. But if PG3(x) is crashing periodically, causing all node servers to disconnect/reconnect it's good to check the log and report it as it probably is bug in PG3(x).

Ah, I understand. Don't change anything there. Polyglot based node servers configure everything on the IoX automatically. From the Polyglot website, you should now have a dashboard view that includes the Caseta node nodeserver, click the details there and you'll see something like this: Click the Configuration button and you'll see a field where you can enter the IP address of Caseta Bridge. Once you enter that and save it, you should get a notice prompting you to press the black button to pair. It should pair in a second or two. Once it pairs it will query the bridge and add nodes to the IoX for each device it finds. When it's done, you'll have to restart the Admin Console so it can read the new created nodes properly and display the correct fields and status.

I'm maintaining that node server, but mostly that means that I'll attempt to fix any bugs that show up. I didn't write it and I don't have any hardware to test with. I can attempt to add features but I'll need details on the what is being sent in the data for the different sensors.

@RichTJ99 My Caseta node server asks for the IP address of the bridge and then prompts you to press the button on the bridge to link just like HA does. It doesn't ask for a password. It also has the following instructions included. The Lutron Caseta node server has the following parameters: * lutron_bridge_ip: This is the IP of your Smart Bridge Device. If you have a Pro Bridge you can set a statis IP by opening the app and going to Settings->Advanced->Integration->Network Settings Once the ip address has been entered and saved, you will be prompted to press the button on the back of the Smart Bridge. Pressing the button will pair the Lutron Caseta node server and SmartBridge. Once paired, the Lutron Caseta node server will query the Smart Bridge for the connected devices and create ISY nodes to represent those devices. The Discover button may be used to force the node server to re-query the Smart Bridge. Use this if you add additional devices to the Bridge using the Luton App. I'm not sure what you are using the eisy to try and connect to the Caseta bridge.

In the node server config you can create a group of devices that can then be controlled as a single entity. But I don't think you can make use of groups created in the app.

I suspect that most node server consider a lose of connection to the device a fatal error. They make the connection on start and fail if the connection is lost. I agree that it would be better to attempt to re-connect and only fail if unable to reconnect for some period of time. But I doubt most node server developers take the time do that. I'm pretty confident that it would have nothing to do with the public IP address, it's just the way the node servers are defined to behave.

I can see the problems. Ambient does a very poor job of using consistent rules for naming data fields. That and the fact that every station/set of sensors presents different data makes it difficult to have a node server that handles everything. It's not practical to write individual node servers for each person's individual configuration. So the node server has rules it uses to parse the data out of that structure. If you look at the soil sensors you see soilhum1 - soilhum5 along with battsm1 - battsm5. So there are 6 sensors represented (one with no suffix and sensors 1, 2, 3, 4, 5.) Then start looking at what other fields have each suffix; humidity1, batt1, feelsLike1, dewPoint1 and just to be slightly different, temp1f That's probably not one piece of hardware, but based on the naming of the fields I have no way to know that. Notice two battery fields, battsm1 and batt1. For air quality it's even worse. You have; pm25, pm25_24h, aqi_pm25, aqi_pm25_in_24h, batt_25in, batt_co2 The node server knows the difference between the current value and 24hr value but again, I suspect that pm25 and aqi_pm25 are different sensors since you say you have indoor and outdoor units, but there's no way to tell that from the data. Why aren't these suffixed to indicate they are different sensors? Right now, these all get lumped under sensor Main. It looks like there are 13 different battery state fields in there. The node server can detect some of those as unique batteries, but given the number of duplicates, not all of them. This is most certainly the most convoluted data set I've seen from them yet. I can probably modify the node server to handle this, but I'll need a debug log from the node server. Please set the log level to debug and restart the node server, give it a couple of minutes and then download the log and PM it to me. I can add it to my list of node servers that need work. But I can't commit to a ETA at this time.

The data the node server is getting from the station looks to be something the node server can't handle. The node server parses the incoming data and creates the nodes to display that data. It does this because there's not a lot of consistency between the sensors and data each station reports. There's no really way to know ahead of time what data any specific station will be sending. Your station however, is sending data that causes the node server to generate bad node definitions. I've not any station do this before. Looking through the errors: e8db84e3ca4a_1 looks like it has two PM25 values and two of some other air quality values. For a node, there can only be one of each e8db84e3ca4a_2 same as above. e8db84e3ca4a_3 has two battery levels. How is that even possible? e8db84e3ca4a_4 again two battery levels e8db84e3ca4a_5 has two battery levels and nothing else, what kind of sensor is that? e8db84e3ca4a_6 a temperature sensor and two battery levels, why does a temperature sensor need two batteries? Since I know nothing about the equipment you have, I don't know what to tell you other than the node server is not designed to handle the data being returned for the sensors.

Probably not, since UD Mobile is able to display them, they are installed correctly on the IoX. It's just the console that isn't displaying them correctly. Everything is stored in the IoX and then both UD Mobile and the console pull the information from there. It's possible there's an error in the node definition files and when the console reads them it fails to parse something and aborts. That info would be shown on the Java console and know where else. Since the node definitions files are dynamically created based on your station configuration, it's not something would be able to replicate easily. The console is less tolerant of error in the definitions than other other components on the system.

Glad to hear it's working. I don't know when I broke that but it was a pretty serious bug so I'm glad you let me know. You can send a note to sales@universal-devices.com and request a refund for the first purchase.

@Sparks at this point there's no evidence that you ever actually purchased (or tried to purchase) the Bond node server. All the logs we have access to show you activating a trial license for MyQ and trying to purchase MyQ. The only log we don't have direct access to is the PG3 log on your system. You'll probably have to do this via a file transfer process between your normal computer and the Polisy/eisy. You can check that or copy it from your system and PM it it to me. The log will be in /var/polyglot/pg3/logs and you'll want the one for the data that you were trying to activate/purchase Bond. If that was Thursday, the log would be pg3-2023-06-01.log.gz You can also request that someone do a remote session with you via the ticket you opened and we can remote in and review the file directly.

Unauthorized means just that. You've entered a username or password that is not correct. PG3x uses the IoX to authenticate so the usernames and passwords are the same as the ones configured in the Admin Console. Whatever you use to log in to the Admin Console is what you use to log into PG3.

If it's working with UDMobile but not the Admin console, then it's probably not the node server. It still seems like the Admin console hasn't read the node definitions and thus, doesn't know how to represent the nodes. You could enable the Java console and see if the admin console is throwing any errors when it loads. Based on my understanding, UDMobile uses formatted values from the IoX so to get those, the IoX needs access to the node definitions. That means that IoX has the proper definitions and for some reason the admin console is not able to get them from the IoX. It appears that the node server is working correctly. So if the Java console doesn't provide any info, you'll have to open a support ticket.

At this point, we have not been able to identify the root cause for the missing files. The current recommended solution is to migrate to PG3x, and yes, it works on a Polisy. There are instructions on the wiki https://wiki.universal-devices.com/index.php?title=Polisy:User_Guide under the heading "Upgrading to PG3x"

When PG3x process a login request, it sends back either a success or fail message that will pop up on the screen. If you're not getting that (I.E. nothing happens when you press login). That indicates that PG3x was not able to get a response when it tried to authenticate your login and thus has nothing to pass back to the browser. If you have not yet updated the system, I'd recommend that you first do a "Upgrade Packages" from the admin console's configuration tab. Depending on what all needs to be updated, this can take 15 or more minutes. After the system has been upgraded, it will need to reboot. Either reboot the system from the admin console's configuration tab or pull the power wait 10 seconds and re-apply power. If your system is up-to-date, then it may just need a reboot.

So far, all of the reported issues involving missing files on install have happened on PG3. After migrating to PG3x, the issue no longer happens. We have been unable to determine the root cause. So the current recommendation is to migrate to PG3x.

Have you restarted the admin console since installing the node server? Every time you install a new node server, you have to restart the admin console so that it read the information from the node server that describes how to display the nodes. Otherwise you end up with random/incorrect info displayed for the nodes.

I already checked the node server store database and everything looked fine. What is currently in the store database for Bond is just the one perpetual purchase option. @Goose66 if you pull up the production Bond entry from your developer list, what do you see for options? I've not heard of a case where the submission fails to include a purchase option, but that doesn't mean it can't happen.

Can you post/pm me the URL? If the server isn't responding at all to the query, yeah, I can't fix that in the node server. But I can check the query and make sure the node server is creating an invalid query.

What version of PG3 are you running? It looks like a file didn't get installed that is required for the node server to run. There have been a couple of case where PG3 (not PG3x) fails to install all of the node server file. We have not been able to determine the root cause of this issue and the current work around is to migrate to PG3x. If you are already running PG3x, then please try a re-install. If you continue to get this error then this would be the first case where this has occurred on PG3x.

Yes, you can ignore it, but unless you're actually trying to debug an issue, it's best to leave the log level at info or even error