Fix non thread safe state write in acmeda integration

[atmurray]

Breaking change

Proposed change

The underlying module uses asyncio and the callback is run within the library's event loop.
As such, the following runtime error was being thrown when calling async_write_ha_state:

RuntimeError: Detected that integration 'acmeda' calls async_write_ha_state from a thread other than the event loop, which may cause Home Assistant to crash or data to corrupt. For more information, see https://developers.home-assistant.io/docs/asyncio_thread_safety/#async_write_ha_state at homeassistant/components/acmeda/base.py, line 65: self.async_write_ha_state().

To resolve this, the library is now initialised to use the existing event loop of home assistant. The callbacks are now async so that they are run within the home assistant event loop thereby allowing async_write_ha_state to be called.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes Covers stopped reporting state from 2024.7.0 onwards (Rollease Acmeda Automate integration) #123509
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[atmurray]

This change was previously included in the pull request #124960 but has been split out into a dedicated pull request.

[atmurray]

@bdraco would you mind checking this out.
The library already supports passing in an existing event loop so if I understand what you're saying the better fix would be to re-use the existing home assistant event loop in the library rather than creating a new one? If this is right, how do I get a reference to the home assistant event loop?

[bdraco]

@bdraco would you mind checking this out. The library already supports passing in an existing event loop so if I understand what you're saying the better fix would be to re-use the existing home assistant event loop in the library rather than creating a new one? If this is right, how do I get a reference to the home assistant event loop?

Yes that would be much better if possible.

hass.loop or asyncio.get_running_loop()

[atmurray]

Yes that would be much better if possible.

hass.loop or asyncio.get_running_loop()

OK done, that was surprisingly easy. Only additional thing I had to do was to make the callback async so that it ran within the event loop.

[joostlek]

If I remember correctly, callbacks can't be async

[atmurray]

Within the library, the callback resolver looks at the callback function and if it is a coroutine (async) creates a task on the event loop, otherwise it runs the callback on the executor.

[joostlek]

I'll wait for bdraco on this one, since the next patch will be out next friday, we don't have a rush to merge :)

[bdraco]

This will work but its very inefficient since creating a task is an order of magnitude more latent than executing a callback.

In core we have a decorator, @callback to tell core how to run a callback.

If its decorated with @callback it runs in the loop, if not it runs in the executor

core/homeassistant/core.py

Line 247 in 5405279

def callback[_CallableT: Callable[..., Any]](func: _CallableT) -> _CallableT:

core/homeassistant/core.py

Line 253 in 5405279

def is_callback(func: Callable[..., Any]) -> bool:

core/homeassistant/core.py

Line 387 in 5405279

if is_callback(check_target):

In the library you could do something similar, however if you are always running everything in the same loop there is likely no need to ever run anything in the executor and you could run the callbacks directly in the library and remove the executor code.

[frenck]

This PR has a merge conflict, could you take a look @atmurray ?

../Frenck