Wait for astral to have attribute 'location' before using it

[ullebe1]

Sometimes while initializing the component the astral module doesn't have the location attribute yet when the component tries to use it, cause bugs like #148, #149 and #175.

This PR implements a loop that causes initialization to wait another second if the attribute isn't available yet. If it still isn't available after 30 seconds we let the initialization continue and crash, like before.

I have been running with a simpler version of the fix (a single 10 second sleep) for months, which has completely fixed the issue for me, but this version is a bit more clever to avoid waiting longer than necessary while also being more resilient in case longer is needed.

Closes #149, closes #175.

[amaisano]

Same problem. Please merge! The patch fixes the issue for me.

[claytonjn]

I'd feel better if this used asyncio.sleep, and unless I'm missing something location = astral.location.Location() should be within the while loop. <- looked at it too quickly, ignore.

Also, is there a similar problem with the location = astral.Location() call in the except block? If memory serves me right, this call is for astral 1.x.

[ullebe1]

I'd feel better if this used asyncio.sleep

The component is currently not async, so would it make sense to mix async into without converting the whole thing?
Also, made a quick test with it using asyncio.sleep, but when using that the fix didn't work anymore - perhaps because of the above?

Also, is there a similar problem with the location = astral.Location() call in the except block? If memory serves me right, this call is for astral 1.x.

It looks like it isn't present in 2.x as their docs point to astral.location.Location().

[claytonjn]

I actually have an async version running locally and will push that out as a new beta release as soon as I get a chance. That being said, I don't think this is required after #189 and using the homeassistant helper is likely a better solution.

@ullebe1 @amaisano can you confirm if 2.0.8-beta fixes this issue for you?

[ullebe1]

@claytonjn 2.0.8-beta fixes it for me, great if we don't need this workaround anyway. I'll continue testing over the next days and report back.

Also a future async version sounds awesome - thank you!

[ullebe1]

@claytonjn I just wanted to report back that after testing the 2.0.8-beta for the last two weeks it works great and completely solved the issue.

[claytonjn]

I've pushed this to the main branch and have the async code in the dev (beta) branch, so will close this.