Current summary and icon sometimes returning `none`
SiriosDev opened this issue · comments
Describe the bug
In recent days I have been experiencing repeated appearances of the exceptional state. Checking on merrysky it does not turn out to be anything particularly out of the ordinary
Expected behavior
See an analogue to the conditions shown by other PW-based
Actual behavior
e.g. exactly now it is shown exceptional when the condition is trivially partly cloudy
(eccezionale mean exceptional)
Home Assistant version
2024.7.4
Integration version
1.5.2
Other details
Unfortunately, the exceptional condition is poorly documented but browsing the core code these seem to be the conditions that fall under the term exceptional
#... CONDITION_CLASSES: dict[str, list[str]] = { ATTR_CONDITION_EXCEPTIONAL: [ "Tornado", "Hurricane conditions", "Tropical storm conditions", "Dust", "Smoke", "Haze", "Hot", "Cold", ], #...
Troubleshooting steps
- I have updated my Home Assistant installation to the latest version.
- I have updated the Pirate Weather Integration to the latest version.
- I have gone through the documentation before opening this issue.
- I have searched this repository and API Repository to see if the issue has already been reported.
- I have restarted my Home Assistant installation.
- I have queried the API in my browser to confirm the issue is not with the API.
- I have written an informative title.
Thanks for opening this issue. Taking a look at the code its setup to return the exceptional condition if the condition code is tornado or none.
Out of the two conditions the only one which can sometimes be returned by the API is none. The bigger question is why is none being returned as a condition.
Whereabouts are you approximately located so @alexander0042 can take a look and see what's going on. It might be related to the weird issues that people have been seeing with the API (see #229). API version 2.1 should fix these issues but its only been released on the dev endpoint.
ye ik the issue 229 of the main repo, the author looks a LOT like me after all 🤣. Joking aside, Could be the API, I didn't get around to taking the screenshot but indeed, now that I opened it even from the Breezy Weather app with PW as source, it showed None (before it updated). I was misled by merrysky 😅
ye ik the issue 229 of the main repo, the author looks a LOT like me after all 🤣.
Yes, I realized after I posted that you had created that other issue.
Could be the API, I didn't get around to taking the screenshot but indeed, now that I opened it even from the Breezy Weather app with PW as source, it showed None (before it updated). I was misled by merrysky 😅
Yes, it's an issue with the API returning none instead of the current condition which shouldn't be happening. I'd like to test to see if this issue is fixed in API V2.1 but I haven't been able to find a location to test with. I'll see if I can find one to test with or if you have a location to use feel free to share and I can see if V2.1 will fix this.
I will do some tests, as soon as I find a new none/exceptional I will write in the coordinates, although perhaps (It is clear that it is an API-side problem) it would be appropriate to close this issue to continue on the original issue
I've moved this issue over to the API repository since it's an issue with the API and not the HA integration. I'll leave this one open for now until we can confirm that V2.1 of the API will fix this issue as it could be a different issue entirely.
Thanks for flagging this- it's been tricky to try to get fixed, so every report helps! Do you mind letting me know where you're located, since that'll help me find the offending process flow
at the moment nothing strange, however the position is around this 39.51181975109912, 15.945201813230057
Looked into this today and I'm 90% sure I know the issue here! What seems to be happening is an issue with the interpolation for the minutely data, essentially when the probability/ amount of precipitation increases significantly from one 3-hourly output timestep to the next, it can get into a situation where the the amount is enough to trigger a rain icon but there's no categorical percentage yet.
Long story short, there's two parts to the fix. The first is adding a check to see if this is occurring and fixing it (easy), and secondly is switching the interpolation approach to be more consistent. Testing both the changes on the dev endpoint at the moment, and will be rolled out in 2.1!
Ok, finally got to the bottom of this, and it turns out that it's (mostly) not a bug in my code for once! GEFS will sometimes (not often) return no precipitation type despite modelling precipitation. If you want to validate it, look at latitude=24.0, longitude=261.5, on 2024-08-15 21:00:00 using the 2024-08-14 T06Z forecast, where there's a mean accumulation of 0.032 mm but no categorical precipitation.
That being said, the API response should be able to handle this, and the obvious answer is to set precipitation to zero, since it always seems to occur with very small amounts. probabilities. I'll update the code to handle that, but it's good to know I'm not crazy here