Comments (6)
Background:
- the attribute describes other attributes and not the state
- we can use core.unit_system.temperature instead
from architecture.
I agree, we should only add unit_of_measurement
if it describes the state and the state is numeric.
from architecture.
This is relevant to the Cooker Entity too, as it includes a unit_of_measurement.
I always assumed that unit_of_measurement was meant to tell which unit systems the device/sensor is reporting in. core.unit_system.temperature is for describing which units the user selected in their configuration.yaml, right?
This means that they are 2 different things, and they can vary independently. There are 4 states to be accounted for here if you are considering combinations of F and C. Some thermostats (and cookers) allow adjusting their measurement unit independently of HA, so unfortunately we could never escape this situation entirely.
I do agree with @c727 that the frontend should just use core.unit_system.temperature. After all, that is what the user chose!
However, internally it seems the platform would need a unit_of_measurement. Systems like Google Assistant and Alexa need that unit, because their incoming data is always in Celsius. If we don't know what unit to convert to, things will break.
We can change the climate/cooker to always report their temperatures in Celsius, which solves this problem, but we will then need to do a conversion in the frontend and (potentially) internally to each platform.
So, I think that unit_of_measurement has a real purpose and we can't eliminate it entirely. However it would still be possible to remove it from the frontend and the state if we want (just keep it internal to the platform).
from architecture.
Entities will convert their state values into the temperature unit used by core. This is currently done in the Entity base class but should be moved to a Sensor base class.
All entities should be written to the state machine in the unit that is the preference of the user.
from architecture.
I see, so:
- If the state is numeric then the platform should export unit_of_measurement and entity will auto-convert. This should be moved to sensor component.
- For climate and cooker, which store temperature as attributes, they should not export unit_of_measurement and instead just write their attributes as the user's preferred unit.
- Input from external systems like Google and Alexa should be converted from Celsius to the user's preferred unit.
- Input from the physical device should be converted internally and stored as the user's preferred unit.
from architecture.
All yes except for 3, as that is already happening.
from architecture.
Related Issues (20)
- Splitting tests files in smaller files in components/modules tests HOT 1
- Feature Request HOT 1
- Add favorite position to Cover entity HOT 10
- Add feature light distribution control to LightEntity
- Add new CURRENT_HVAC constants HOT 1
- Add Home Appliance entity
- Officially allow enities to set their entity ID not based on their names HOT 2
- Custom Device Class for Binary Sensors HOT 9
- Installed homeassistant supervised on my Linux machine; can't get it to run. HOT 1
- Expand enqueue options media player HOT 2
- Extend Rest API - unique_id HOT 3
- Add "status" as an attribute to CalendarEvents HOT 5
- Add list of (upcoming) calendar events to templating HOT 1
- Creating automations on the fly HOT 1
- Optional health check HOT 2
- Open letter for improving Home Assistant's Authentication system HOT 7
- Add device_class Heater HOT 2
- Area Units HOT 3
- New Device class for Reactive Energy (varh) HOT 1
- "Lost" device HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from architecture.