Temperature in Cozumel, Mexico is out of expected range

[jum]

Describe the bug

Today I have checked multiple times, and the temperature in Cozumel, Mexico is consistently between 4 and 5 degrees Celsius. I have only a T-shirt and shorts on and I believe it is more like 28-30 degrees Celsius around here.

Expected behavior

Temperature in the above 28 deg Celsius range.

Actual behavior

Temperature in the 4-5 deg Celsius range.

API Endpoint

TimeMachine

Location

Cozumel, Mexico

Other details

Here is a partial json dump:

{ "offset" : -5, "hourly" : { "summary" : "Partly Cloudy", "icon" : "partly-cloudy-day", "data" : [ { "apparentTemperature" : 1.04, "pressure" : 1010.09, "precipIntensity" : 0, "time" : 1714856400, "windSpeed" : 5.5999999999999996, "windGust" : 8.4000000000000004, "summary" : "Cloudy", "temperature" : 4.54, "uvIndex" : 6.2000000000000002, "icon" : "cloudy", "visibility" : 16.09, "humidity" : 0.89000000000000001, "dewPoint" : 3.04, "precipType" : "rain", "windBearing" : 220, "cloudCover" : 0.76000000000000001, "ozone" : 287.79000000000002, "precipProbability" : 0, "precipIntensityError" : 0, "precipAccumulation" : 0 },

Troubleshooting steps

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

[cloneofghosts]

Thanks for the report. I'll ping @alexander0042 to look into the issue on his end as from my testing it seems to be an issue with the NBM model. A workaround for now is to add exclude=nbm to your query URL so the API will fallback to using the global GFS model which is returning more accurate temperatures.

[alexander0042]

Thanks for reporting this issue! These sort of edge case weather reports are incredibly helpful, and this is definitely a bug! I'm going to guess it's a problem with NBM grabbing the top grid index instead of the bottom one, but I'll let you know shortly

[alexander0042]

Thanks again for reporting this! I found the bug and am pushing out V2.0.4 later, which addresses it by adding a check in the lat/lon to x/y conversion to make sure that it's not a negative integer point

[jum]

Just did look again, works fine now!