Thanks, Petro; I’ve circled in red the things I hid for various reasons.
I didn’t see these before, but removing the hide_entity seems to coincide with them coming back.
click the 3 dots like I said and remove it. It does not remove it from the your system only that card.
This is what I was referring to when I said ‘take control’.
- Click 3 dots in upper right corner.
- Click configure UI.
- Select the card’s edit button where you want to remove the item.
- Delete the item.
Again, You aren’t deleting the item from you system, only the interface.
Also, keep in mind. From this point forward you have to add all the items you want to the interface. You must be currently in ‘auto generate’ mode. When you configure the UI for the first time, it switches you from ‘auto generate’ to normal configuration mode. Everytime you want a new card/entity, you have to add it yourself.
Do yourself a favor and read the lovelace documentation and watch the video. Everything through the UI is pretty self explanatory at that point.
Also you can play around with the demo interface, it’s where I took the screenshots.
1 Like
I appreciate the actual links to further reading; researching those and sharing it is awesome.
“GitOps” is the mentality that everything you’re using starts from source control, is pushed to the service that needs it, and that service has no config that didn’t come from source control. Everything running is deliberately sourced from a repository that can be rolled back or verified if something goes sideways. It’s how we consistently launch services at massive scale like FB, Apple, Google, Indeed, etc. It becomes a habit, but it’s the opposite of clicking on a UI (because that’s not generated from source control). In Hass terms, the HomeAssistant config would be regenerated on a clean system with a configured git_pull.
Do these UI changes result in config files built that represent the resulting dialog boxes? I see “show code editor” but I’m not sure where that yaml gets inserted.
The files that hold these changes are hidden but present inside your config folder. You’ll need to be able to view hidden files on whatever computer you are using. The are located in config\.storage. There’s tons of files, edit them at your own risk. All the files are json and they are not meant to be edited by a human.
If you want to use configuration files to configure lovelace, move to lovelace yaml mode.
In regards to all your comments about git and pulling / pushing. drop that from your mind. This software is trying to reach out to users who don’t code. They do not understand git, nor should they need to. Therefore none of this relates to git at all.
Maybe those users who don’t code will build the next addon or integration? :-/
1 Like
Not everyone wants to contribute. They only want to use the product.
When I say drop this from your mind, i’m referring to your use of home assistant. Not deployment of add-on or integrations. That should be 100% separate from your configuration.
For example, when I develop, I use my developmentbox set up in a virtual env. All those changes are managed through git but its 100% separate from my working configuration.
My actual configuration that runs my house is on a NUC where daily snapshots are performed. The snapshots contain the entire configuration and everything configured through the UI. Separate from that I maintain a git repository that stores my configuration history with pushes and pulls. This does not include changes done through the UI, it only includes changes made to .yaml configurations.
Thanks @petro
It only includes changes made to .yaml configurations.
Maybe you’ll not run into problems where reverting the config doesn’t need you to revert the UI steps at the same time. I’ve been coding 38 years; it’s happened more frequently recently.
FWIW, the automatic recording of config from switches was a more common thing before. “rancid” (“Really Awesome New Cisco confIg Differ”) was this cruft of “don’t read it but it works” scripts to collect changes in config and commit them to a repo. You might find it useful for that workflow if it’s still out there.
Thanks for the help. You’re generous to give your time for others.
1 Like
That’s what the snapshots are for. They backup everything.
While I appreciate that I can “take control”, I kinda like that the system automatically adds things. Initial integrations are easy and nothing ever gets lost.
It’s unfortunate that there is no longer the ability to remove from the UI those things that were automatically added. (The UI quickly gets cluttered without it.) That’s the best of both worlds.
– Brian
1 Like
I too want to stay with the auto generated Dashboard but need to be able to hide duplicate entities. I don’t understand why they took the capability away to delete them from thenUI!
2 Likes
Likewise. Being unable to hide redundant or superfluous entities, without forever preventing new devices being added automatically to the UI in the future, is a harsh penalty.
I have a set of z-wave wall switches that control the lights in my home.
For better integration, I’m using the light platform to announce to Home Assistant that they are lights.
Because of this, there are now two entries for each device in my Lovelace UI. That really clutters things up…
Old thread, but this might be useful. I want to hide the HVAC temperature control for the living room if that room has the HVAC is switched off. I use the condition card, with a sensor defined to make it work. This is for the Airtouch4, and I’m using entity slider row as the control.
sensors.yaml
This make the preset mode property of climate.itc_living available as an entity state, so the Conditional card can use it.
- name: Living Preset Mode
state: "{{ state_attr('climate.itc_living', 'preset_mode') }}"
This defines a card type on my Lovelace dashboard with two conditions
- The room damper is turned on
- The Preset Mode is ITC (which standards for Individual Temperature Control or something like that)
- type: conditional
conditions:
- entity: fan.damper_living
state: 'on'
- entity: sensor.preset_mode_living
state: ITC
card:
type: custom:slider-entity-row
name: Living Temp
entity: climate.itc_living
attribute: temperature
min: 19
max: 26
step: 1
grow: true
toggle: false
I am wondering if it’s possible to use OR in this conditional type like in automations:
- condition: or
conditions:
- condition: state
entity_id: person.jimmy
state: home
- condition: state
entity_id: person.joey
state: home
I’m not really sure I understand your question. You can use OR logic in conditions fine.
What I mean is, that your config for the conditional behaviour means that both must be true to show the card (AND condition).
But how to use this with OR?
I have these two entries I would like to simplify to one. I would like to show the ring doorbell camera picture if someone rang the door OR if there is motion (occupancy) in the front yard.
cards:
- type: conditional
conditions:
- entity: input_boolean.ring_active
state: 'on'
card:
type: picture-entity
entity: camera.kamera_haustur_mqtt_snapshot
camera_image: camera.haustur
camera_view: live
show_state: false
show_name: false
view_layout:
grid-area: header1
- type: conditional
conditions:
- entity: input_boolean.garten_vorne_occupancy
state: 'on'
card:
type: picture-entity
entity: camera.kamera_haustur_mqtt_snapshot
camera_image: camera.haustur
camera_view: live
show_state: false
show_name: false
view_layout:
grid-area: header1
But the structure is different and there is no “option” to conditional (OR) like in my example above (taken from automation yaml syntax)
I tried:
- type: conditional
conditions: or
- entity: input_boolean.ring_active
state: 'on'
- entity: input_boolean.garten_vorne_occupancy
state: 'on'
and
- type: conditional
conditions:
condition: or
- entity: input_boolean.ring_active
state: 'on'
- entity: input_boolean.garten_vorne_occupancy
state: 'on'
and
- type: conditional
condition: or
conditions:
- entity: input_boolean.ring_active
state: 'on'
- entity: input_boolean.garten_vorne_occupancy
state: 'on'
the last syntax one though is accepted by the UI, but acts still as AND
You could also try creating another calculated sensor and using that. I think it’s possible, but I haven’t done it. I just do simple things like aliasing sensors, I have this in my sensors.yaml
- sensor:
- name: Temperature Forecast Minimum
unique_id: temperature_forecast_min
state: "{{ states('sensor.openweathermap_forecast_temperature_low') }}"
unit_of_measurement: "°C"
@pedolsky
Thanks - I will give the Entity Filter Card a shot.
Wouldn’t this entity filter card be shown, but just empty?
@tomwaldnz:
That’s a good suggestion as well to create a combined entity.
The card provides show_empty: (true/false).
You are right - thanks for pointing out! Never used that before 
Thank you!