Pirate-Weather/pirateweather

Current `humidity` value doesn't make sense in the HRRR domain

cloneofghosts opened this issue · 3 comments

cloneofghosts commented

Describe the bug

I noticed the other day when testing V2.1 that the humidity value changed between endpoints which makes sense because the data is coming from NBM and not HRRR. Due to these differences sometimes the humidity value shown in the API just doesn't make sense.

These are the values shown in the API currently:

  "temperature": 22.85,
  "dewPoint": 9.98,
  "humidity": 0.52,

If I run those values through a relative humidity calculator I get ~44% humidity which is what I get when I exclude NBM from the API. I bet NBM is being used instead of HRRR because the sub-hourly HRRR doesn't have relative humidity.

Expected behavior

The current humidity should be around 44%.

Actual behavior

The current humidity shows 52%.

API Endpoint

Production

Location

Ottawa, ON

Other details

No response

Troubleshooting steps

  • I have searched this repository and Home Assistant Repository to see if the issue has already been reported.
  • I have read through the API documentation before opening this issue.
  • I have written an informative title.
cloneofghosts commented

@alexander0042 Still seeing this issue I reported almost a month ago. I checked again and I see the following:

"temperature": 17.52,
"dewPoint": 10.36,

I stuck these values into some online calculators are showing roughly 63% relative humidity. NBM is showing: 59% whereas HRRR is showing 64%. I assume the slight difference is due to interpolation and the fact that HRRR subhourly doesn't have relative humidity.

The solution here would be to just swap to using HRRR relative humidity in the HRRR domain?

alexander0042 commented

Agreed- consistency is worthwhile here. Switched the humidity priority from NBM>HRRR>GFS to HRRR>NBM>GFS, so that if someone is excluding HRRR for some reason it'll still fallback to NBM. After thinking a bit about it, I think keeping it NBM > HRRR > GFS for hourly makes sense, because both parameters are there in both sources

cloneofghosts commented

Yeah it was just currently which needed to be fixed since it's a combination of HRRR and NBM data and the other blocks were fine.