Weatherflow API seems to have broken the integration

[robchandhok]

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:

2023-08-28 12:50:38.459 DEBUG (MainThread) [custom_components.weatherflow] Finished fetching weatherflow data in 0.218 seconds (success: True)
2023-08-28 12:50:38.878 DEBUG (MainThread) [custom_components.weatherflow] Finished fetching weatherflow data in 0.419 seconds (success: False)
2023-08-28 12:51:59.649 DEBUG (MainThread) [custom_components.weatherflow] Finished fetching weatherflow data in 0.195 seconds (success: True)
2023-08-28 12:52:00.141 DEBUG (MainThread) [custom_components.weatherflow] Finished fetching weatherflow data in 0.492 seconds (success: False)

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:

• deleting and re-adding the integration
• redownloading via HACS
• making a new access token and using it
• accessing the API via their URLs and my token, and that worked

[chheiss]

Strange. Without doing anything, I am currently getting readings for both stations. V 15

[UpDryTwist]

Folks -- check your Home Assistant logs. If you have the updated version (fully updated), and you have at least level WARNING set, you should be getting a warning in your logs. If not, check around on your system to ensure there's not something funky that's prevented you from getting the updated pyweatherflowrest -- you might be running with the old package for some reason . (Full disclosure, I haven't had time to run the update yet, so I can't check on my install.)

[Colorado4Wheeler]

Mine also started working about 30 minutes ago without any manipulation, perhaps there was just a delay in the API propagating or something.

[janick]

Still not working for me. I reloaded the integration and it still complains about the sea_level_pressure key

''' This error originated from a custom integration.

Logger: pyweatherflowrest.api Source: custom_components/weatherflow/init.py:121 Integration: WeatherFlow Weather (documentation, issues) First occurred: 8:16:03 AM (108 occurrences) Last logged: 12:15:17 PM

{'air_temperature': 16.0, 'conditions': 'Partly Cloudy', 'feels_like': 16.0, 'icon': 'partly-cloudy-day', 'local_day': 30, 'local_hour': 9, 'precip': 0, 'precip_icon': 'chance-rain', 'precip_probability': 0, 'precip_type': 'rain', 'relative_humidity': 78, 'time': 1693411200, 'wind_avg': 4.0, 'wind_direction': 210, 'wind_direction_cardinal': 'SSW', 'wind_gust': 4.0} 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. {'air_temperature': 17.0, 'conditions': 'Partly Cloudy', 'feels_like': 17.0, 'icon': 'partly-cloudy-day', 'local_day': 30, 'local_hour': 10, 'precip': 0, 'precip_icon': 'chance-rain', 'precip_probability': 0, 'precip_type': 'storm', 'relative_humidity': 75, 'time': 1693414800, 'wind_avg': 3.0, 'wind_direction': 210, 'wind_direction_cardinal': 'SSW', 'wind_gust': 4.0} You can set the value IGNORE_FETCH_ERRORS in pyweatherflowrest/api.py to ignore this error. {'air_temperature': 24.0, 'conditions': 'Partly Cloudy', 'feels_like': 24.0, 'icon': 'partly-cloudy-day', 'local_day': 30, 'local_hour': 13, 'precip': 0, 'precip_icon': 'chance-rain', 'precip_probability': 0, 'precip_type': 'rain', 'relative_humidity': 49, 'time': 1693425600, 'wind_avg': 3.0, 'wind_direction': 240, 'wind_direction_cardinal': 'WSW', 'wind_gust': 4.0} '''

[Colorado4Wheeler]

I also get the sea level pressure key issue but the rest still works... until I reloaded. I reloaded the integration to check what my exact message was on the sea level as I had already cleared my logs in system (and was too lazy to search the big log) and Weatherflow fails again. It does seem hit-and-miss. I'll try to do more in-depth logging but so far I'm getting about the same as @janick

[dennyChandler]

Failing as well - If I can assist any further please let me know.

Logger: pyweatherflowrest.api
Source: custom_components/weatherflow/__init__.py:121
Integration: WeatherFlow Weather (documentation, issues)
First occurred: 2:10:28 PM (45 occurrences)
Last logged: 2:27:21 PM

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.
{'air_temperature': 28.0, 'conditions': 'Clear', 'feels_like': 28.0, 'icon': 'clear-day', 'local_day': 30, 'local_hour': 15, 'precip': 0, 'precip_icon': 'chance-rain', 'precip_probability': 0, 'precip_type': 'rain', 'relative_humidity': 44, 'time': 1693425600, 'wind_avg': 4.0, 'wind_direction': 60, 'wind_direction_cardinal': 'ENE', 'wind_gust': 6.0}
You can set the value IGNORE_FETCH_ERRORS in pyweatherflowrest/api.py to ignore this error.

Made a call with weatherflow, here is the response object:

https://pastebin.com/aKtwwgh3

[ldeffenb]

You can set the value IGNORE_FETCH_ERRORS in pyweatherflowrest/api.py to ignore this error.

Well, apparently your installation has the "IGNORE_FETCH_ERRORS" set to false, so it is failing. I'm guessing that the released fix has this set to false as well, but it would apparently need to be set to true to actually ignore the fact that the sea_level_pressure isn't there?

[UpDryTwist]

@ldeffenb - on the nose. I left the PR set to False so that it wouldn't silently fail to get data, with no visibility . . . with a "to do" to find a way to properly configure it from the application to "true". Maybe the right thing to do is to set it to True in the short term, until a way is there to configure it from the client . . .

[ldeffenb]

At least the logs will still have the missing field(s) logged, if I read the fix source code correctly.

[robchandhok]

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.

[UpDryTwist]

@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!).

[UpDryTwist]

@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 . . .

[robchandhok]

@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.

[rwolfe5420]

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 Source: custom_components/weatherflow/init.py:121 Integration: WeatherFlow Weather (documentation, issues) First occurred: 9:39:37 pm (3 occurrences) Last logged: 9:39:37 pm

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. {'air_temperature': 13.0, 'conditions': 'Clear', 'feels_like': 13.0, 'icon': 'clear-night', 'local_day': 30, 'local_hour': 22, 'precip': 0, 'precip_icon': 'chance-rain', 'precip_probability': 0, 'precip_type': 'rain', 'relative_humidity': 79, 'time': 1693447200, 'wind_avg': 3.0, 'wind_direction': 30, 'wind_direction_cardinal': 'NNE', 'wind_gust': 4.0} You can set the value IGNORE_FETCH_ERRORS in pyweatherflowrest/api.py to ignore this error.

[yegorh]

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.

[JtwoA]

I updated and neither of my two stations was working. Now one is/one isn't.

[janick]

What is the easiest way to break out of the shell container and edit HA files/update files directly?

[briis]

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. I tried different Station ID's and with some of them (mine f.ex.) I get a value for sea level pressure, but for others I don't. I am not sure why, I have to get in touch with the WeatherFlow team to understand that. In the meantime, we could work around this by setting a 0 value for sea level pressure if it does not exist?

[janick]

How would HA react to a NAN value?

[UpDryTwist]

@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.

[UpDryTwist]

Just to summarize for everyone the situation:

1. Weatherflow is having some trouble with their API. We are speculating that they have multiple servers behind a load balancer, and that only some of the servers are poisoned. So you will see inconsistent results depending on which server gets handed to you by the load balancer. For the poisoned servers, neither "sea_level_pressure" nor "uv" is returned for the hourly forecasts, which breaks the Home Assistant integration.
2. Yesterday, I put in a patch that allowed the code to ignore errors (currently, only in the hourly forecasts; it could easily be extended to all the data reads). HOWEVER, I defaulted the condition to NOT ignore the errors, with a "todo" to add some way to set it to ignore (other than by editing the file). I did this on the misguided principle that errors shouldn't be silently ignored (e.g., for people using the component to record data, so they wouldn't have bad data recorded without a signal). Of course, this was a mistake, as most folks would rather it just collected bad data and worked otherwise ;).
3. @briis cut a release with my PR this morning. But of course, it was set to NOT ignore the errors, so it didn't fix things for people
4. I just submitted a PR that changes the default. So by default it will now ignore errors in the hourly data.
5. When briis gets a chance to accept the PR and cut 1.0.16, that should start working consistently for everyone.

[briis]

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)

[briis]

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.

[psmith3]

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.

Fixed. Thanks for this!

[deadrubberboy]

We have a hurricane coming up, and it'd be great to get everything recorded in HA. @eelcovb Where are you in the path? Lowcountry of SC here.

Orlando, FL no direct exposure, but probably some tornado's. Stay safe!

Orlando here too! Also my Tempest having same issue as others.

[robchandhok]

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.

Confirmed fixed for me, thank you @briis !

[JtwoA]

HUZZAH! Both units reporting in successfully - many thanks for hitting this hard, @briis - much appreciated!

[rwolfe5420]

    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: @.***>

[jeremyhamm]

1.0.16 resolved the issue for me. Thanks for everyones hard work in fixing this.

[janick]

Working now.

if they can give an explanation to why some stations do not have the Sea Level Pressure in the Forecast.

Maybe because my station is at 800ft altitude? :-)

[deadrubberboy]

1.0.16 resolved the issue for me. Thanks for everyones hard work in fixing this.

Same. All working again. Thank you!

[dennyChandler]

Confirmed working here as well, thank you all for your efforts in fixing this!

[chheiss]

Confirmed as working, thanks for all the effort!

[PYehl73]

I updated all my files - getting some data but many entities are showing not available? Weather Station not giving air temp anymore?? lol

[robchandhok]

I updated all my files - getting some data but many entities are showing not available? Weather Station not giving air temp anymore?? lol

Did you update to the .16 release or patch by hand? I'm getting air temp just fine on the actual release.

[PYehl73]

I updated the files manually. What steps do I need to do for actual release? (sorry newbie to HA)

Update - never mind I figured it out... rebooting now.

Nope after restarting - even deleted old one and put in my station ID / token again - only 45 sensors now.

I updated all my files - getting some data but many entities are showing not available? Weather Station not giving air temp anymore?? lol

Did you update to the .16 release or patch by hand? I'm getting air temp just fine on the actual release.

[Yomegaman]

Your fixes have everything working perfectly for me again. (Supervisor version)

Thank you ALL so much!

[briis]

I will close this now as the particular issue has been solved. If anyone still have issues please create a new issue with data from the logs.