* First pass at timers
* Move to separate file
* Refactor to using events
* Add pause/unpause/status
* Add ordinal
* Add test for timed Assist command
* Fix name matching
* Fix IntentHandleError
* Fix again
* Refactor to callbacks
* is_paused -> is_active
* Rename "set timer" to "start timer"
* Move tasks to timer manager
* More fixes
* Remove assist command
* Remove cancel by ordinal
* More tests
* Remove async on callbacks
* Export async_register_timer_handler
* Allow templates for enabling automation triggers
* Test exception for non-limited template
* Use `cv.template` instead of `cv.template_complex`
* skip trigger with invalid enable template
instead of returning and thus not evaluating other triggers
* Import and cache supported feature enum flags only when needed
* Add comment aboud being loaded from executor.
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
Use a dictcomp to reconstruct DeviceInfo
a dictcomp is faster than many sets on the dict by at least
25%
We call this for nearly every device in the registry at
startup
* Small speed up to setting up integration and config entries
When profiling tests, I noticed many calls to get_running_loop. In the places
where we are already in a coro, pass the existing loop so it does not have to
be looked up. I did not do this for places were we are not in a coro since there
is risk that an integration could be doing a non-thread-safe call and its better
that the code raises when trying to fetch the running loop vs the performance
improvement for these cases.
* fix merge
* missed some
* Addition of add filter
This change adds an `add` filter, the addition equivalent of the existing `multiply` filter.
* Test for add filter
* Update test_template.py
* Update tests/helpers/test_template.py
---------
Co-authored-by: Erik Montnemery <erik@montnemery.com>
* Turn on thread safety checks in async_dispatcher_send
We keep seeing issues where async_dispatcher_send is called from
a thread which means we call the callback function on the other
side in the thread as well which usually leads to a crash
* Turn on thread safety checks in async_dispatcher_send
We keep seeing issues where async_dispatcher_send is called from
a thread which means we call the callback function on the other
side in the thread as well which usually leads to a crash
* adjust
* Refactor entity_platform polling to avoid double time fetch
Replace async_track_time_interval with loop.call_later
to avoid the useless time fetch every time the listener
fired since we always throw it away
* fix test
* Add title feature to notify entity platform
* Add overload variants
* Remove overloads, update signatures
* Improve test coverage
* Apply suggestions from code review
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Do not use const
* fix typo
---------
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Add thread safety checks to async_create_task
Calling async_create_task from a thread almost always results in an
fast crash. Since most internals are using async_create_background_task
or other task APIs, and this is the one integrations seem to get wrong
the most, add a thread safety check here
* Add thread safety checks to async_create_task
Calling async_create_task from a thread almost always results in an
fast crash. Since most internals are using async_create_background_task
or other task APIs, and this is the one integrations seem to get wrong
the most, add a thread safety check here
* missed one
* Update homeassistant/core.py
* fix mocks
* one more internal
* more places where internal can be used
* more places where internal can be used
* more places where internal can be used
* internal one more place since this is high volume and was already eager_start
It turns out we have custom components that are writing to the area registry using the async APIs from threads. We now catch it at the point async_fire is called. Instead we should check sooner and use async_fire_internal so we catch the unsafe operation before it can corrupt the registry.
* Move thread safety check in entity_registry sooner
It turns out we have a lot of custom components that are writing
to the entity registry using the async APIs from threads. We now
catch it at the point async_fire is called. Instread we should check
sooner and use async_fire_internal so we catch the unsafe operation
before it can corrupt the registry.
* coverage
* Apply suggestions from code review
It turns out we have custom components that are writing to the device registry using the async APIs from threads. We now catch it at the point async_fire is called. Instead we should check sooner and use async_fire_internal so we catch the unsafe operation before it can corrupt the registry.
Michael Hansen
J. Nick Koston
Matthias Alphart
Allen Porter
Marc Mueller
Sid
Troon
Jan Bouwhuis
G Johansson
Erik Montnemery