- These were using orjson directly, its a bit cleaner
to use the helper so everything is easier to adjust
in the future if we need to change anything about
the loading
* Initial orjson support take 2
Still need to work out problem building wheels
--
Redux of #72754 / #32153 Now possible since the following is solved:
ijl/orjson#220 (comment)
This implements orjson where we use our default encoder. This does not implement orjson where `ExtendedJSONEncoder` is used as these areas tend to be called far less frequently. If its desired, this could be done in a followup, but it seemed like a case of diminishing returns (except maybe for large diagnostics files, or traces, but those are not expected to be downloaded frequently).
Areas where this makes a perceptible difference:
- Anything that subscribes to entities (Initial subscribe_entities payload)
- Initial download of registries on first connection / restore
- History queries
- Saving states to the database
- Large logbook queries
- Anything that subscribes to events (appdaemon)
Cavets:
orjson supports serializing dataclasses natively (and much faster) which
eliminates the need to implement `as_dict` in many places
when the data is already in a dataclass. This works
well as long as all the data in the dataclass can also
be serialized. I audited all places where we have an `as_dict`
for a dataclass and found only backups needs to be adjusted (support for `Path` needed to be added for backups). I was a little bit worried about `SensorExtraStoredData` with `Decimal` but it all seems to work out from since it converts it before it gets to the json encoding cc @dgomes
If it turns out to be a problem we can disable this
with option |= [orjson.OPT_PASSTHROUGH_DATACLASS](https://github.com/ijl/orjson#opt_passthrough_dataclass) and it
will fallback to `as_dict`
Its quite impressive for history queries
<img width="1271" alt="Screen_Shot_2022-05-30_at_23_46_30" src="https://user-images.githubusercontent.com/663432/171145699-661ad9db-d91d-4b2d-9c1a-9d7866c03a73.png">
* use for views as well
* handle UnicodeEncodeError
* tweak
* DRY
* DRY
* not needed
* fix tests
* Update tests/components/http/test_view.py
* Update tests/components/http/test_view.py
* black
* templates
* Update the nest integration to be useable fully from the config flow
* Support discovery in nest config flow
* Remove configuration entries
* Remove unused import
* Remove dead code
* Update homeassistant/components/nest/strings.json
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Remove commented out code
* Use config flow for app auth reauthentication path
* Improves for re-auth for upgrading existing project and creds
* More dead code removal
* Apply suggestions from code review
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Remove outdated code
* Update homeassistant/components/nest/config_flow.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Reduce overhead to refire events
- asyncio timers can fire early for a varity of reasons including
poor clock resolution and performance. To solve this problem
we re-arm async_track_point_in_utc_time and try again later
when this happens.
- On some platforms this means the async_track_point_in_utc_time can
end up trying many times to prevent firing the timer early since as
soon as it rearms it fires again and this repeats until we reach
the appointed time. While there is not much we can do to prevent
asyncio from firing the timer callback early, we can reduce the
overhead when this happens by using avoiding creating datetime
objects
* tweak mocking
* -vvv
* fix time freeze being too broad in litterrobot
* adjust
* Refactor template entity to allow reuse
* Fix schema and default name
* Add tests
* Update requirements
* Improve test
* Tweak TemplateSensor initializer
* Drop attributes and availability from TemplateEntity
* Use rest sensor for proof of concept
* Revert changes in SNMP sensor
* Don't set _attr_should_poll in mixin class
* Update requirements
* Remove async_remove_listener
This avoids the ambuigity as to what happens if same callback is added multiple times.
* Keep track of a context for each listener
This allow a update coordinator to adapt what data to request on update from the backing service based on which entities are enabled.
* Clone list before calling callbacks
The callbacks can end up unregistering and modifying the dict while iterating.
* Only yield actual values
* Add a test for update context
* Factor out iteration of _listeners to helper
* Verify context is passed to coordinator
* Switch to Any as type instead of object
* Remove function which use was dropped earliers
The use was removed in 8bee25c938
* Add return code to integration application credentials in config flow
* Update google tests to use new return code
* Update spotify test for no auth configured
* Add translation for oauth2_missing_credentials
* Add new return code to yolink
* Update homeassistant/strings.json
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
Co-authored-by: Franck Nijhof <frenck@frenck.nl>
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
J. Nick Koston
Franck Nijhof
epenet
Allen Porter
Erik Montnemery
Marc Mueller
Raphaël Beamonte
Joakim Plate
Malte Franken
Paulus Schoutsen
Kevin Stillhammer
Allen Porter
