Though in theory the requests sounds logical, in practice it is untennable.
First of all, where it makes sense, it already happens at entity level. A light entity can have many other properties besides on/off incorporated, such as rgbw, brightness, etc. A thermostat has temperature, setpoint, modes, etc. Covers have state, position, tilt, … They all result in combined information in cards such as the tile card.
Devices on the other hand can have many, many entities. There is nothing standard about most of them, so trying to make some standard out of that that the UI can work with is next to impossible. Take my car. It has 5 window entities, 6 door entities, lock, battery state, odometer, climate, pre-heating, charging info, range. Good luck trying to put that into one card, taking into account that all car brands have different kinds of data.
It is part of why device automations are something to avoid over automations based on entities. Devices are just too different depending on brand, model, integration.
Speaking in OOP terms, I want there to be a device card that represents an object, not a class. If a class has multiple instances, let there be multiple cards. When entity has no device, it will be nice to create new device for it.
In practical terms, I think it would be down to integration developers to provide it. The nearest we have at the moment is probably the Sonos card from HACS, but there’s a clear use case there.
So use an auto-entities card that automatically adds all entities of a device in it, als call this card a device card. If an entity has no device, just explicitly name the entity inside the card. Anything more specific would be impossible due to the generic nature of devices.
And that’s a source of quite confusion for every new person (I guess OK. That was a source of confusion to me…).
I mean, when I tried HA for the first time, it was like chaos: integrations, addons, devices, entities, attributes, helpers…
I understand that entities are the core of HA. But that’s a source of confusion when you expose them to the end user. Because what do they represent? Really? How do you map them to the real world of your house?
For the end user, devices make sense. They represent a real world thing. Entity is like a part of the device, or its attribute. Oh, wait, entities have attributes… What for?
I know, legacy, backwards compatibility, blahblah.
Anyway, IMHO the devices are natural ways of thinking for a lot of people. If entities are the “meat” of HA, it can still be a “delivery mechanism” for the “interface” like a device. Same an integration, or helper, etc. But still: this is a “low level” stuff. Or at least should be. IMHO.
Most of the car users don’t care if the engine is 4 or 6 cylinder. Or that your steering assist is electrical or hydraulic. This is important, cars are made with particular technologies, like HA is made of particular parts; but as with cars, not all parts need/should be a first class citizens of the USER interface.
Take Zigbee for example. There are thousands of devices, with more coming out every day - nobody can keep track of them all. But they share a relatively small number of entity types, which they also have in common with devices using other protocols. This allows developers of integrations for motion sensors and… whatever… media players to create something that works as a whole - which is what Home Assistant is for. It integrates.
The Powers that Be have recently started pushing the concept of devices as a way of reducing confusion for newcomers, but I think they may come to regret it - it’s already causing a lot of problems.
And users have got to make some effort, for goodness sake!
I never mentioned cylinders as entities, because, gosh, my car doesn’t even have them. Which goes to prove cars are not as uniform as you thought they were. I also don’t care about fule levels, because there’s no fuel.
Your point was, make devices first class citizens in the UI. So how should the UI in your perspective show the car? How would HA let me interact with it? I definitely care if one of the windows is open, maybe less if it is the sunroof that I intentionally kept ajar.
The point I wanted to make is: How would the UI represent my car if HA does not even know it is a car, nor what each entity in it contributes to the whole. What assumptions would HA need to make about a car that do not fit the controls it actually provides?
You seem to know a thing or two about programming. So please come up with a reasonable number of UI components that would HA to interact on devices, in a way that all supported devices can make use of all their capabilities?
You probably won’t be able to, unless you break down complicated devices into smaller, well understood subparts. Lets call them, ehh, I don’t know, entities?
And this is the entire problem someone has to define what is ‘visible’
What I consider important is probably very different than what others consider important.
Someone would have to define what that visible UI would have to look like at the device level. - that I assume would be the manufacturers responsibility. We’ll we all know they will just say. We solved this already use my app. And now we’re back in a viscous loop exactly where we are now.
Specs like matter define what a device is in its definition and it helps. But that’s only ONE protocol. Across thousands. What do you do for something that pops up off a CAN bus discovery? Command line sensors random RESTful calls.
Its a lofty goal @DvdNwk but it’s simply unattainable. I’m quite impressed dev was even able to get it down to configuration or control entities in the first place.
Yep. Unless you want HA to be the “industry standard”. Then you solve things for the users, do something for them, instead of forcing them to learn your way
I myself can manage, I love the possibility of using YAML, I automate my Mac with REST calls to HA API. Etc.
But what about ANYBODY else in my circle of friends and family? NOBODY else but me will be able to do that (apart from my programmers friends ;)). That’s the fact. They will just not use HA, unless it is easy for them.
I’m not saying entities concept is the barrier, I’m just saying in general: every little step towards a simplicity for “normal people” is a good step.
AFAIK, entities were first, devices were added. My guess is they were added for a reason I’ve read voices stating that entity attributes are discouraged, that it is legacy.
My history knowledge may be wrong, my HA adventure started like a year ago, but I’m pretty sure there is a lot of legacy stuff laying around here. Not all is “by design”, and not all is up to the latest “design goals”.
Well, I think we have a misunderstanding here. I meant that the number of cylinders is a design detail. It makes all the difference in the car, but from the USER POV, it’s just a delivery mechanism that they don’t care (mostly) about.
They care about being able to drive, accelerate fast, break in short distance, etc.
If your car doesn’t have cylinders and I can drive it the same way as any other car (and I mostly can), then that proves my point: as the engine being a “low level detail” - and what matters is the UI stays on a higher level, usable by users.
Hmm, I think HA does understand “a car type of device”. Or at least the “lightbulb type of devices” I can act upon devices in automations. I can see devices in integrations. Devices group entities. That’s a good thing to me.
I’d encourage for more parts of HA’s interface to treat devices as first class citizens.
For example, when adding a new card in the Dashboard, we can search “by card” and “by entity” → I’d add “by device”. It could just show available cards for every entity of the device. That’s without changing anything in the HA’s model of doing things.
What about a card that can make use of multiple entities at the same time? It is common for me to create a stack card with a thermometer details: the temperature, humidity, LQI, battery status and temperature graph. Instead of me composing that manually, there could be a “Thermometer card”, where you select a thermometer device and it can populate the fields by the proper entities. We know which entity in the device is a battery right? We know which one is LQI, right? We know which one is the temperature… Or we can “guess” by the entity name. And we can let it be customizable of course in the “advanced” view.
I have a few ideas, each one can be discussed on its own thread, etc. But the main idea being: devices as first class citizens, entities as a “low level” implementation detail.
And this is the problem… In MY install I care about cylinder 6 and number 4. And how dare you - hiding that for me is disrespectful (yes that how end users react when you make these assumptions. I’ve been dealing with end user support for 25 years)
I get what you’re saying, but I get the feeling we’re are stuck on terms. You’d probably call a humidifier a device. In HA it is an entity. Same as a fan is an entity.
I have a device, the Dyson Pure Humidify and Cool, It is both a fan, humidifier and air quality meter. In the real world it is one device, in HA it is modeled as one device. It has entities for the fan and the humidifier.
Both have all kinds of controls relevant to humidifiers and fans. Have you looked at tiles, for example when used with a humidifier or fan entity I talked about? They provide one card for the entire fan. One card for the entire humidifier. So it is there. Even the light entities are compound, they can even have presets. Don’t just look at the old entity cards.
I think the entities often are what you mean by devices. But device in HA is a higher concept. In itself it is too complex because it is often multiple “devices” in one.
To see detailed information, user can alternatively click on control, to see more info. It is also possible to determine what is more necessary at the moment. For example, show battery only when little % left. If you imagine that this is a car, then it can display information only when one of the cylinders has failed. Also show EV charging current only when the vehicle is charging. In any case, it won’t be possible to do it universally, but this is just a variant of the card. Some people need to see everything, others only the priority. Even Android phones freeze apps which user don’t use. Therefore, if user does not press a rare button, for example, light indicator on the device, after 3 months it can be hidden on Lovelace card
No i get the concept of showing just in time info and only as much as necessary. I use it extensively - you’d be amazed what you can fit in one card using that concept.
But what I’m saying is you CANNOT make all of those decisions FOR the user without thier input.
SOMEONE has to spend time to build that uI. Someone has to parse the device types…and make a decision about ‘how do I show that.’
Who is to say that ‘engine’ means sensors attached to a car and therefore hide everything I dont deem ‘the engine warning light’.
If im Ford that’s fine. I know what the O2 sensor coming off the manifold means under condition x.
In my house you have no idea what it is. Engine might be the virtual enterprise engine room I build for my nephew (still trying to convince him SNW is worth his time) and the details are the blink lights and actuators to make it run…
(see recent ZWaveJS bug when they added a basic entity to a bunch of stuff accidentally - Short version similar concept)
Without user context you have no idea what something is beyond - this thing says it’s a light. We expose this for a light that supports these features…
HA dev already figures that part out at a domain level (ever notice the light control shows rgb if your light is capable? ) and that’s probably as far as they dare go without running into water with many sharks.
OK. That was a source of confusion to me…).
