Thank you for a great update. I have an issue though that has meant I have had to roll back. My dashboards make great use of the more-info-card to display the more info sliders for light entities in my primary dashboards. I have managed with various cardmod options (e.g. state card content) to remove components I do not need. However, the new update has altered the entity information dialog to show the individual members of light groups but for me this really breaks my dashboards. @piitaya or @MindFreeze , is there anyway of disabling this new feature or would you be able to help with the cardmod code needed to hide it? I really like my dashboards and the more entity sliders are awesome, so I will be stuck without being able to update HA anymore unless I can find a way of disabling this new feature. Any help would be much appreciated! Thank you
Interesting - seems counterintuitive. I might want them to clutter in a room, but want to see them as part of the group. This way my rooms show only the grouped item and only show the details when looking at the group.
The whole reason (maybe for me only) is to keep the clutter out of some rooms with lots of related devices.
Any chance we can get it to go back to the way it briefly was ?
Making these members show by user choice would be nice. And there is a FR for that.
To be clear, I mean Not per member, but as a group.
Reasoning: we grouped the members for a reason; to have central control. No need to show them in the more info of the group , which acts as the new controllable entity.
If we need to set the hide members, we hide those also in other places of admin control, so that is not always a desirable solution
Adding a setting to hide/show members would fix this
Or just have them in theUI, but collapsed under a heading like “Hidden Members”. This way it’s just a click away to expose.
My use case is for that occasional memebet that isn’t behaving that needs a manual intervention. I have grouped things together from various ecosystems and control methods… Wifi (tuya, ge cync) and iR … Those sometimes require fine tuning.
Another use case is my grouped night stand lights. Great all the time, except that one time one of us stays up later and the other wants to turn off their light. Shame on me for not automating this one tho
Hi! How do I assign integrated energy sensors to rooms in the Energy Flow window that appears on the energy dashboard? It is not possible to assign rooms in the Create Riemann Sum Integral Sensor function.
A riemann sum sensor can have an area assigned. Create the sensor in the UI, or in yaml with unique_id assigned, and then select the entity settings for the entity and you can assign an area, same as any other sensor.
Being able to access grouped entities in the more info card is great. The only downside for me is that most of my grouped entities are lights and they’re grouped via Zigbee. That means they don’t split out with this new feature. Is there any chance of this being supported in the future?
Totally understand and I am not being difficult. I do agree with @Mariusthvdb on this though. Grouping was to simplify my dashboards. In my kitchen, I have 48 Hue bulbs. These are grouped by area and now my more info for the downlights alone has a list of 24 different entities that makes my dashboard extremely long vertically. I would also request being able to swtich these on and off by user choice. I can create a lighting group within HA for this and hide members but I already have the lighting group coming through from Hue. Being given the option to show/hide would be really nice. @Mariusthvdb, would you share the location of the FR so I could review and add to it? Thank you
We can’t add a new dedicated visibility option for every new feature. An option for this already exists and is called “hidden”. If you don’t want entities to show up in the more-info, enable their hidden option. There is also the option of not scrolling down if you just don’t want to look at them.
Why is it so difficult to accept that showing those by default is not for everyone?
I can appreciate you can Not set visibility options for every new feature, but please can we ask the same from the dev team to not force those long lists of members on every more-info?
Hiding those members is not only effective in this more-info dialog, and when actually developing the Dashboards our users get to manipulate we need the info.
But in most other circumstances, that info should not be at their fingertips be default.
A generic setting to show/hide group members would be so welcome. Maybe even admin only?
If all of that would not be feasible, (can’t imagine though) please at least make the Dom path to that section (!) easily theme able, so we can card-mod it out of sight?
We know this is not for everyone but every single UI change is negative for some. There is no way around that except using 3rd party mods. Something like kiosk mode or card-mod (as you said), for example.
I haven’t looked into this but if it is too difficult for mods to hide it, we should be able to make some minimal changes to make it easier.
I agree you can’t do themnall but in this case ALSO WHOLEHEARTEDLY Agree that this is a special one Mind. It needs to be there. You need to be able to hide group display separately… I’m having the same issue and I want the in this card but NOT the auto dash. That would me hide. Buuuuut.
Nope sorry bud this is a miss. this one is necessary because the pattern you’re setting up. If you’re going to put them in the more info panel it needs a separate control for expansion. Hell some of the systems I have have 12-24 member lighting groups. Those won’t fit. But I want them in the dash. Not hidden.
Don’t get the answer ot perhaps described my question not good enough. I’m fine with separating it in another entitiy. Here it was already a seperate one and I only put it into the template, to have the icon in more info, …
But still/again want the level be shown in more info. As before and in core integration vacuums still there, e.g.
So how is the setup needed for a template vacuum, that the more-info of this known from where the battery state is delivered, if it is not from the attribute anymore.
