I would like to display devices in Lovelace, and to automatically show beautiful entities for such devices. Very often, for example when turning an outlet on and off, you want to see the energy consumption. Also, the weather (humidity, temperature, air pollution) is not grouped nicely enough in Lovelace. Also, it is difficult to see battery percentage in conjunction with the entities in Lovelace. I agree that not all auxiliary things that devices have should be displayed in Lovelace, but the user must decide for himself what to display.
Which you can easily do when you create the cards, especially if you use custom cards to include multiple entities in a row etc.
Well, not really, cards are too big, and my tablet is too small
Soooo, what exactly are you hoping for? Cards are how ALL of the dashboard is createdā¦
This is small:
Pretty nice. Is it the standard tile card? Do you mind sharing your code?
The default dashboard already only shows cards for controls and auto hides configuration entities. As far as āhiding the not beautiful entitiesā thatās probably as far as dev can go. They donāt have any idea what your device does - so randomly making decisions on what to show /hide without some schema to follow is practically impossible. At best theyād get yelled at for being wrong m the time. Example see recent strife on default icon choices, colors or thermostat controls.
Edits to defaults are no win situations. Someone always hates the choice.
But beyond that the default auto dashboard becomes pretty much useless once you have more than 20 devices IMHO.
At that point youāre building your own dashboard anyway. Put on it what you want to see not what someone else wants you to see.
2 Likes
The FR makes sense to me. It happens every time I add a new device ā figuring out how to display it to see any basic info ā even temporarily, until I decide / start experimenting how to improve it.
Cool, but thatās like the first thing everybody turns off when they want any kind of customization.
Actually, youāve just prompted me to create a new ādefaultā dashboard, as an extra to my customized dashboard, and I think it will stay, thx 
Sure, but thatās no excuse to having NO defaults. Itās better to have any defaults than none.
I would give the choice to the dev implementing the device itself. Optional config option, so that it stays backwards compatible.
Or just stick with what the ādefault dashboardā is doing.
Actually, thermostat controls is a great example why it is needed. Itās useful, beautiful, automatic.
My understanding is that it is based on an entity with attributes, not on a device ā but thatās a technicality that I wouldnāt want to explain to my nonāITāeducated family/friends, to whom Iād like to recommend using HA.
Anyway, it looks and behaves like a ādevice cardā. Thatās the goal. Thatās great, and if somebody doesnāt like it, they can customize it however they want anyway.
Itās using Mushroom Template card and Custom Stack in Card.
type: custom:stack-in-card
cards:
- type: custom:mushroom-template-card
primary: HA Server
secondary: 'Uptime: {{ states(''sensor.ha_uptime_phrase'') }}'
icon: mdi:server-network
tap_action: none
icon_color: |
{% if states('sensor.cpu_temperature') | int > 80 %}
red
{% elif states('sensor.cpu_temperature') | int > 70 %}
orange
{% elif states('sensor.cpu_temperature') | int > 60 %}
yellow
{% else %}
green
{% endif %}
- type: custom:mushroom-chips-card
chips:
- type: template
entity: sensor.cpu_temperature
content: '{{ states(entity) }} Ā°C'
icon: mdi:thermometer
icon_color: |
{% if states('sensor.cpu_temperature') | int > 80 %}
red
{% elif states('sensor.cpu_temperature') | int > 70 %}
orange
{% elif states('sensor.cpu_temperature') | int > 60 %}
yellow
{% else %}
green
{% endif %}
tap_action: none
- type: template
entity: sensor.processor_use
content: '{{ states(entity) }} %'
icon_color: |
{% if states('sensor.processor_use') | int > 80 %}
red
{% elif states('sensor.processor_use') | int > 70 %}
orange
{% elif states('sensor.processor_use') | int > 60 %}
yellow
{% else %}
green
{% endif %}
tap_action: none
icon: mdi:cpu-64-bit
- type: template
entity: sensor.memory_use_percent
content: '{{ states(entity) }} %'
icon: mdi:memory
icon_color: |
{% if states('sensor.memory_use_percent') | int > 80 %}
red
{% elif states('sensor.memory_use_percent') | int > 70 %}
orange
{% elif states('sensor.memory_use_percent') | int > 60 %}
yellow
{% else %}
green
{% endif %}
tap_action: none
- type: template
entity: sensor.disk_use_percent
content: '{{ states(entity) }} %'
icon: mdi:harddisk
icon_color: |
{% if states('sensor.disk_use_percent') | int > 80 %}
red
{% elif states('sensor.disk_use_percent') | int > 70 %}
orange
{% elif states('sensor.disk_use_percent') | int > 60 %}
yellow
{% else %}
green
{% endif %}
tap_action: none
- type: entity
entity: sensor.db_size
alignment: end
state_color: false
1 Like
As a dashboard feature? Erā¦ How? There are thousands of them (Z2M have nearly 4,000 in their database alone) - who is going to compile the list?
HA works with entities, not devices. Thereās nothing to stop you using picture element/entity/glance cards in your dashboards, with images of your devices and entity icons.
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.
2 Likes
And some entities donāt belong to devicesā¦ 
1 Like
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.
I canāt see a ārethinkā ever happening. Itās just not how HA works.
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.
1 Like
Somebody posted about that this morning:
2 Likes
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.
When I started with HA some 5 years ago, devices did not exist, only entities. Iām still used to thinking in entities first 
2 Likes
Well noā¦ Design.
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! 
1 Like
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?
2 Likes
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.
1 Like