bpwwer

Pushed version 1.0.1 with the fix.

Of course the data being sent would be different from what they document. Why would I expect their documents to be right [he said with much sarcasm]. It's an easy fix, I'll have it done shortly.

Next release - version 2.0.13 has been published to the plug-in store.

Nevermind, the raw data was in the attached lot in the first post. It looks like they added aqi data (named aqi_pm25), which matched the PM 2.5 sensor in the plug-in's parser. Should be fixed in the next release.

Ok, I see the problem. More issues with the data from Ambient. Looks like you have to air quality sensors. In all other cases, Ambient seems to append a number to the sensor field name to differentiate between multiple sensors of that type. They may be doing that for air quality sensors as well, but it's not documented that way in the API docs. I guess I really need to see the raw data you're getting for the station to see if this is something I can program around. When the plug-in is set to debug level logging, it should be dumping the raw data to the log file. The reason it matters is because the IoX/ISY needs each piece of data needs to map to a list of pre-defined, unique data identifiers. For air quality , the IoX/ISY supports only one PM 2.5 data value and Ambient is listing two in the data. Since the plug-in is parsing the data and dynamically creating the mapping to IoX/ISY types, it ends up creating two PM 2.5 node values with the same type. Then the Admin Console flags that as an error.

After clicking the Load Profile button, check the PG3 log. Are there any errors? Your description sounds like the admin console isn't getting all the profile files, but you say the mobile app is working fine so it's able to get those same files. That implies that the problem is with the admin console. If you can, enable the java console for the admin console (how you do this depends on the computer you're running the admin console on) and restart the admin console. The java console log will show errors it it's having issues with the profile files.

That sounds like the Admin Console didn't get the node definition for that node. Try the "Load Profile" button from the PG3 Ambient plugin details page. Then restart the Admin Console.

I can't help with the admin console showing different values than the mobile app or PG3. Once the plug-in feeds the data to PG3, it's no longer in control of where it goes or what happens to it. As to why you are only seeing a few values in the three nodes, what are you expecting to see? The plug-in parses the data from Ambient into the different sensors. Typically they name the data fields with different suffixes for each sensor. That's why there are three nodes, it seeing data fields with no suffix (main), data fields with '_in' suffix for the indoor sensor, and '_4' for sensor #4. Because of how plug-ins work, it can only support data fields that it knows about. So any data fields that the plug-in doesn't have a known mapping for, it ignores. With the plug-in log level set to debug, the log will show the raw data received from Ambient and which fields are being ignored.

Your station name has a character that is illegal to use in a node name. That's why it keeps failing. I believe node names are restricted to just alpha/numeric characters and maybe _ and - so PATTON&DNSVIEW fails because of the '&'.

You'll get more info about what is failing if you switch the log level of the plug-in to debug. It will then log what is being returned by the query. The error message indicates that what is being returned isn't in the format expected so it could be an error message. The request being made is: https://api.weatherlink.com/v1/NoaaExt.json?user=<Device ID>&pass=<Password>&apiToken=<API Token> You can try that in the browser using your parameters and see what it returns. There is a newer API available and a newer plugin that uses it. It's possible that this version of the API has been discontinued and no longer works. If that's the case I'll have to remove the plug-in. The version that uses the new API version is in the non-production store and named Davis_V2

I just publish version 2.0.11 which should clear the alerts once they are no longer active.

As near as I can tell something changed in the response from NOAA. The plug-in is looking for "There are no active watches, warnings or advisories" but that doesn't seem to exist anymore. Instead, the response is pretty much empty. I'll need to re-work the plug-in to detect that the response is empty instead of looking for that string.

Mostly, plug-in come to be because someone has a need for it. In many cases, the person with the need also has enough of a programming background (or is willing to take the time to learn enough) to create it themselves and then make it available for others. There are also cases where an existing plug-in developer will create a plug-in for others. In some cases this may be a work-for-hire (I.E someone pays them $500 to create the plug-in) or they may think it will be popular enough to make it worth their while. For this to work, there are typically some requirements: The developer needs access to the hardware that the plug-in is for. This may be that someone sends them hardware or someone with the hardware is willing to do a lot of testing for the developer. The developer needs access to documentation on how to talk to the hardware. Apparently, u-tec just released an API for local control of the locks and more, like just released in the past month or so. https://developer.uhomelabs.com/hc/en-us/articles/39731959004057-What-is-U-home-OpenAPI Looks like there might be enough there to develop a plug-in for it.

The plug-in sends the data to PG3x. If the data is showing up in PG3x and is updating, then the plug-in is working correctly and the problem lies elsewhere. If the data is not updating in PG3x, then it is most likely that the WeatherFlow hub is no longer sending out updates or something changed on your network such that the data being sent by the WeatherFlow hub is being blocked. This assumes you are configured to get data from the hub and not from the WeatherFlow servers. If you're configured to get the data from the WeatherFlow servers, then it's likely the requests to the server are failing or the server is failing to respond with any data. In all cases, the plug-in log file (once switched to debug level) what the plug-in is doing and if it is encountering any issues.

2024-12-09 14:30:47.948 MainThread udi_interface DEBUG roku:discover: Processing http://192.168.30.62:8060/ 2024-12-09 14:30:47.948 MainThread udi_interface DEBUG roku:discover: roku_dev = {'device-group.roku.com': '849BC5D71D1DF6C95F72', 'LOCATION': 'http://192.168.30.62:8060/', 'Server': 'Roku/14.1.4 UPnP/1.0 Roku/14.1.4', 'Ext': '', 'USN': 'uuid:roku:ecp:YJ00CJ339086', 'ST': 'roku:ecp', 'Cache-Control': 'max-age=3600'} 2024-12-09 14:30:48.058 MainThread udi_interface ERROR roku:discover: Discovery failed for http://192.168.30.62:8060/: 'data' 2024-12-09 14:30:48.058 MainThread udi_interface INFO roku:discover: Discovery finished It discovers a Roku device at 192.168.30.62, but when it makes a request to get more information about the device, the request fails. It's not the plug-in's fault, it can't make the request to the Roku succeed.

Ok, that seems like a bug in PG3x, it should be able to create/download something even if the plug-in doesn't start. Not having that will make if more difficult to debug. At this point, I'd suggest reinstalling one of the plug-ins, capturing the PG3x log file after that (make sure it's level is set to 'info') and attaching that log to a ticket to UDI.

And did the browser download a <plugin>.zip file? The .zip file includes more than just the PG3x and plug-in log files which is why I asked for that. From the log above, it looks like you changed the logging level for PG3x from 'info' to 'warnings'. When trying to debug issues, that's not really a good idea as we use the info level messages to understand what PG3x is doing. The one error shown was expected since we know the plug-in didn't start and generate a log file yet.

It appears that PG3x is unable to start any of the plug-ins. If you select he details/log for one of them (there won't be a log) there should be a button to download a log package. Download that and post or PM it to me.

I only have one old Vue device so I can't personally confirm that Vue 3 devices will work. There isn't anything in the plug-in that would block or stop it from working with Vue 3 devices as long as they are still using the same API.

The poll settings are PG3 settings. They tell PG3 how often to send a poll event to the plug-in. The value is number of seconds between events.

The "Onecall data query failed" error is a generic message that means the plug-in didn't get anything it could use when it queried the weather server. In almost every case like this, the server is returning an error message saying the API key is invalid. You can get more information about what the plug-in is doing prior to the error by setting the log level to debug. The debug level log will show the exact https query that the plug-in is using and will show what the server returned. If the server is returning an API Key invalid, there is nothing the plug-in nor I as the plug-in's author can do to change that. You'll need to work with OpenWeatherMap to get a valid API key.

My fault, I added a syntax error which causes it to crash on start. Version 2.0.5 should fix that.

The log helped. I think I understand what's happening and I made another change to better detect the dropped connection and attempt to re-connect automatically. This change is in version 2.0.4

I had left a comment in the code wondering if it needed to perform a discovery after the reconnect. So maybe the answer to that is yes. I did add a log message that says it's trying to re-connect and it should log that every 30 seconds while disconnected. Do either of you know if that's happening?

Did you make changes to blue-iris-poly.py file at some point? The update process is failing because it sees that someone changed that file and it doesn't want to nuke those changes. There's a couple of things you can do - 1) revert the file back to it's original using 'git' commands. git checkout blue-iris-poly.py or rm blue-iris-poly.py; git checkout and then do the re-install via the GUI 2) delete the node server and then re-install 3) install the new version to a different slot 4) force git to update the files - git fetch origin master; git reset --hard origin/master The safest way is delete and re-install. Running git commands manually could end up causing problems for future updates unless you also make sure all the permissions/file ownership is correct.