KeyError due to pressure_trend + other keys missing from better_forecast API response

[jdandrea]

Filing this here in case others are noticing the same issue. This appears to be a WeatherFlow issue, however if they're mid-changing their API for some reason it may be necessary to adjust on the weatherflow4py end too. Hopefully this is just a hiccup.

The issue: pressure_trend and five other previously expected key/value pairs have gone missing from my current_conditions response in the past 24 hours or so, leading to a KeyError (redacted API call for reference, called in WeatherFlowRestAPI).

In addition to pressure_trend, also missing from my current_conditions are these:

• solar_radiation
• time
• uv
• wet_bulb_globe_temperature
• wet_bulb_temperature

They're all documented so they shouldn't be missing in the response IMO. I've also filed a support request with WeatherFlow to see if anything odd is happening on their end.

The following are also missing, however they appear to be considered optional because they have default values and are also only supported when making a point/coordinate request anyway.

• brightness
• station_pressure
• delta_t
• dew_point
• lightning_strike_count_last_1hr
• lightning_strike_count_last_3hr
• lightning_strike_last_distance
• lightning_strike_last_distance_msg
• lightning_strike_last_epoch
• precip_accum_local_day
• precip_accum_local_yesterday
• precip_minutes_local_day
• precip_minutes_local_yesterday
• air_density
• is_precip_local_yesterday_rain_check

Note that, in accordance with the API, a station ID is being passed in and not a point/coordinate, so pressure_trend ought to be returned.

[IvanLH]

I also have noticed this, beyond WeatherFlow's behavior, would it be best to assign defaults across the board for all values in the dataclass? AFAIK this library is not using the values for anything beyond reporting it to HA. So a parse to None or a '0' value shouldn't affect things. I could help out if needed. I already had to learn why the thing was failing.

[jdandrea]

@IvanLH When I forked the repo and tried to set defaults for those fields just to see what would happen, I got a new exception: <class 'weatherflow4py.models.rest.forecast.WeatherDataForecastREST'> -- 'mixed_winter_precip' is not a valid PrecipType ... which I thought made sense because HA core is still using Version 1.0.6 <!!!>, which in turn doesn't have the class methods to support this ...

... except, no, those changes are super recent (thanks git blame). It looks like @jeeftor just swooped in about a half hour ago with an attempt to fix some parsing challenges on the WeatherFlow API side (thank you!!). Like they wrote, it's not glamorous but it reportedly works.

So I'll try the revision (though it's not yet packaged, perhaps I should wait for that and force it with pip in my container venv), and also see if we can get HA to use 1.2.0 or higher and not be fixed on 1.0.6... but it does look like their convention is to use a single revision and not use >=. Circling the airport!

[jdandrea]

The revision is more extensive as well, for example the use of PressureTrend.UNKNOWN so yep I'm going to sit tight and if help is sought with cross-checking, happy to do that too. But yeah, a bit of a mess that @jeeftor didn't make and had to try and clean up.

[jeeftor]

Latest tag should be working. Need to get a pr into ha now

[IvanLH]

It seems WeatherFlow has fixed things on their end. At least for me. But thanks for the quick turnaround!

[jdandrea]

What @IvanLH said, thank you @jeeftor!!!

[jeeftor]

Are you guys still fighting this? I'm trying to close out: home-assistant/core#125611 - which I think I need to do 1st before I can get these changes added...

[IvanLH]

It hasn't happened to me again. So no rush I guess.

[jeeftor]

Closing based no this hasn't h happened in a while