* Speed up generation of template states
* tweak
* cache
* cache hash
* weaken
* Revert "weaken"
This reverts commit 4856f50080.
* lower cache size as it tends to be the same ones over and over
* lower cache size as it tends to be the same ones over and over
* lower cache size as it tends to be the same ones over and over
* cover
* Update homeassistant/helpers/template.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* id reuse is possible
* account for iterting all sensors
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
- 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
* feat: make this variable available in template entities
This makes the variable `this` available in template entities.
It will simplify the use of self-referencing template entities.
Because, without this, we have to repeat the entity id every time.
If we can solve this without explicitly spelling the entity id,
code can be re-used much better.
As a side-effect, this will allow to use `variables`-like patterns,
where attributes can be used as variables to calculate subsequent attributes or state.
Example:
```yaml
template:
sensor:
- name: test
state: "{{ this.attributes.test }}"
# not: "{{ state_attr('sensor.test', 'test' }}"
attributes:
test: "{{ now() }}"
```
* expose entity_id instead of this
* add test
* Refactor to expose this variable
* Tweak repr dunder
Co-authored-by: Erik <erik@montnemery.com>
Petro31
Franck Nijhof
ehendrix23
Rami Mosleh
J. Nick Koston
Joakim Sørensen
Marc Mueller
[pʲɵs]
Raphaël Beamonte
Kevin Stillhammer
Erik Montnemery
akloeckner
Paulus Schoutsen
avee87
Ruslan Sayfutdinov
Brynley McDonald
Jan Bouwhuis
Marcel van der Veldt
Chris Browet
Raman Gupta
