Connections are somehow randomly drawn about ha-sankey-chart

[MindFreeze]

Can you include at least the previous section in the screen shot? Set show_names to false if you are worried about privacy.

[emufan]

Sure.

BTW Possible to have (with k präfix) a Thousand delimiter (here in Germany .)? So 13.947 instead of 13947?

[MindFreeze]

For 13.947 you want to set unit_prefix to k and round to 3

This is screenshot is very strange. I will have to experiment a bit to figure it out.
I am guessing that some of your sensors report fractions and get rounded down to 0. This is a bug as zeros shouldn't be displayed but rounding probably happens too late.

[emufan]

As said, "without k prefix" 😉 Because otherwise, the next column and all other values in the same column will show 0,239 instead of 239, But not that important. As is it only the ony value, I only thought, it is more common to have this thousands separator. But of course not urgent.

Same for the strange connectors. Not urgent.

[emufan]

With e.g. round:5 it looks the same

[emufan]

Here an updated one with different colors, to see the child sections better.

min_box_height: 5
min_box_distance: 5
wide: false
round: 5
height: 400

The lower, the thinner. Regardless of values.

And the bars are not taking the different values into account much either. Moth probably you derive the ratio from the first column/section? Perhaps better to derive it for each column/section, each? Because without first column, it is better distributed

[emufan]

Did you already have some time to look into this? Whatever I try, it is the same.

Some are too thin, some not there in total and it seems, that it is thinner and thinner (and sometimes not even there) per section from top to bottom. (each color is here a group of child's from entities before.

or

Perhaps only a wrong rounding in calculation of the positions?

And what I saw now a lot of times as well. Above you can see that the vertical space is e.g. filled 90% in column 1. But sometimes it is only 40%, 20% or less. Why is this happening and how to avoid this?

later today

The bars height is getting lower and lower. You can see it in columns 1, but 2 as well. Only space between is increasing in 2.

[MindFreeze]

This is all because you have a lot of tiny values in the last column. This requires a lot of empty space between the boxes and makes the pixels per state value weird. As I said 0 values should be hidden but I haven't had time to fix that. You can improve this a bit by reducing min_box_height and /or min_box_distance

[emufan]

No, As said, the 0 is only rounded 0,x. There is value. And these values should stay, because there is something >0 and therefor important to see.

And the mentioned problems are there if I remove the <0.5 values.

A bit less visible, but the same and a systematical problem independently of the values and number of values.

And secondly, the height of the thin connectors are completely independend from the values. The only rule is: thinner from top to bottom

1. There is something wrong in the connection line codes From top to bottom, the connections are thinner and thinner or are completely not there. Good to see in all the pictures. Eg. especially here,
   
   and here
   

2. The problem that the height of the first column is getting lower and lower, if the values increase over the day is still there as well.
   
   ~half of the height some hours later
   
   and in the evening again 20% of it.

[emufan]

P.S. If I replace

        const endSize = Math.min(c.size - endYOffset, b.size - startYOffset);
        if (endSize > 0) {
          // only increment if this connection will be rendered
          startYOffset += startSize;
        }

with

        const endSize = Math.min(c.size - endYOffset, b.size);
        if (Math.min(c.size - endYOffset, b.size - startYOffset) > 0) {
          // only increment if this connection will be rendered
          startYOffset += startSize;
        }

the end is fine. Completely. As said. A glitch in code not values.

99% fine. Only a little further glitch at the beginning, where I'm currently not understanding your calculation. But this is not related to my fix above. It was there before already, but only less or fewer times to see, because a lot of connections were not drawn without the fix.

[emufan]

And the 1% problem is as far as I can see, because of the max 1 in startsize calculation, to the heigh is too height in thos edge cases because of this. Without it it is fine

So instead

        const startSize = Math.max(Math.min(remainingEndState / b.state * b.size, b.size - startYOffset), 1);

now (if there is another background and to have still a lower limit.

        const startSize = Math.max(Math.min(remainingEndState / b.state * b.size, b.size - startYOffset), 0.1);

or directly

        const startSize = Math.min(remainingEndState / b.state * b.size, b.size - startYOffset);

[MindFreeze]

Your main issue is with rounding. There should never be a 0 value connected to anything. Yes, it may 0.1 underneath but this is meaningless if the UI shows 0. These 0 values will disappear in the next release so you may as well set round: 1 now if you want to keep them.

[emufan]

No, the main issue are the corrections above. As said, even with removing the <0,5 values the problems are there. See above pictures. I don't know, why you are insist on a not existing the 0 problem, if this is proven, that it is not related to the problem.

And to remove the values now, please only with an option. I really like to see them (that there is something <1, but of course don't want to see ,x everywhere.

All the cases, you now want to hide whyever have value >0. And the rounding behavior to show 0 in cases <0 is completely correct and logical. Let's say you have 10 children 0.4 and one parent 4. You now want to show only the parent with 4 without children if the parent is the sum? Makes no sense. Even with 10 0 cases, I know, which 10 entities (e.g. from 30 children, where 20 are ==0) are causing the 4 and if I want to see more, I have to set the rounding to 1. So it is the opposite of meaningless.

So if ever, then please with a "hide rounded 0 values yes/no" option to set how the user or I ;-) want.

[MindFreeze]

fixed in v0.7.0

[emufan]

@MindFreeze With 0.7.0 a lot better, but still

With my fix before:

[MindFreeze]

This is correct behavior, not a bug. Count the child numbers and you will see, they are more than 793 Wh. Your change displays 793 splitting into ~806 which makes no sense.

[emufan]

You are right. Thanks for pointing me ar this. Copy&Paste issue, here missing one daily->yearly replace in the sum helper sensor.