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.
