* Move state length validation to StateMachine async_set method
We call validate_state to make sure we do not allow any states
into the state machine that have a length>255 so we do not break
the recorder. Since async_set_internal already requires callers
to pre-validate the state, we can move the check to async_set
instead of at State object creation time to avoid needing to
check it twice in the hot path (entity write state)
* move check in async_set_internal so it only happens on state change
* no need to check if same_state
We have to build all of these at startup.
Its a lot faster to compare floats instead
of datetime objects. Since we already have to
fetch last_changed_timestamp, use it to compare
with last_updated_timestamp since we already know
we will have last_updated_timestamp
* Add new frame helper to clarify options available
* Adjust
* Improve
* Use report_usage in core
* Add tests
* Use is/is not
Co-authored-by: J. Nick Koston <nick@koston.org>
* Use enum.auto()
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
Avoid addtional timestamp conversion to set state
Since we already have the timestamp, we can pass it on to the State
object and avoid the additional timestamp conversion which can be as
much as 30% of the state write runtime.
Since datetime objects are limited to microsecond precision, we need
to adjust some tests to account for the additional precision that we
will now be able to get in the database
* Always do thread safety check when writing state
Refactor the 3 most common places where the thread safety check
for the event loop to be inline to make the check fast enough
that we can keep it long term. While code review catches most
of the thread safety issues in core, some of them still make
it through, and new ones keep getting added. Its not possible
to catch them all with manual code review, so its worth the
tiny overhead to check each time.
Previously the check was limited to custom components
because they were the most common source of thread
safety issues.
* Always do thread safety check when writing state
Refactor the 3 most common places where the thread safety check
for the event loop to be inline to make the check fast enough
that we can keep it long term. While code review catches most
of the thread safety issues in core, some of them still make
it through, and new ones keep getting added. Its not possible
to catch them all with manual code review, so its worth the
tiny overhead to check each time.
Previously the check was limited to custom components
because they were the most common source of thread
safety issues.
* async_fire is more common than expected with ccs
* fix mock
* fix hass mocking
* Reduce number of calls to last_reported_timestamp
When a state is created, last_update is always the same
as last_reported, and we only update it later if it changes
so we can pre-set the cached property to avoid it being
run when the recorder accesses it later.
* fix cache not being overridden
* coverage
* Refactor state_reported listener setup to avoid merge in async_fire_internal
Instead of merging the listeners in async_fire_internal, setup the listener for
state_changed at the same time so async_fire_internal can avoid having to copy
another list
* Refactor state_reported listener setup to avoid merge in async_fire_internal
Instead of merging the listeners in async_fire_internal, setup the listener for
state_changed at the same time so async_fire_internal can avoid having to copy
another list
* tweak
* tweak
* tweak
* tweak
* tweak
* Speed up async_get_loaded_integrations
Use a setcomp and difference to find the components to split
to avoid the loop. A setcomp is inlined in python3.12 so its
much faster
* Speed up async_get_loaded_integrations
Use a setcomp and difference to find the components to split
to avoid the loop. A setcomp is inlined in python3.12 so its
much faster
* simplify
* fix compat
* bootstrap
* fix tests
