Paulus Schoutsen
Paulus Schoutsen
I think what it is trying to achieve is that we sometimes see integrations that use async methods and use that to wrap sync calls, instead of going through our...
The original plan was to have it be phased out and no longer be added to new APIs, and have all new contributions be done in async. However, I think...
State attribute translations will be provided as part of https://github.com/home-assistant/core/issues/34264#
Oh that is an interesting thought. So we would scaffold 4 automations that the user can adjust afterwards. I think that I would slightly prefer to use interfaces, but offer...
Ah, in that case, we could even have `async_attach_interface` just return device automation config. That way `interface_integration` can convert it when the user wants to.
Users can control their brightness of the lights themselves via the normal controls. Using entities is out of scope for this. The goal is to be able to offer something...
I've been thinking about this a bit more. Two thoughts: ## Producers and Consumers For each interface there will be: - producers: devices that generate the events - consumers: devices...
I think that blueprints are a step towards this goal but not a full solution. The problem with blueprints is that we still expect users to find the blueprint for...
If only one signal is sent, shouldn't they be events?
I agree with this issue. All features need to be provided by the actual API of the devices or need to be provided by either the entity integration (light, sensor...