Hi there,
I tried to add a ton of new values regarding health to my templates.yaml and got stuck with the device.
I planned to add all the tempalte sensors to a device called “My Body” or something.
# config/templates.yaml
# Diese Datei wird von 'template: !include config/templates.yaml' geladen.
# Sie muss eine Liste von Template-Typen enthalten.
- sensor:
- name: "Nils' Gewicht"
unique_id: nils_gewicht_sensor
unit_of_measurement: "kg"
device_class: "weight"
state_class: "measurement"
state: "{{ states('input_number.nils_gewicht') | float(0) }}"
device:
name: "Körper von Nils"
identifiers: ["nils_body_metrics"]
manufacturer: "Personal Health"
model: "Human Body Metrics"
.....
But the yaml would not load.
I get:
Invalid config for 'template' at config/templates.yaml, line 12: 'device' is an invalid option for 'template', check: sensor->0->device
Why isn’t device not allowed for a template sensor?
Hi,
I cannout find the keyword device: there.
However, I had a lengthy discussion with chatGPT and gemini and both insist that device: should be possible.
If I create a template helper in the GUI I can select a device.
Can you say why?
So you believe the bullshit engines, over the official documentation…
LiQuid_cOOled linked you to the documentation that shows all the available YAML configuration variables for template entities, device is not in that list… ipso facto ChatGPT and Gemini are making stuff up.
Read carefully, I set up a template sensor via GUI and added it to a device.
Because I did not want to do that fifty million times I used the yaml way and created a lot of tempalte sensors like the above.
but device is not possible in the yaml way.
I was just wondering about that.
Both the AI engines you mentioned scrape data from old threads and provide you with a warm and fuzzy solution.
You will find out quickly that doesn’t work well with HA. Thus the feedback from multiple forum members including the moderator who manages the integration.
Hi,
I added those sensors to track weight etc. First try was to add them as input_numbers but those are not able to keep long time statistics.
So I switched to templates. I want to use my own because I track via a scale, a smartwatch and other devices. And I can transfer the values of their integrations to the template even after switching hardware.
First idea was to create a label (tag) or an area called “Body of Nils” “Body of Gwen” etc. But a device would be more suiting to the hirarchy: Home->Area->device->entity.
I remembered that I created lots of templates for my PV system and the spa and added it to the exisiting devices via the GUI, so my Idea was to create a device for each person to add those templates.
But since it is not possible via yaml I will fall back to another solution.
I understand that there is no perfect solution for rooms/areas etc. I read about the different opinions regarding levels and areaslike inside and outside with rooms as logical substructures and how each desired solution would lead into lots of problems and reorganizing.
We had our fair share of fuckups regarding rooms etc with the ioBroker project years ago. It’s not that simple after all, isn’t it?
Because the developers designed it to work that way.
Users have requested to allow assigning a device to a YAML-based Template entity but were told it’s not currently feasible (there was a similar request for assigning labels in YAML, with the same reason it can’t be done).
That’s why that ability isn’t described in the documentation; it’s not possible.
Because AI tools make inferences, they made the incorrect assumption that it is possible thereby misleading you.
It’s always best to rely on the official documentation. The general rule is if something is not explicitly mentioned, or there’s no example shown, then it’s not possible.
NOTE
The bad advice given to you by the AI tools is a modern example of the old adage “A little knowledge is a dangerous thing.” Without a firm understanding of the details, it offers advice based on guesswork.
Funny you mentioned labels via yaml. I also tried that to save time. But gladly one can select multiple entities and assign them all at once.
My desire to tinker around in the backend comes from 5 years ioBroker. I am absolutely not used to a uselful and good looking ui and a complete documentation.
I started using Home Assistant in 2018 (after over using other home automation software for over a decade). Configuration was predominantly in YAML. So I still prefer to configure things in YAML, largely because I can see multiple configurations at a time (by simply reading it in a text file).
Over the years, configuration has migrated to the UI. To be clear, the UI is where the information is captured but then it is stored in JSON format in hidden files. They’re hidden to help prevent users from editing the JSON data directly (a single editing mistake will cause Home Assistant to fail).
There’s an ongoing transition from YAML configuration to UI configuration, largely because it’s less of a learning curve for novices (don’t need to learn YAML) but perhaps more importantly because developers have more programmatic control over the hidden JSON data (distributed among many inter-related files).
One important thing you should know is that not all features available via YAML configuration are exposed via UI configuration. For example, the Automation Editor’s Visual mode doesn’t offer all of the features possible in YAML mode. Similarly, a Template Sensor helper (created via the UI) lacks some of the features available to a Template Sensor configured in YAML. In the case of a Trigger-based Template Sensor, you can (currently) only configure it in YAML
Why? The answer is a combination of:
It’s the first release of the UI-based version; more will come later (maybe)
Expose only enough features to be functional and not overwhelm novices
Lastly, don’t make the mistake I initially did and fail to make the distinction between YAML and Jinja2 (templates). They’re different languages with their own syntax and grammar.
if you haven’t already.