I suspected that was the case so that it could be specified differently for each section. So, I did previously try that but was putting the line before the entity_id list. I moved it to after and it works now. Thank you.
FWIW, should min_width be in the Entities object table on the README instead of the Sections object table?
Also, now that I’m trying to optimize the layout on mobile, when it does switch to vertical, the height seems excessive. Any chance this statement could be revisited allowing for a separate height_horizontal and height_vertical to be specified?
Only matters while in horizontal layout. Vertical layout height is dynamic based on content.
Having more or less up and working now I am not quite understanding how to use remaining_child_state.
I wanted to have a remaining_parent_state and a remaining_child_state together.
So if I have 2 sections, either the child will have more than the parent or the parent will have more than the child. So one will need to show a value and the other is not being displayed.
This, however, corrupted the card and it showed infinity for the remaining_child_state. Is what I am trying to do not possible? Or am I doing it wrong?
In addition, I have one entity that belongs to all parents (fixed value consumer). I am guessing that Sankey is assigning the parent consumption alphabetically, i.e. fixed value will be supplied before the other children.
Is there a way to have fixed value filled last? BEcause the other children “Office” and “Siemens” should have priority (it is also closer to reality because the “fixed value” is a calculated template sensor which is less accurate than the measured ones).
You are creating a circular dependacy with the remaining entities. It might work if you remove sensor.mains_0_untracked from the children of Mains 0 Excess.
State is calculated based on the order in the config, not alphabetical.
Just played around with this card and tried to mimic the client distribution in my Unifi network
Maybe not intended to be used for non-energy-entities but the first result is good enough
What am I missing, as I can not seem to figure out where this unmeasured is coming from?
Is is a calculation error?
That the unmeasured needs to be a remaing_child_state instead of a remaining_parent_state?
This unmeasured value is driving me nuts…
it looks OK, as I have a grid import and Solar production which totals to the second second, this total adds up
but the other childs are less then the total of solar and grid import which gives me the unmeasured.
I don’t see a problem. You have a 27W discrepancy. This is normal. No sensor is perfect and there are always losses everywhere.
If you are certain that you have no unmeasured power and can’t recalibrate your sensors, you can use children_sum or parents_sum to reconcile the difference. They are not easy to understand though