As an average home assistant user I want more convenience while adding new devices so that I don’t need to learn anything about the Jinja templating engine if I just want to add common additional virtual sensor values.
Example 1: In our house every room has got a temperature and humidity sensor. An outdoor sensor exists as well. In the beginning one of my very first automations was to send a notification if the humidity raises above 60% so that we know when we should open the window. But when it is raining outside maybe that is not a clever notification. So I needed the absolute humidity values for comparison. Searching that topic I quickly found that others had the same question and the answer is do it yourself and look for template sensors. That was my first what the heck experience.
Many intergrations comes with additional sensor values like “signal strength”, which are hidden by default. So when it comes to temperature and humidity devices why can I not have a virtual sensor caluculated by the integration already. This could be hidden by default as well but can be easily activated like the signal strength today with a click.
Example 2: We own a body scale. But the sensor adds the weight and the pulse only. I was looking for common additional sensors values like the body-mass-index as this is a very basic information and typically provided by every smart scale. In the forums you quickly find solutions and again template you own sensor. That was another what the heck moment.
There are already profiles in Home Assistant. And maybe this is a larger concept but why could these personas don’t have additional values like body height. So that the BMI can be easily calculated from the weight and height by the integration. Again, hide that virtual sensor by default as this is maybe not needed by everyone but you have the “choice” to use that additional sensor. (This is for sure offtopic and another WTH but people have devices like smart phones and watches which counts daily steps and such which could be bound to the persona as well. Blood presure devices could add data as well. And so on. In the end we could have not only a great energy dashboard but a “persona dashboard” of the inhabitants of the samrt home to track their well being like we do for example for batteries as well… in the end it is all one and the same. If it can be tracked in Home Assistant it will be tracked in Home Assistant.)
Maybe there are more examples to this “WTH moment” in other areas of additional virtual sensors. I like that Home Assistant is as flexible as a Swiss Army Knife but for an average user this is very frustating in the beginning and templating your own sensor is a steep learning curve. So if possible, there should be common virtual sensors suggested for different device classes and over time integrations fills these gaps so that the overall user experience is increased greatly for every Home Assistant user.
I guess that is my point in this WTH. And apologize for the “wall of text”.
The Home Assistant user experience for new users is not that great when it comes to additional virtual sensor values and template sensors. I’ve solved that long time ago. I’m fine. But if you go and buy a smart device there is sometimes more convienence with the original manufaturs app and in the first glance it seems to be more powerful while under the hood the additional things are simply calculated from the other values. When there is an integration in Home Assistant sometimes you only have the bare minimal sensor values and than you need to live of the land.
But it would be simple in my humble opinion to increase the user experience when some device classes provide such common virtual sensors, even if they are deactivated by default. Lay the foundation in the developer guidelines for something like this and over time the integrations will pick this up and the user experience would increase greatly, especially for new users but also for advanced users who got lazy…
PS: Thank you for the “Thermal Comfort” sensor link. I like that and at the same time I didn’t know about that… what the heck
Understood. I just wanted to share my experience over the last years and where I think that Home Assistant could be improved for new users. I even register to the forums for that case. I read the forums but without an account and search solution for my problems and always found several threads for my problem. So there was never a reason to register.
It’s more of a concept than a requests for a specific integration where I kindly ask that a absolute humidity sensor would be added to the “Switchbot Meter (Plus/Pro)” or such. That was just an example where my past would have saved a lot of time.
Something much more general as in “An integration for a device measuring temperature and relative humidity should provide a sensor for the absolute humidity”.
I don’t see how you could implement this. My humidity sensors are just that. Sensors. The integration they use is ZHA, which deals only with the communication and should not be weighed down with tons of code to calculate a zillion possible valuesffor every Zigbee sensor on the planet. Let alone that you need additional information to calculate this value (temperature in this case) , which may not even be provided by the same integration.
The way I do it (and am happy to share) are a bunch of cutstom_template macros which provide me with some general conversion (of which 2 are RH to AH and vice-versa.
Maybe I was using the wrong terms. Dunno. But I also don’t see this in an integrations like ZHA. I agree that this does not make sense at all. Also, when an device only provides a relative humidity sensor than the absolute humidity could not be calculated without the temperature. If these values are provided from different devices, than you need to do this yourself.
But when a single device measuring temperature and relative humidity why should it not provide a “virtual” sensor for the absolute humidity as well. I personally would consider this as a common use case for such a device and every new Home Assistant user would run into an issue at this point… (most don’t care about absolute humidity at all, so I would hide them like the signal strength is hidden).
Thank you. And again, my WTH is not the “how” (I solved that already) but the question “why” a new Home Assistant user needs to learn all that for the sake to have a virtual sensor, like for example an absolute humidity sensor, which could be provided by default.
(I’m not against learning opportunities. Don’t get me wrong. But in the beginning of everyone Home Assistant journey that could increasing the frustation level)
That could be handy. But it’s not for HA, it’s for the integration. Because a device might supply data but how should the HA developers know how they are related, in a general way, not knowing anything in advance about the device that supplies it? Maybe your device has 3 temperature readings and 2 humidities. Or one of each but they are not taken in the same location.
Furthermore, there are so many derivative quantities that could be calculated, it’s hard to say which ones to choose and too much to do them all.
That’s why there is a system where any user can make any sensor out of combinations of data. Template sensors is that system.
Now, I do think it would be useful if there was a ‘blueprints’ system for template sensors, so users who don’t code can access this system more easily. But building the calculation of a couple of random template sensors into HA core doesn’t sound like a good idea to me.
@peki75 - how about something slightly different?
What if there were blueprints, but for derived sensors?
How about if H-A shipped with some ‘standard’ blueprints for derived sensors?
Things that are either common, or are needed to utilize core HA functionality.
Energy usage from power
Absolute humidity from temp/relative humidity
AQI from particulate sensors (and whatever else is required.)
???
What if those derived sensor blueprints could be used directly from a device page?
Preferably it would only show the blueprints for ones that the current device has all required sensors.
Alt; when creating from the device page, only sensors from the current device could be used to populate the blueprint.
Solves the discoverability issue, eases creation for ones needed to do things like track energy usage, and prevents the “wrong” sensor from being used if a device has multiple sensors of the same type with different meaning.
Keep in mind that Template Blueprints were recently added in 2024.11. Currently they are YAML only, so they aren’t super friendly for new users; but I’m sure the goal is to make them available in the UI like their script and automation counterparts. Like those other blueprints, they will let newer users leverage the templating knowledge of more experienced users without learning any Jinja.
Can’t help but feel that even if they can eventually be created via the UI, there’ll be a future WTH lamenting how difficult it is for new users to install a blueprint. It’s turtles all the way down …
I guess I go with Tom’s suggestion and this is something for the documentation in the first place. That could then maybe help someone like me in the past, looking to solve some more advanced problems.
