I hadn’t realized that dashboards have an upper limit, which isn’t surprising since there’s only so much a system can process at one time, but I started getting file/config/.storage/lovelace_dashboard_DASHNAME is too large, skipping. Max size 512000 bytes once I started doing a large redesign of my UI/UX.
It’s crazy how just some cardmod’s and auto entities, both which can require a lot of code to really tweak your dashboard, takes up as much space for ~10 dash pages as my old dashboards with ~20 pages and hundreds of entries, but here we are.
So I’m faced with some options and am curious what others do to get around these issues:
Ditch the UI editor and go pure YAML. Of all the things to go pure YAML on, a dashboard makes the least sense to me since you really need to see what’s happening as you make changes. One option would be to develop on a UI dashboard and then copy/paste that into the YAML only dashboard, but that’s cumbersome. The only part of this that I find useful is doing includes but I don’t think that juice is worth the squeeze.
Smaller tabs/cards/etc spread over multiple dashboards. I think a version of this is likely but just spreading everything over a dozen dashboards also seems cumbersome. The next bullet would be the “version of this” that think is likely.
Create “utility” dashboards for the heavy hitters. I have some complex auto entities (among other things) in the new dashboard that can take a lot of inline Jinja2 to get working the way I want, these could be shuffled off into one or more utility dashboards under a browser mod popup that can be called cross dashboard (this is where I’m leaning)
Write more shorthand and simpler inline Jinja2. I never worried about that, having been ignorant of the file limits, but this only goes so far.
Write functions/templates/etc to do the Jinja2 lifting. This is also probably likely, and that is that instead of doing inline Jinja2, just cook that code into functions or templates more, rather than lean on cardmod to handle them. For instance, determining background or icon color - the logic could be baked into the function/template and then all that’s needed for cardmod is to access an attribute rather than calculate that itself. This has the benefit of being more reusable as well.
What have you other big dashboard designers done?
To give you an idea of the direction I was going, these are a few cards. They take a disturbing amount of code to achieve, with each room summary being about 300 total lines of YAML. It’s beyond just “pretty”, those big icons are also visual cues and change color based on if there is motion in that room or how many lights are on.
My Main Dashboard, using 5 fold-entity-rows with auto-entities inside + 5 expander-cards, with 20 Custom:Button-cards inside + 5 expander-cards, with total of 8 history-explorer-card inside +
2 extensive apex-charts and extra dozen of custom:button cards
Headers in expander-cards and fold-entity rows are “filled” with “entities to i.e legacy-groups”
And everything is heavily card-modded, templated, and with 2 huge button-card template in view-header
Still im only At 1/3 of your size, So i guess i dont have to worry … yet
PS: Using custom:button-cards with templates in View-Header can save you i.e +2000 rows
Also, look at your various Card/Entities templates, might be alot, you can “convert” to template-sensors , i.e calculations , functions etc.
And “define” repeated a Cards in Your Theme
Those room overviews do use custom button cards, along with some Mushroom cards. I think where it all really goes downhill is I have each of those buttons call a popup of auto entities, that’s where the real templating and card-modding happens. So if you figure even just 6 buttons per card for 10 areas = 60 heavily templated and card modded popups - that’s where the real problem lies.
I’m exploring cross-dashboard popups, which will likely fix the problem, but I think also cutting down on the need for card mod and auto entities to be so heavily templated in the card but rather in a template entity that stashes what’s needed in attributes might be the only way to get this dash moving forward.
Thanks, I’ll have to explore that and see what rabbit hole I go down. There’s probably no way to escape templating, regardless of card mod or something else (card mod being king makes it hard to move away, it’s so well supported), so I’ll have to just get creative without over engineering (which it likely already is lol).
Cross dash popups are challenging, but there are two HACS extensions that do this specifically that I’m trying out. Bubble Card is a nice look but super JS heavy and I went that route first but it killed my CPU on edits (400%+) so i’ve abandoned it. Browser mod can only do it if every browser is registered and even then it’s iffy. That’s why I was searching for suggestions, that’s all I have now (pending your recommended link) if I want THIS dash, otherwise I have to pivot away from many hours of work - which if it happens, it happens.
It looks very interesting for sure. It seems like it’s developed by the same person as card-mod, maybe? It was hard to discern from the thread, but it also sort of sounded like it was being rolled into HA - but maybe I read that wrong.
Kind of Yes, he has “forked/taken over” some of ThomasL’s repos and enhanced , committed to them ( in card-mod he has done alot pull’s , before he decided to create/simplify/adapt it to HA " resent " changes in the " generated front-end structure"
Your best option would be migrating to yaml mode where you will be able to use anchors, secrets, include.
Even now in a storage mode you can also use a decluttering card which also saves lines.
Particularly for cardmod. Reusing cardmod code is described here: main cardmod thread - 1 st post - fantastic link at the bottom - other stuff - reusing a code.
Just jumping in to say: that error is not from some limit in core. It’s from the Watchman custom integration, which has introduced a size limit on the files it processes now that it also looks at config storage files as well as YAML.
A future release is slated to make that size user configurable, so you might find you don’t need to take any action at all on this apart from waiting for an update to Watchman.
That makes sense as I do use Watchman, but it makes me wonder why it says they are a problem. It is just made up and arbitrary limits or is it thinking “if you were on a rPi” or something?
Well, honestly, my dash is 844K already, when I was debugging something else is when I saw that error. For all I know it’s been complaining for years, as I have two other files over that 512K mark already and none of these have “failed to load” as I was warned, which was confusing but I though I was just being lucky. This current dash also loads without a problem really and it’s 17,604 lines - but you make it sound like I’m about to have a catastrophic problem
This has definitely only just been introduced with the recent updates to Watchman.
To reiterate this warning is only related to that component. It is a warning not an error. And it has nothing to do with core and its capacity to load files. You really have nothing to worry about.
No, i have no idea my self whether there is/was a limit, i guess/would have thought a txt-file is a txt file ( And it’s not like it’s 2digits MB files ), and ones Hardware should be capable of handling it
My Smiling Face Was only to my “Suggestion/Approach” … Trail & Error , And honestly i hadn’t heard of / seen anything about a file-size limit ( of the Dashboards ) before this, so the “Subject” Caught my Attention
Also because i just bought a Green in December, And after been “Testing” it for a few month now, i honestly think " I definitely Has “Limitations” i Haven’t experienced Before on my other Hardwares
With my all due respect, the main issue is not “why I was warned about s limit”. (as it was said above this is just a feature of Watchman). The main issue is that your large dashboard should be moved to yaml if you need it to be maintainable.
