Penny Wood

They copy the context of the creating thread or task. The only real issue is when you create a thread from a task or thread, then the var is unset....

OK so this is going to be much more viable once we don't have to back-port context vars as per #167. contextvars are still a 3.7 feature however, and since...

@balloob Is this something worth considering? Otherwise it's very old and can be closed.

The main issue I can see with doing this is going to be managing requirements. We'd have to check that any requirements specified in the manifest by more than one...

Looking at the different addon types there, it's worth contemplating how lovelace addons and custom cards etc will fit in to the greater scheme of things. After all, a custom...

@iantrich yes of course, what I'm implying here is that ideally it would be good if they could be packaged the same way as components and downloaded from an add-on...

@ottowinter There's a template sensor documented in the docs [that does this already](https://www.home-assistant.io/components/binary_sensor.template/) ```yaml # Example configuration.yaml entry binary_sensor: - platform: template sensors: sun_up: friendly_name: "Sun is up" value_template: >-...

> I would fully support adding more conditions throughout the code base The main ones really are `sensor.solar_elevation`, `sensor.solar_rising`, and `sensor.solar_azimuth`. There's a whole heap you could have, many of...

Either way really :grin:, it's the same set. > Quite recently I've seen some people complain about huge DBs because the sun entity is generating tons of events. Got a...

Here's a link to the PR that at least turns down the sun.sun device's events: home-assistant/home-assistant#23832