I’m not sure what you mean with the statistics of the devices. If you mean the recorder data, that is only in regards to entities not devices. Merging the devices will simply move all entities from one device to another and disable the entity-less device. This process will not change anything about the entities and recorder data should therefore be kept.
This looks encouraging - go give it a thumbs up 
1 Like
Ability to add text (static custom attributes), number (static custom attributes); link media (e.g. for device pictures or custom icons) or calendar to a specific device would be great. This is a semantic grouping thing
1 Like
Not necessarily. Some issues are being investigated.
What issue lead to the note about YAML configuration support being removed ? I looked over the PRs but didn’t manage to find the change.
The support for yaml never existed. That was the issue that was being investigated. It was an error in the PR description that made it’s way to the beta release notes. So the release notes were corrected to signify that it’s UI only.
Well, nutz! I was looking forward to employing this feature but all of my Template entities are defined in YAML.
Template helpers don’t currently support all available options (for example, a Template Binary Sensor helper only supports three out of about a dozen options) and are limited to sensor and binary_sensor (no support for trigger-based either) so that’s why I continue to define them in YAML.
Anyways, hopefully Template helpers will eventually be fully fleshed out so I can migrate and take advantage of this new feature.
FWIW, it’s a bit surprising that an advanced feature like appending a Template Binary Sensor to an existing device is introduced to the least feature-complete variation (i.e. helper). In contrast, it’s already possible to assign an MQTT entity to an existing device using YAML.
3 Likes
Would like to see/have it for YAML entities as well. Esp. there.
In the current Home Assistant structure, it is possible to create or link a device with just one config entry. Template entities created via YAML do not have a configuration entry.
So it is not an option not to extend it to entities via YAML config, the developers were willing, but it is not compatible.
What does the MQTT integration do differently so that it allows appending MQTT entities to an existing MQTT device, all in YAML?
Is it because it is limited to appending to an MQTT-based device and not a device based on other integrations?
Correct me if I’m wrong, but MQTT integration has a configuration entry (connection to the broker). Only entities are configured via YAML.
That sounds correct to me. The MQTT integration is responsible for handling publish/subscribe and needs to be present to allow MQTT entities (sensor, binary_sensor, lock, etc) to work. The MQTT integration is installed via the UI.
However, when configuring an MQTT entity in YAML, if it is referencing the MQTT integration’s config entry, then that’s transparent to the user. Each MQTT entity is free to define its own device or be part of another device.
Anyways if you feel it’s not possible then so be it. I will have to wait until Template Sensor/Binary Sensor helpers get feature parity with their more capable YAML cousins (before I can migrate what I have). Currently they only support a fraction of the available options (and don’t support the Trigger-based variety at all).
1 Like
What do you mean exactly? Really would like to understand.
Template entities have config entires as well ofc.
core.entity_registry
{“aliases”:,“area_id”:“ha_steuerung”,“categories”:{},“capabilities”:null,“config_entry_id”:null,“device_class”:null,“device_id”:null,“disabled_by”:null,“entity_category”:null,“entity_id”:“sensor.foo_bar”,“hidden_by”:null,“icon”:null,“id”:“ididid”,“has_entity_name”:false,“labels”:,“name”:null,“options”:{“conversation”:{“should_expose”:false},“cloud.alexa”:{“should_expose”:false},“cloud.google_assistant”:{“should_expose”:false}},“original_device_class”:null,“original_icon”:“mdi:toggle-switch”,“original_name”:“foo bar”,“platform”:“template”,“supported_features”:0,“translation_key”:null,“unique_id”:“unique_id_template_sensor_unix_tag_gerade_oder_ungerade”,“previous_unique_id”:null,“unit_of_measurement”:null},
Without this is shouldn’t be possible to assigne categories, areas, exposure to voice, … And exactly there is the link to devices as well: device_id
Template helper entities configured via YAML are not linked to a config entry.
What you mention is an entity registry (core.entity_registry file) and not a config entry (core.config_entries file).
The fact is that the current structure of Home Assistant makes it unfeasible to link devices to template helpers configured via YAML. Can this change? It can, but it is very unlikely that they will make such a complex and structural change to meet such a specific use case.
None of the assigned entities have an entry in core.config_entries file either so I don’t get the explanation or don’t see the tree in the woods.
Those have entries in core.entity_registry only as well and assigned by mentioned device_id. Same as exposure is done (via should_expose) or areas assigned via area_id, …
I would bet if a reload of the template would not clear the device_id, a set device_id to an existing device_id would bring it to the device on the UI, wouldn’t it?
It wouldn’t work, a configuration entry is still required for it to work.
this still only doable via helpers?
all my templates are defined in yaml and I’d like to associate those to existing devices (similar to the new helper way…)
UI only.
is there an existing feature request we can vote on to extend to YAML? a device_id property or something would be wonderful