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
* Add support for sending telegram messages to topics
Based on original PR #104059 by [jgresty](https://github.com/jgresty).
Did not manage to merge conflicts, so I remade the changes from scratch, including suggestions from previous PR reviews.
Topics were added to telegram groups in November 2022, and to the
telegram-bot library in version 20.0. They are a purely additive change
that is exposed by a single parameter `message_thread_id`. Not passing
this parameter will not change the behaviour from current.
This same parameter is used to send messages to threads and messages to
topics inside groups.
https://telegram.org/blog/topics-in-groups-collectible-usernames/it?setln=en#topics-in-groupsFixes#81888Fixes#91750
* telegram_bot: add tests for threads feature.
* telegram_bot: fixed tests for threads.
* telegram_bot: fixed wrong line.
* Update test_telegram_bot.py
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
Co-authored-by: Erik Montnemery <erik@montnemery.com>
* Add data coordinator to incomfort integration
* Remove unused code and redundant comment, move entity class
* Use freezer
* Cleanup snapshot
* Use entry.runtime_data
* Use freezer, use mock_config_entry
* Use tick
* Use ConfigEntryError while we do not yet support a re-auth flow, update tests
* Use tick with async_fire_time_changed
* Report non-awaited/non-locked config entry platform forwards
Its currently possible for config entries to be reloaded while their platforms
are being forwarded if platform forwards are not awaited or done after the
config entry is setup since the lock will not be held in this case.
In https://developers.home-assistant.io/blog/2022/07/08/config_entry_forwards
we advised to await platform forwards to ensure this does not happen, however
for sleeping devices and late discovered devices, platform forwards may happen
later.
If config platform forwards are happening during setup, they should be awaited
If config entry platform forwards are not happening during setup, instead
async_late_forward_entry_setups should be used which will hold the lock to
prevent the config entry from being unloaded while its platforms are being
setup
* Report non-awaited/non-locked config entry platform forwards
Its currently possible for config entries to be reloaded while their platforms
are being forwarded if platform forwards are not awaited or done after the
config entry is setup since the lock will not be held in this case.
In https://developers.home-assistant.io/blog/2022/07/08/config_entry_forwards
we advised to await platform forwards to ensure this does not happen, however
for sleeping devices and late discovered devices, platform forwards may happen
later.
If config platform forwards are happening during setup, they should be awaited
If config entry platform forwards are not happening during setup, instead
async_late_forward_entry_setups should be used which will hold the lock to
prevent the config entry from being unloaded while its platforms are being
setup
* run with error on to find them
* cert_exp, hold lock
* cert_exp, hold lock
* shelly async_late_forward_entry_setups
* compact
* compact
* found another
* patch up mobileapp
* patch up hue tests
* patch up smartthings
* fix mqtt
* fix esphome
* zwave_js
* mqtt
* rework
* fixes
* fix mocking
* fix mocking
* do not call async_forward_entry_setup directly
* docstrings
* docstrings
* docstrings
* add comments
* doc strings
* fixed all in core, turn off strict
* coverage
* coverage
* missing
* coverage
* Prelimenary tests for incomfort integration
* Use snapshot_platform
* Use helper
* Ensure the device name is set in device info
* Move snapshot tests to platform test modules
* Move unused snapshot file
* Naming and docstr
* update snapshots
* cleanup snapshots
* Add water heater tests
* Setup for split
* Adjust to allow for None
* Create
* Add missing
* Fix datetime parsing in Azure DevOps sensor
* Remove definition id and name
These aren't needed and will never change
* Add tests for each sensor
* Add tests for edge cases
* Rename translations
* Update
* Use base sensor descriptions
* Remove
* Drop status
using this later for an event entity
* Switch to timestamp
* Switch to timestamp
* Merge
* Update snapshot
* Improvements from @joostlek
* Update homeassistant/components/azure_devops/sensor.py
---------
Co-authored-by: Joost Lekkerkerker <joostlek@outlook.com>
* Add ista EcoTrend integration
* move code out of try
* Use account owners name as entry title
* update config flow tests
* add tests for init
* Add reauth flow
* Add tests for sensors
* add translations for reauth
* trigger statistics import on first refresh
* Move statistics and reauth flow to other PR
* Fix tests
* some changes
* draft_final_final
* remove unnecessary icons
* changed tests
* move device_registry test to init
* add text selectors
* Update BMW sensors to use device_class
* Test adjustments
* Trigger CI
* Remove unneeded cast
* Set suggested_display_precision to 0
* Rebase for climate_status
* Change charging_status to ENUM device class
* Add test for Enum translations
* Pin Enum sensor values
* Use snapshot_platform helper
* Remove translation tests
* Formatting
* Remove comment
* Use const.STATE_UNKOWN
* Fix typo
* Update strings
* Loop through Enum sensors
* Revert enum sensor changes
---------
Co-authored-by: Richard <rikroe@users.noreply.github.com>
* Add config flow
* Make sure the device is polled - refactor
* Fix
* Add tests config flow
* Update test requirements
* Ensure dispatcher has a unique signal per heater
* Followup on review
* Follow up comments
* One more docstr
* Make specific try blocks and refactoring
* Handle import exceptions
* Restore removed lines
* Move initial heater update in try block
* Raise issue failed import
* Update test codeowners
* Remove entity device info
* Remove entity device info
* Appy suggestions from code review
* Remove broad exception handling from entry setup
* Test coverage
