So, about the new automation editor.
In theory, I love the idea of being able to tell an automation to target the temperature of an area, or a floor, and then not worry about the details. And even more so when it comes to letting AI help me out, here.
In practice, though, on my system, it becomes a recipe for error, because not every sensor of a given type is providing definitive, or even useful, information for the room.
I'll give you an example: if I pick "Living Room" as the target for a "Temperature crossed threshold" automation, I get seven entities with it. One of them is the living room temperature as it should be. I also get raw sensor data that it's based on but which shouldn't be treated as definitive, sensors that are excluded from my existing computation because they're insufficiently reliable (the AC temp sensor that's halfway out the window; an Echo in a warm spot because it's around other electronics), computed values for heat index and dew point and frost point which aren't the room temperature at all, etc.
If you have a complex setup, you really need to be able to designate (in the area configuration, for preference) which sensors for an area (of a given type) are the ones which give definitive information for that area and so should be included in area/floor targets. Not just for ease of defining new automations, but just to make screwing them up less easy to accident your way into.)
(I had hoped the "related sensors" section of the area configuration might do this job for temperature and humidity, at least, but it seems to be ignored in this context.)
Thank you, Can you please create an issue against HA frontend showing those 2 screenshots?
That why Labels are so great.... they can be targets too.
Yes, will do but I really dont know what ha frontend is 
Oh, yeah, I use labels quite a bit these days.
But still, if you want this feature to be easy, intuitive, AI-friendly and non-fragile, which is how I read its description in the blog post, you'll want to make it easy to configure the default case to not break, yeah?
There is no default case though, it's however the user starts to add the trigger. Area's just happen to be at the top collapsed the first time you enter that window, but the user can expand each area and select individual devices or entities.
When I assign a templated device tracker helper to a device, it appears there as a diagnostic sensor.
Is that supposed to happen?
Yes, they are diagnostic entities.
Well, yes, if you know the details of exactly what you need already, you can. That's fine for me, system administrator and part-time Home Assistant wrangler. But the way I read this blog post is that the intent is to make things simpler for people who aren't:
An automation engine thinks in primitives. People donât. You think âwhen the front door opensâ, âwhen the last person leavesâ, or âwhen a battery runs lowâ.
The old path started somewhere else, with Home Assistantâs internals. Which entity? Which state? Does it become
on,detected,home, ornot_home? Do I need a state trigger, a numeric state trigger, a device trigger, or a system event? If you know Home Assistant well, those questions are second nature. If you donât, they are the wall you hit before you even start.The new triggers and conditions speak the language of the thing you care about. When the bedroom drops below 18°C, turn on the heating. You donât think about numeric state triggers, attributes, or units. You pick Temperature crossed threshold and say what matters.
and this is where the problem lies. Because it seems from this post that it should be possible for my wife, who is not an expert in Home Assistant or how exactly our particular instance is set up, to set up one of those automations in "the language of the thing she cares about" without reference to my Big Handbook Of Exactly How Everything Works Underneath to find out that she needs to specifically reference my handcrafted sensor.magic_areas_aggregates_bedroom_aggregate_temperature or maybe sensor.thermostat_average_temperature entities because targeting "Area: Bedroom" will do exactly the Wrong Thing.
And I want that to work. That'd be great.
But at the moment, that breaks horribly because the area can't be told that for its temperature, it needs to look here and here, and not just assume that every temperature-class entity in it relates to the current temperature of the entire area.
I think you're over complicating this a bit much. This is the default view. (ignore my crappy theme)
Do you think expanding an area to select a device is complicated?
Mind you, you can just search for the device and go from there too:
when clicked brings you here
For me, no. But I'm not concerned about my usage; I built the system.
For anyone else, though, there are 56 devices in my living room. Six of those have temperature entities attached to them, only one of which will produce the desired result for someone who wants to set up something as simple as "when the temperature in the living room exceeds this, turn on my fan". Looking at it from the device-first search, they have to have learned and somehow remembered that Magic Areas, and not the possible-looking Smart Thermostat, Living Room AC, or Thermal Comfort Living Room is the one to pick.
Sure, this is me-friendly, but HA always has been. What it isn't is family-friendly or not-HA-grognard-friendly, which is what I interpret the intent of this feature to be.
The UI works for most use cases, I think 56 devices in a single area is a bit much and shouldn't be considered the "go to system" to build a UI against.
If I had six devices in my living room and they happened to be the ones with five incorrect temperature entities attached to them, it would still be an accident waiting to happen for anyone without my underlying knowledge of the instance implementation.
If someone has two devices in their living room which report temperatures, one of which is a thermostat which gives accurate readings and one of which is a window AC unit which, like mine, is routinely ten degrees off, their temperature-based automations are going to fail if they assume that they can set up their automations in the exact manner described in this blog post.
This is a problem for, again, people unlike me.
That's going to be challenging for anyone if they don't know what the 6 devices are. I really don't think it's as big of a deal as you're making it out to be. Anyone who set up 6 devices in an area is likely going to know what and where those 6 devices are based on the names they set up.
My partner has created automations (I end up cleaning them up), however all I needed to say was "This device is called xyz" when they asked. Because we don't think alike in regards to naming.
And, again, I am talking about how this feature should work for the people in the household who didn't do the setup.
I, as the guy who did do the setup, should be able to configure things to make life easy for the people who didn't do the setup to use the system when I'm not there - without needing to learn everything I know about the internals - shouldn't I? I don't understand how this is an unreasonable ask.
If you name your light switch mayonnaise, how is any UI going to help that situation? This is the point I'm bringing up. If you don't know the areas or devices that someone else set up, no UI is going to overcome that. It is an unreasonable ask.
The current UI is area name, device name, entity name, label name driven. If you don't know the names because you did not set it up, then it's going to be a challenge regardless how the UI presents the information.
Anyways, my opinion doesn't really matter in the long run. So it's just a moot point. Lets let others have the floor.
Firstly, that's an absurdity and I have to assume that you know that.
Secondly, that's not even related to the original ask, which was not even slightly related to device naming. It was about providing a mechanism to ensure that triggers, etc., which reference an area or a floor, not a specific device, as described in the above blog post, are using data which is actually representative of the area/floor they picked.
Given the number of integrations which create temperature (as an example) entities which aren't representative of the area the device happens to be in[1], assuming that they are whenever someone naĂŻvely picks "Area: Bedroom" without looking further, as they're being told they can and should do, is handing out footguns to newbies.
Anyway. I'm done here.
Why, yes, please include my 3D printer nozzle temperature in this automation! âŠď¸