Comments (3)
- For some platforms 2. makes sense. For example
speedtest
has a common data object that does the periodic speed testing, but it can output multiple sensors:
- platform: speedtest
minute:
- 0
- 15
- 30
- 45
monitored_conditions:
- ping
- download
- upload
Combining this into a separate platform
entry would be very cumbersome
- Somewhat like my first comment: Platforms with shared configuration benefit from 2. For example, in WUnderground:
- platform: wunderground
api_key: !secret wunderground_api_key
monitored_conditions:
- weather
- weather_1d_metric
- ...
This list can contain lots of monitored conditions and I seriously wouldn't want to type platform: wunderground \ api_key: !secret wunderground_api_key
for every single one of them.
-
\1. makes more sense when the individual sensors/... are separate and don't control each other. As a user, if I see
sensors:
in the Template Sensor, I assume that I can't use multipleplatform:
directives or else something will break. -
\1. allows for much better separation in config files. For example, I can have all my "livingroom" entities grouped under the comment "livingroom" and don't have to navigate between file positions all the time. Of course multiple
platform:
directives are technically allowed, but then the previous comment comes into play again. -
\1. saves on indentation: Especially in the Template Sensor platform, where lines can get pretty long, having 4 more characters per line is gold 💯.
-
In 2.
sensor_entity_id:
is very misleading: It is not your entity_id. For example, if I typewohnzimmer_heizkörpertemperatur
as key, the "ö" will get converted into an "o". While the current way of having the friendly name control the entity_id so closely isn't perfect IMHO, having a standardized way that you can rely on is important. Edit: Same with lower+uppercase
from architecture.
I think that both have their purpose.
I think for template ones, I would probably have prefered if we defined 1 entity per config. No reason to cramp it all together because they are not related.
The first one is related because it's based on, for example, a location that is passed in.
The need to define entity IDs or names should not be added to platforms or components anymore. That can now be done via the entity registry.
from architecture.
For core site: it doesn't matters. Since we have change add_devices
callback too none blocking, there is no speed benefit. For the yaml parser I don't know.
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.