-
Notifications
You must be signed in to change notification settings - Fork 11
Weatherflow API seems to have broken the integration #81
Comments
I have exactly the same versions / issue: in my log: 2023-08-28 16:27:52.329 DEBUG (MainThread) [custom_components.weatherflow] Finished fetching weatherflow data in 0.102 seconds (success: True) Tried the exact same things, rebooted everything multiple times. |
My integration is also broken with WeatherFlow Logs: Config entry '******' for weatherflow integration not ready yet: Error while retreiving forecast data: Error occured processing forecast data. Error message: 'sea_level_pressure'; Retrying in background |
@robchandhok Any idea what version of HA your Parents are running. I reverted to an older backup (2023.8.3) and it was still broken. |
I am on 2023.8.4 of HA and seeing this same error. HA log shows: API from my weather station still reports sea_level_pressure so not quite sure why we are suddenly seeing this error. Excerpt from the API webpage of my weather station: |
@jgosnell56 Not sure if it matters to you but you may want to hide your exact location. |
I can confirm same issue started earlier today. As luck would have it, we lost power at 3:40 ET and when it came back, this integration is no longer working. Completely updated system. Logger: homeassistant.config_entries Config entry 'The House' for weatherflow integration not ready yet: Error while retreiving forecast data: Error occured processing forecast data. Error message: 'sea_level_pressure'; Retrying in background Mine started work today 8/29 at 10am without doing anything??? |
I had exactly the same power outage "luck".. Checked my whole setup 6 times, changed the DB, threw away existing sensor data, just to find a fix.. |
it is broken for me too, as described above by robchandhok |
well time to dig into this code....uggg fun times LOL. I already commented out some stuff...with no luck. |
so looking at the straight up forcast api data that comes back... i don't see an issue with that json.... which means...something is getting messed up as its reads the data back is my guess, which could be the python library maybe?
|
2023.8.3 I am now convinced it's a bug in the config/init flow. So restart breaks it. Running instances are fine. Can't see it though. |
Annnnnndddd….. it’s back working. There still might be an opportunity to catch this at init (defensive programming) but I don’t hav3 an example to test against. Hopefully working for others. |
Just reloaded the plugin and it's still broken for me. |
Hmmm. Race condition? |
My Weatherflow died today too. I've tried deleting & reinstalling (HA Supervisor) but get these error lines; ERROR:asyncio:Task exception was never retrieved Then it sets up all my sensors with lines like this; Finally giving these errors; This has worked great for about a year - until today. PLEASE HELP |
I also started encountering this after a Home Assistant restart yesterday (using the cloud-based integration, not the local MQTT integration). Like the others, if I call the API myself, it appears to return well-formed JSON, with the appropriate "sea_level_pressure" key. I can't see any difference between that key and surrounding keys. I walked through the code (inspection, not debugger), and couldn't see anything anomalous in the code -- nothing that indicates why "sea_level_pressure" would hiccough and not any other value (if, say, it was indeed a race condition, I wouldn't expect us all to have the exact same experience). I think someone's going to have to look at this in a debugger (or with a lot of debugging statements turned on) to catch it. (If no one has a chance to do so, I may have some time this coming weekend, but certainly not before then.) One hypothesis: different JSON is returned for some reason when we're all invoking it in the browser than when it's being invoked from within Home Assistant (although this doesn't really make sense, as it seems to happen both for folks using the cloud-based API and the local MQTT-based API). First thing to do, I think, would be to see if it reproduces when just calling https://github.com/briis/pyweatherflowrest from a command-line harness. Just a thought. |
I haven't checked weatherflow community forum yet either... They might have info of changes
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: UpDryTwist ***@***.***>
Sent: Tuesday, August 29, 2023 9:01:09 AM
To: briis/hass-weatherflow ***@***.***>
Cc: Green Eggs and Code ***@***.***>; Comment ***@***.***>
Subject: Re: [briis/hass-weatherflow] Weatherflow API seems to have broken the integration (Issue #81)
I also started encountering this after a Home Assistant restart yesterday (using the cloud-based integration, not the local MQTT integration). Like the others, if I call the API myself, it appears to return well-formed JSON, with the appropriate "sea_level_pressure" key. I can't see any difference between that key and surrounding keys. I walked through the code (inspection, not debugger), and couldn't see anything anomalous in the code -- nothing that indicates why "sea_level_pressure" would hiccough and not any other value (if, say, it was indeed a race condition, I wouldn't expect us all to have the exact same experience). I think someone's going to have to look at this in a debugger (or with a lot of debugging statements turned on) to catch it. (If no one has a chance to do so, I may have some time this coming weekend, but certainly not before then.)
One hypothesis: different JSON is returned for some reason when we're all invoking it in the browser than when it's being invoked from within Home Assistant (although this doesn't really make sense, as it seems to happen both for folks using the cloud-based API and the local MQTT-based API). First thing to do, I think, would be to see if it reproduces when just calling https://github.com/briis/pyweatherflowrest from a command-line harness. Just a thought.
—
Reply to this email directly, view it on GitHub<#81 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADRHLMD7KOW7ZFUQ7I54FPLXXXRZLANCNFSM6AAAAAA4B52ZAQ>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Agree with @UpDryTwist . It's starting to look like the forecast API call is the culprit, it would be nice to still succeed with the station data in the face of that error (regardless of this specific error many of us are experiencing). I'm not a good enough python programmer to make that change tho. Just needs a wrap in an error catch. |
@briis - any feedback? |
I have been away for a long time, so I did not monitor this for a while. I will have a look at it ASAP. |
FYI, this might help. The other Home Assistant integration is having the same issue: A stated workaround there is:
(I have not verified that this helps, since I'm running this one...) (EDIT: I didn't realize both projects are by the same author! Cool!!!) |
Haven't looked into it thoroughly, but my 2 cents: Looking at a piece of forecast code, I noticed 'weather_daily' and 'weather_hourly' are used as keys: `_WEATHER_DAILY = "weather_daily" _LOGGER = logging.getLogger(name) WEATHER_TYPES: tuple[WeatherEntityDescription, ...] = ( However, on checking the API response, the forecast keys used seem to be 'daily' and 'hourly' (https://apidocs.tempestwx.com/reference/get_better-forecast). Again, only took a quick look, will try to look into it and test hopefully later today. We have a hurricane coming up, and it'd be great to get everything recorded in HA. Cheers |
|
Orlando, FL no direct exposure, but probably some tornado's. Stay safe! |
Checked it, not the issue. |
East coast of Florida and my HA-integrated Tempest has also gone offline. Talk about (bad) timing! |
OK, thought I wouldn't have time until this weekend, but it was bugging me (and it's driving me nuts looking at my dashboard with errors on it!), so I pulled it up in the debugger. @briis if you didn't already figure this out, the problem is that the hourly forecast no longer includes sea_level_pressure (I wonder if there was just a firmware push?). I'll confirm a fix and put up a pull request this evening. For others on this thread, after I confirm, I'll let you know how you might patch until Bjarne has a chance to cut a release. EDIT: Yup. Confirmed the fix. Will put up the pull request later, but for you hurricane trackers, below are general guidelines for how you can fix this in your installation. WARNING: There are many ways to run Home Assistant. I cannot speak for your own instance (nor, unfortunately, do I have the bandwidth today to troubleshoot other instances). You need to be reasonably technical to apply this patch; you need to understand the mechanics of your Home Assistance instance; and you need to be comfortable patching Python. You could break things!
Here are the steps I took to patch my version:
|
OK, @briis , the PR is there. Thanks, BTW, for this fantastic implementation! You can see how freaked out we all get when it's not working! |
I can confirm the change works. I was able to make the change inside HA. I'm using the OS version. |
Again my apologies for not really being a python guy, but if I could suggest (a) package a release with IGNORE_FETCH_ERRORS set to true by default, and (b) when debugging is on, log the IP address of the server (if that's possible). I pointed the Weatherflow support folks at this ticket as well, as the intermittent behavior points to a disparity between the load balanced instances of the server. |
@ldeffenb - yes, the logging will have the offender (first one found) and (if DEBUG enabled) the overall array returned. @robchandhok - good idea, and really my fault for having left it as False (I was erring on the side of no silent failures, but should have erred on the side of make it work). I'll try to get to it tonight with a PR for @briis to see tomorrow. In the meantime, folks can use the same patching instructions from my note above, which should work as-is still (WARNING, that's from theory, not because I tried it against the latest release!). |
@robchandhok - did the Weatherflow folks happen to mention the type of load balancing they're doing? If they're doing DNS round-robin, then it'll be useful to get the IP address returned by DNS for any given user. But if they have a bunch of servers behind a load balancer . . . then the IP of the actual server will be opaque to us. And I'm loathe to add in a bunch of extra code to fetch the IP if it won't be meaningful . . . |
@UpDryTwist They haven't replied yet, but you are correct it's behind ELB on AWS. Not worth the time, I agree. Best to just enable the robust handling of missing keys. |
Mine is also broken with the same sea level error. Not sure how to resolve the issue. So I have disabled for the time being. Logger: pyweatherflowrest.api The key sea_level_pressure is missing from the following array (DEBUG logging only), causing an error. It is likely that the Weatherflow API has changed unexpectedly. pyweatherflowrest on Github. |
Hey guys, I updated to .15 this morning, but it didn’t fix the issue. However, I just checked and it’s working fine now. |
I have now done some more testing - and as many of you noticed, it is the Sea Level Pressure for the Hourly Forecast that is causing the problems. |
How would HA react to a NAN value? |
@briis - I just added PR that defaults the variable I'd set to turn on/off ignoring errors in the hourly data to True (i.e., it will now just semi-silently ignore errors in the Weatherflow data). I changed the logging so that it logs at level WARNING at least once, but then shifts to DEBUG logging to not spam the logs. If you have a way to let the user set this variable (through a config setting when configuring the component), that'd be even better - but this should work for now for the vast majority of users. |
Just to summarize for everyone the situation:
|
Thank you @UpDryTwist for this summary. I am right now working on making it possible to toggle the IGNORE_FETCH_ERRORS from the Config Menu in the Integration. But the default will now be changed to True instead of False, so that you should get data, no matter if a single item is not present. Hopefully this can be released later today (It is early morning here in Denmark) |
1.0.16 is now published, which hopefully fixes this for everybody. I will keep this open for a while until I am sure this now works for all. |
Fixed. Thanks for this! |
Orlando here too! Also my Tempest having same issue as others. |
Confirmed fixed for me, thank you @briis ! |
HUZZAH! Both units reporting in successfully - many thanks for hitting this hard, @briis - much appreciated! |
Thank You for this, mine is working as well this morning.
Get Outlook for iOS
From: Bjarne Riis ***@***.***>Sent: Thursday, August 31, 2023 1:31 AMTo: briis/hass-weatherflow ***@***.***>Cc: rwolfe5420 ***@***.***>; Comment ***@***.***>Subject: Re: [briis/hass-weatherflow] Weatherflow API seems to have broken the integration (Issue #81)
1.0.16 is now published, which hopefully fixes this for everybody.
I will get in touch with the WeatherFlow team to see if they can give an explanation to why some stations do not have the Sea Level Pressure in the Forecast.
I will keep this open for a while until I am sure this now works for all.
—Reply to this email directly, view it on GitHub, or unsubscribeYou are receiving this because you commented.Message ID: ***@***.***>
|
1.0.16 resolved the issue for me. Thanks for everyones hard work in fixing this. |
Working now.
Maybe because my station is at 800ft altitude? :-) |
Same. All working again. Thank you! |
Confirmed working here as well, thank you all for your efforts in fixing this! |
Confirmed as working, thanks for all the effort! |
Did you update to the .16 release or patch by hand? I'm getting air temp just fine on the actual release. |
Your fixes have everything working perfectly for me again. (Supervisor version) Thank you ALL so much! |
I will close this now as the particular issue has been solved. |
See also #80 I think.
Home Assistant 2023.8.4
Supervisor 2023.08.3
Operating System 10.5
Frontend 20230802.1 - latest
I just stopped being able to read my Tempest. When you reload, the log reports:
2023-08-28 12:49:19.004 WARNING (MainThread) [homeassistant.config_entries] Config entry 'TheView' for weatherflow integration not ready yet: Error while retreiving forecast data: Error occured processing forecast data. Error message: 'sea_level_pressure'; Retrying in background
I turned on debugging and see this pattern:
My guess is that something changed in the API return values?
I am quite puzzled. My parents instance of HA (not up to 2023.8.4) still works with their tempest.
I have tried:
The text was updated successfully, but these errors were encountered: