I’m still fairly new to Home Assistant. Things are working well without a ton of effort. One of the things that is detracting to the whole new user experience is all of the zwave.* entities that automatically get added to the Overview UI which usually just show “ready” and make it difficult to find the elements a user should be interested in like the actually control. (Currently, I’ve got about 25 dimmers/switches, a couple of locks, and more to be added.)
This seems like a fairly frequently asked question, but I’m having a hard time trying to figure out what is the right thing to do for the current state of Hass in December 2019. (I’m running 0.103.4 It seems the GUI, automations, etc. all have been significantly improved since much of the documentation and forum threads were written. In particular, a lot of docs/advice related to Z-wave seems out of date Thank you to everyone who has been contributing so much.)
So my question is: In late 2019 with 0.103, what’s the best way to hide the zwave.* status entities so they don’t clutter up the main GUI without removing them completely?
I don’t want to completely disable/remove the zwave entities from Hass by disabling them, they seem to contain useful diagnostic information that one might need when something isn’t working.
Ideally, I’d like something that would catch all of the zwave.* entities so I don’t have to maintain a list of every entity name. I still have more devices to add. It would be cumbersome to go into customize and try to hide each of the ``zwave.* entities.
I’m somewhat assuming that anything in the zwave. domain is primarily related to the zwave network itself for debugging and status information and isn’t a user control like light, switch, lock, sensor, etc.
On a more general note, I wondering does it still make sense for zwave.* entities to be automatically added by default to the main overview UI? It might make more sense if they were grouped, or conditional so that they’d only show up if they weren’t in state ready. It would also make sense if that info was only visible from the Zwave control panel. If every Zwave device is in state ‘Ready’, do a user really need to see that info?
I have to say, currently the UX has gotten pretty good – a device like a dimmer can be easily added from the GUI, the entity names can be customized, and they can be added to an area, so they get grouped in that area’s card. For the most part, no config files need to be edited. Unfortunately, The light or switch entity as well as the zwave.* entity gets grouped into the area as well which detracts from the overall UX.
Change to yaml mode and create a ui-lovelace.yaml, then list in it only the devices you want to see.
Check out the docs on yaml mode.
The States mode (you are currently using) is scheduled to be deprecated, not sure when.
Change to yaml mode and create a ui-lovelace.yaml, then list in it only the devices you want to see.
If I understand correctly, you’re suggesting that I should give up on the “auto maintained UI” and define the UI from scratch entirely in YAML.
While I believe I will eventually do this, I don’t want to do this (yet) for a couple of reasons:
I’m still discovering what works out of the box and want to learn what the current state of Home Assistant is, especially for new users.
Devices/integrations are still being added automatically. Plugged in the roku, chomecast, etc. and they automatically appeared. I’m usually pleasantly surprised. Adding those things to hass was way down on my list. If I wasn’t letting hass control the UI, I wouldn’t necessarily know those were there.
Redefining my whole UI to get rid of zwave.* devices seems kind of a drastic solution to me. I asked this question because I can see there are a bunch of different ways to do this, all with different effects, but I was wondering what might be the prescribed path for new users.
The States mode (you are currently using) is scheduled to be deprecated, not sure when.
I don’t know what you are referring to. This (How Lovelace works) seems to indicate the state machine based UI configuration was pre-lovelace?
I’m currently using Lovelace in the default configuration which I think is referred to as “simple mode” (blog from Oct 2019).
From my reading of that blog article, the zwave.* status entities shouldn’t be automatically added to the UI in “simple mode”. They don’t seem to follow that object model. Maybe I’m not interpreting things correctly.
Okay, maybe you changed it or maybe they changed the default. I’m sorry if I misled you here as the ‘States’ used to be the default. (as they will be deprecating it as it is a) less flexible and b) consumes more resources - this is probably why it has been switched)
There is no way to hide elements from the default lovelave. So sorry, I can’t help you.
If you move to a ui-lovelace.yaml you will get 3 dots (a very slim hamburger ???) in the top right corner of your interface and any newly detected (or the entities you choose to ignore) will be there under ‘unused entities’
I understand where you are coming from AND you have to progress at your own pace.
Scratch building a custom lovelace UI may seem like lots of work at first, I agree there. The reason it is that way is to suit a broad swath of use cases (like setting up automations for tampering switches for example). The devs are partially right to not ‘hide’ too much from beginners who may get some insight to use such obscure entities by just seeing them there. So that leaves us with a little work up front in setting up an optimized UI for our specific use case. The advantage here is it forces folks to learn how to do it, which long run results in a much better user experience. This is just the short/steeper part if the learning curve that is well worth enduring imho.
Also, I believe ‘monster-card’ can be used by ha to hide entity types when new devices are added. This can reduce the work of removing ‘useless entities’ when adding new devices. For example all zwave devices spit out a ‘source node id’ entity that is rarely of use in automations.
You know YAML isn’t the ONLY way to configure LoveLace, there is the storage method configuring it completely from the frontend (the preferred method).
I am using a custom lovelace card called auto-entities, which automatically creates a list of all the entities in the Z-wave domain. Just like you are used to now
I am presenting them on the last tab (lovelace ‘view’), so out of the way to the normal use.
1st, you are correct but it’s not a path i know (I’m old school, have always hand coded and I’ve probably missed a boat load of tricks) hence my statement : -
I would love you to step in if you can assist (I may learn something too )
Though automation is my thing and I try to avoid the front end (I fail at that too) as it seems like I’m using HA as a remote control then.
I migrated from the ui-lovelace.yaml to the storage method, it’s much easier to modify. You can copy what you have in the yaml into the “Configure UI” option in the ‘slim hamburger’ menu.
You know YAML isn’t the ONLY way to configure LoveLace, there is the storage method configuring it completely from the frontend (the preferred method).
From what I can tell, for example searching for how to do things and seeing how much stuff changed recently, the whole UI and configuration process has improved dramatically placing it much more in reach of users who aren’t super technical (or don’t want to climb a big learning curve).
When adding Z-wave dimmers and locks I was able to do it completely through the UI. The main thing I had to via a text editor was zwcfg-*.xml additions for access to device specific parameters (HomeSeer multi-click, etc.)
There is no way to hide elements from the default lovelace
Actually it can be done with the UI: Configuration → Customizations → (select ‘(zwave)’ device) → pick an attribute to override → select hidden.
This adds an entry to customize.yaml. The confusing part was that while the change took immediate affect in the UI, it is lost on the next restart because my default configuration.yaml didn’t have a !include customize.yaml. This was mentioned in several threads. I don’t know if the include would be present on a new fresh install.
Since updating 25 entities would be cumbersome, I just edited customize.yaml after grepping the zwave.* entity_id’s from .storage/core.entity_registry.
@firstof9 - Thanks for the link to the video. I’ve got a lot to learn. I’m still adding devices and I kind of feel like I’ll wind up missing something when I stop letting HA manage the UI. I had planned not to spend much time on the UI until I finish adding devices, get all the MQTT stuff going, get my rtl_433 sensors working with some data storage that is no longer rrdtool, etc.
@Emphyrio - Thanks, I’ll take a look at installing the auto-entities card.
@truglodite - Thanks, I’ll take a look at monster-card as well and see how it compares to auto-entities card.
@Mutt - Thanks for your replies. Sorry you were waiting for my next post, there were many distractions while writing it. It certainly seems like things are rapidly evolving.
Yeah that new show hidden button feature gets rid of the FOMO anxiety for custom ui’s. Regardless what method you use, I’m sure you will embrace ui config more after you get other things settled in and have the time to optimize it.
TBH, I don’t see how the automagic ui would fit well into any long term use case. It won’t take long before even the most unskilled and tolerant user to want a more efficient ui, whether it be all the batteries on their own tab, or some other contrivance. That matrix of what is useful to each user is so broad that an automatic UI setup approaches acceptable only for folks just starting out (who have bigger/better things to worry about than how the UI looks, and may appreciate seeing all the ‘stuff’ as the get familiar with what to do with it all). It fits that role fine as is, and as this thread shows there are many ways to pick it up from there, that can suit a good swath of skills/preferences. Like I’m no yaml expert, so the hamburger config (whatever it is called) works for me. Otoh I have friends who code for work that prefer just yaml. It is nice ha has options for everyone (even in automation, a lot can be done in node red without a single line of code).
It might be useful in many situations but it isn’t the “be all, end all” for configuring the UI. There are some big drawbacks, IMHO.
I use yaml mode and don’t see any reason yet to switch to the GUI editor.
You might as well not as it’s deprecated so not being maintained any longer (in favor of auto-entities I think)
I would recommend starting on the UI as you add devices when there isn’t much to overwhelm you. You can start small and build/modify it as you add more stuff. It’s a good learning experience.
)
