Item 1 is not meeting the minimum threshold of 5 height units and it’s adding an item to the column. Again you can adjust all of this with the layout card. The layout card even describes in great detail how the automated placement of cards works. It would be helpful if you read it, then you’d understand.
Pulled directly from layout card help:
It follows a simple process.
- A number of columns are prepared based on the screen width and
<column_widt>
. - The number of columns is clamped between
<min_columns>
and<max_columns>
- Cards have a
cardHeight
, which is calculated from their content. One unit is roughly 50 pixels tall. - Each new card is added to the first row which is less than
<min_height>
units tall. - If all columns are taller than
<min_height>
, the card is added to the shortes column. - Once all cards have been placed, any remaining empty columns are removed.
is the condescension really necessary? i have read it and i do understand it, for the most part.
my issue is with the idea that the system is “trying to prevent vertical scrolling,” which is what has been said more than once in this thread. if that is in fact the goal, it’s clearly not doing a very good job when a very simple scenario like this does the exact opposite.
My tone wasn’t meant to be condescending. Sorry. I just wanted you to read the blurb about how it works.
Because it has a default of 5 units for a minimum size. Simply using auto with layout card and making the min_height attribute set to 4 or 3 would get you what you want.
thank you, i’ll give this a shot.
would be helpful if there were somewhere we could just configure the minimum height for the system as is without needing to use the layout card. seems like it would solve a bunch of potential issues…
At some point there was talks about a new system where you could drag and position things in a grid like system. I have no idea what happened to that idea.
i actually had to go to min_height 2 to get this to work the way i wanted, but it does in fact work. thank you for the assist.
Been interesting reading your discussion. Whilst I fully understand HOW it works - I also fully believe the philosophy behind this is wrong - and is one of those things that’s clearly ‘a developer does UI design’. Sure it’s logical but it’s bonkers to use.
Given the thrust to dumbing everything down (integrations / move from yaml etc) - this stands out as still incredibly odd. The casual user is oft mentioned for reasons to move away from yaml and move everything to the front-end. How is this casual user going to react when they’ve made themselves a dashboard just how they want it - only to find it renders completely differently on every different device with panels pissing about all over the place? You’re seriously going explain to them the 5 step logic based on the min panel size?
And - I might go on - this is all now rendered pointless by the multiple Lovelace dashboard access stuff. We can get away from the one-dashboard for every device paradigm and just have different dashboards for each device type / screen layout we connect with…
Listen, I just explained how it works. I didn’t come up with the idea, I didn’t develop it, I wasn’t on a committee coming up with the process, nor am I defending it. I will however, argue back when people don’t take advice on how to fix it and instead complain.
Sorry - I wasn’t meaning to have a go at you. I can see how it came across but that wasn’t my intention.
I’m just arguing against the concept that this is a sensible way to have a front-end. If we don’t make our voices heard, then how will things get better? I love HA, but the whole “hunt the panel” thing got boring a couple of years ago. But for some reason there seems to be a mindset that this is how it is, and it can / will never be improved. Most things have improved so much over the last couple of years, but the screen layout is still untouched and still a dog.
IMO.
I’d just like to post this here. My current front page. No stacked cards, and as you can see - minimising vertical scrolling is not what this dashboard achieves. It’s moving cards about and making the screen taller than you’d think possible.
-
Just posting pictures does not help, not to mention you may not have refreshed the page since moving the order. There’s a caveat to the system. When you adjust the order, it moves the cards around but the automatic placement does not execute. So reloading the page will cause it to execute so you can see the true decided layout.
-
We have no idea what your vertical stacks look like. You could have vertical stacks littered throughout that. That will drastically change your placement because the considered card is the vertical stack, not the card inside the vertical stack.
-
Custom cards may not calculate height properly. Things like fold row and conditional cards impact placement because they are cards that have height when unhidden/expanded. The state at load time is usually what’s taken into account for card height.
-
A solution has been posted many times. You’re welcome to use it to avoid all of this.
-
If you want to see this change, make a feature request. In all these complaints, I’ve yet to see someone take the time to create a feature request to change this behavior.
Just posting pictures does not help, not to mention you may not have refreshed the page since moving the order. There’s a caveat to the system. When you adjust the order, it moves the cards around but the automatic placement does not execute. So reloading the page will cause it to execute so you can see the true decided layout.
The picture shows exactly what I wanted to show. That the aim of minimising scrolling doesn’t work (although my point is that this is the wrong philosophy - but that wasn’t the point of the picture). What else would you like me to have posted to back this up?
As to the second point - I refreshed several times because I wanted to be sure this wasn’t me being an idiot before I posted it.
We have no idea what your vertical stacks look like.
I mentioned in the post that there are no stacked cards on that page. They don’t look like anything because there aren’t any.
Custom cards may not calculate height properly. Things like fold row and conditional cards impact placement because they are cards that have height when unhidden/expanded. The state at load time is usually what’s taken into account for card height.
Fair point. I see there are 3 mini-graph cards on the offending column - so it could well be that.
A solution has been posted many times. You’re welcome to use it to avoid all of this.
I’ve not seen a solution to this. You’ve shown me how I can see the actual order of the cards, but not how to stop them wandering about the dashboard.
If you want to see this change, make a feature request. In all these complaints, I’ve yet to see someone take the time to create a feature request to change this behavior.
A great point. I’ve now created a feature request for what I’d like to see. Please vote for it people!
Custom:layout-card has been mentioned in this thread a ton. I even walked another gentleman through the process above.
And I wrote a lengthy response as to why that’s not practical. Having an entire dashboard defined in a single card would be like 1000+ lines long. An utter pain.
Recently, for example, I had an entity_id change under me which broke my picture-entity card. All I got was red screen saying there was an error - can’t remember the exact text - something like ‘Cannot get state of undefined’. I basically had to remove entity by entity until I found the offender. I can’t imagine doing that for a card with over 100 entities on it.
Many things can be done in other ways - however the dev team often look at improving them. See automations / scenes etc moving to the front end. Indeed much of the focus has been on improving the front-end accessability. I cannot for the life of me understand the defensive attitude to suggesting improvements - or the denial that everybody on here who finds the logic odd has a valid view point. It’s quite frustrating.
I’m not arguing to be a troll - I just feel that you’re dismissing an idea because ‘it doesn’t work that way’. The very fact that somebody took the time to make a layout-card to work round adds strength to my point. I think it would be a genuine improvement to HA, and that’s what we all want - devs and users alike - to make HA the best it can be.
Anyway - I don’t think we’re going to agree so this will be my last post on the issue (except to plug my feature my feature request if others respond). I’ve raised the feature request and we’ll see where that ends-up.
That’s not how you use it. You can use it as a single card where you need it. That would be per view worse case scenario.
See comment above. The offending card would still be red, not the entire layout card. Please don’t make assumptions.
No but you seem to knock the solution before trying it, which is why we are in this round about communication. It seems that you just don’t want to attempt using this, instead are making assumptions on how it works.
This card is most similar to a stack card. Do you get errors on the stack card when underlying card fails? Short answer: No.
This is correct. Because you are unwilling to try the solution. Not because the solution doesn’t work.
as a completely unrelated side note. I suggest that you look into the decluttering card or lovelace_gen. Both allow you to significantly shrink your configuration. They also make it easier to maintain.
Personally, I use lovelace_gen. I have about 3000 lines of ‘lovelace_gen’ code and it generates around 100,000 lines of UI. It’s extremely easy to manage and adding items is simply a configuration change with a couple lines of code. It has a steep learning curve to it though. Anyways, here’s a snipit of the entire layout card for it
- type: custom:layout-card
layout: grid
gridrows: auto
gridcols: 20% 80%
cards:
- type: vertical-stack
gridrow: 1 / 1
gridcol: 1 / 2
cards:
...
- type: vertical-stack
gridrow: 1 / 1
gridcol: 2 / 2
cards:
...
Make the cards contained in ...
decluttering cards or use lovelace_gen. Heck you can simple use !includes for each card.
Came here to see if i can find any solution on my vertical stacking issue
And although there was quite a bit of heated back and forth, i did learned alot
And thanks @petro for your patience, hang in there.
Ill give custom layout + lovelace_gen a shot
Lovelace_gen is a steep learning curve but the juice is worth the squeeze.
This might give you some ideas
I use layout-card a lot and Lovelace-gen a bit. I also make a lot of use of stack-in-card and other methods to create compound “cards” which I put in separate include files to enable me to reuse recurring code and also include cards in different views and on different dashboards for landscape and portrait devices.
For example, the map screen for desktop uses the same compound ‘card’ four times, once for each person, I use layout card to place them and lovelace-gen to provide the parameters.
On mobile only one of the cards shows and you choose which by clicking on the person entity in a glance card which sets an input field. Conditional card does the rest.