bpwwer

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.

First off, my comments and reasons for not wanting to allow for automated restarts of node servers/PG3 are really because that tends to be used as a band-aid to handle poorly behaving node servers. The right way to do things is to get the node servers to not behave badly. In this case, the node server isn't really behaving badly, it's behaving mostly as intended. When it can't communicate with Blue Iris, it goes into a disconnected state and waits for someone to take action to resolve the issue. Now it could and should handle this better. It should try to re-connect, the code is mostly there, just not the logic to attempt that. In cases like this, where the author has pretty much abandoned the node server, I'll typically take a look if I have time. Unfortunately, I don't always have time to dig into someone else code to figure out how it works and what can be done to resolve any issues. You happened to ask at a time when I'm not real busy so I'm going to try and make some changes. Version 2.0.3 should try to re-connect when it fails to query the Blue Iris server. I have no way to test this.

Yes, for plug-in's it doesn't display historical information, just real-time. The PG3x log itself does display historical information (back to midnight of the current day). Each daily log is saved for 2 weeks, I believe, but there's no way to view those daily logs via the GUI. debug would show the most information, critical shows the least. Typically you'd want to have this set to error or warnings. Those will show (as you might expect) error messages and warning messages. The plug-in developer determines what messages are shows at each level and there isn't any standard for what messages get shown at what level. So how useful each level is, depends on the developer. The log messages are supposed to be just human readable text. Some additional information is included in them by default: date/time, the log level, the module where the message was generated from. For the most part, you can ignore all of that. Here's a breakdown of a log message: DATE TIME Thread Name Module LOGLEVEL MESSAGE 2024-10-27 00:00:35.500 Thread-3 (run_forever) udi_interface DEBUG picos:btn_callback: Button on was Press

From the log, it appears to be working. Successfully set {UID} :: CLIFRS to 0 UOM 25 Successfully set {UID} :: CLIFRS to 1 UOM 25 Successfully set {UID} :: CLIFRS to 2 UOM 25 Successfully set {UID} :: CLIFRS to 3 UOM 25 That shows it setting the fan value to low, medium, high, auto There's nothing in that log that shows it setting the level to 'Not Supported' Based on what I see, the plug-in is working correctly. Have you restarted the Admin Console? If not, try that.