Throttle only skips some renders. Updates are still received but not displayed right away. All the calculations happen on render though.
I have a chart with frequent updates running on a slow tablet with only 1s throttle but my chart is probably less complex than yours. Mine is similar to the first image in the readme. I also have only 1 or 2 remaining type entities and prefer to use HA templates. This could impact performance I guess.
I was already thinking about doing the calculations using template sensors. But when it comes to electr. power the remaining entities are are a simple āparent - known device1 - known device2ā to have an entity representing the unknown consumers.
It likely wonāt make a difference if being outsourced into a templates.yaml.
Not to mention that I dislike splitting up definitions without sense. the entites which are of type āremaining_parent_stateā are of no use outside the sankey card since so outsourcing them into helpers or templates.yaml results in the risk one accidently deletes these some day since uncertain about why they were defined and thus get deleted, until one realises the misery.
Splitting up things makes sense if software offers a working āparent/childā object tree feature, but thatās a differnt story. Without such a feature I keep myself from splitting things whenever possible.
The function to calculate remaining connections is recursive so it may have some performance penalty but it should be only in complex setups with grouping, passthroughs, etc.
Just receiving the frequent updates from the API could be the problem. In that case you can try to create throttled entities in the backend with filters in HA Filter - Home Assistant.
I use card mod to get bigger fonts in the Sankey flow:
card_mod:
style: |
ha-card {
color: white;
font-size: 23px;
}
.span.value {
font-size: 23px;
}
This works great on my macbook and ipad but on my Google Nest Hub (second gen) it doesnāt work. On the Hub I get the default font only.
Has anyone done this before on a Hub with bigger fonts?
After a lot of edits I finally seem to be getting somewhereā¦ and I confess itās a beautiful chart when in landscape mode
Not really sure why the most right entity is displayed as it is , but itās ok. Well in fact it is not reallyā¦ its a child of the same column as the other entities, so I donāt get why it is displayed in its own column next to those.
However, this results in an unreadable chart when using portrait ( my normal perspective) o. Mobile ā¦
Now ofc Sankey thrives in Landscape, but would there be anything I could do to make this less of an issue ?
Fwiw, I have experimented with a minim every state, but that makes no difference. It merely takes out some of the entities that are practically invisible as they are already ā¦.
Iām running into the same thing Mariusā¦
The worst part is ive been thinking about it for a week and canāt even think of a graceful way for the card to adapt to moving from likely a 16:9 or 4:3 aspect ratio to 1:2 or maybe 1:2.5.
The card would likely have to support dynamically dropping sections (essentially columns) starting from either the left or right or scrolling? Combination of both, while adjusting or selectively disabling icons and/or labels?
I was personally planning on building a second chart that had half the sections / width (a compromise for sure) and dropping them behind thomasā custom card that supported selective display on mediaquery (layout card?)
What do you monitor your devices with? Smart plugs?
There is now min width option per section. So you can set some width for each section and if the total width is more than the screen it will become scrollable horizontally.
The right most part wonāt be visible until you scroll but this is the best I can do for now.
I have been considering a vertical root like layout for mobile but labels would be an issue and it would be a lot of work to support it.
Ah right, I didnt spot that yetā¦ will experiment, thx.
still, I dont see why the Heater office would need the space in the most right column, as it is a child of the same hierarchy as the entities 1 column to the left of it.
it seems it is not a matter of available vertical space. (Iāve tried to delete several of them. using a min value). It keeps being positioned as a single entity in that right most columnā¦
You must have put it in a separate section. Check your indents. Looks like you configured a section with only this entity.
Section/column placement is explicit in the config and not decided by the card.
using:
- entities:
- entity_id: sensor.energy_consumed_daily
name: Verbruik Huis
children:
- sensor.calculated_totaal_dag_afname
- sensor.solar_self_consumption_daily
- entity_id: sensor.solar_energy_daily
name: Opbrengst Zon
color: gold
children:
- sensor.solar_self_consumption_daily
- sensor.calculated_totaal_dag_levering
- entities:
- entity_id: sensor.calculated_totaal_dag_afname
name: Grid Afname
# children:
# - sensor.grid_energy_total
# - sensor.gemeten_energy_per_dag
# - sensor.ongemeten_energy_per_dag
# - entities:
# - entity_id: sensor.grid_energy_total
#
- entity_id: sensor.solar_self_consumption_daily
name: Verbruik Zon
color: darkorange
# children:
# - sensor.gemeten_energy_per_dag
# - sensor.ongemeten_energy_per_dag
- entity_id: sensor.calculated_totaal_dag_levering
name: Teruglevering Zon
color: orange
I can get the āsensor.solar_self_consumption_dailyā to connect form both 1st column entities into the second:
either this:
or
Am I missing a section where we can connect a child to 2 different parents??
this might be very silly, but after some other chart issues, I have to askā¦ can we not show negative values?
Returning to grid or consuming from grid being the most important value in my chartsā¦ and I just realized it wont show because he chart only shows upward from 0, (and I even set a higher threshold to take away the 0.0 or 0.01 kWh entities)
this however also means my complete return to grid isnt shown.which is per definition a negative number.
I could create a template sensor and abs it, but how to distinguish the entity from being actually consuming or producingā¦ as itās the result sum of total production and total consumption.
amount exported is not necessarily a negative number. It is only negative if the reference point is energy imported.
I just colour it and works well to identify export vs usage.
sure I do the coloring too, and just made an abs template, figuring if the Net grid counter would go below 0, it would also cause the returned to grid sensor to grow, so the change would be noted anyways.
- unique_id: saldo_totaal_dag_energie_afname
name: Saldo totaal dag energie afname
state: >
{% set saldo = expand('sensor.grid_energy_teller_1','sensor.grid_energy_teller_2')
|selectattr('state','is_number')
|map(attribute='state')
|map('float')|sum %}
{{[0,saldo]|max}}
yet, this poses the same issue as above, not all connections are displayed in the Sanky
consider this:
sections:
- entities:
- entity_id: sensor.energy_consumed_daily
name: Verbruik Huis
color: brown
children:
- sensor.calculated_totaal_dag_afname_t1
- sensor.calculated_totaal_dag_afname_t2
- sensor.solar_self_consumption_daily
- entity_id: sensor.solar_energy_daily
name: Opbrengst Zon
color: gold
children:
- sensor.solar_self_consumption_daily
- sensor.calculated_totaal_dag_levering
- entities:
- entity_id: sensor.calculated_totaal_dag_afname_t1
name: Dal
color: green
children:
- sensor.calculated_totaal_dag_afname
- entity_id: sensor.calculated_totaal_dag_afname_t2
name: Piek
color: orange
children:
- sensor.calculated_totaal_dag_afname
- entities:
- entity_id: sensor.calculated_totaal_dag_afname
name: Grid Afname
children:
- sensor.gemeten_energy_per_dag
- sensor.ongemeten_energy_per_dag
- sensor.saldo_totaal_dag_energie_afname
- entity_id: sensor.solar_self_consumption_daily
name: Verbruik Zon
color: darkorange
children:
- sensor.gemeten_energy_per_dag
- sensor.ongemeten_energy_per_dag
- entity_id: sensor.calculated_totaal_dag_levering
name: Teruglevering Zon
color: orange
children:
- sensor.saldo_totaal_dag_energie_afname
# this is the new entity with connections to 'Grid Afname' and 'Teruglevering Zon' above
- entities:
- entity_id: sensor.saldo_totaal_dag_energie_afname
name: Saldo
color: red
which in addition to the missing link in the post above, also does Not show the connection to the āGrid Afnameā. The numbers are perfect up to 2 figures decimalā¦
the gaps in those are easy to spot, there is a connection in the config, but they are simply not drawnā¦
Abs doesnāt make sense in this case. You want to invert it. So -1*. By definition exported = -imported. Only one of them can be <0 at a time and wonāt be displayed. Then you can arrange both entities however you want
not really.
this entity returns negative if net metered is consuming, and positive if returning. If Iād invert, I would be creating the same problem, but then in the opposite situation.
With the 0, abs variant, I now have an entity that takes out the minus, and remains 0 if negative.
this is another illustration of the same numbers:
what I dont understand is why there is no connection between Opbrengst Zon (bottom left) and Verbruik Zon next to it. Same for the missing connection between Grid Afname (to the left of the Center Red Saldo).
First of all, absolutely love this card @MindFreeze !
Now, I encounter something odd: I have this card 2x on the same dashboard, once without energy_date_selection (left), using todayās values, and once with energy_date_selection: true (and the energy date selection card above, on the right).
For the card with energy_date_selection, I only see my ābaseā sensors, not the ones I created with helpers to group together the underlying energy consumption sensors (using the āgroupā helper, and āsumā).
For reference, hereās the relevant part of the code for the left one, the right one has the same but energy_date_selection: true added under show_names: true
- type: custom:sankey-chart
show_names: true
sections:
- entities:
- entity_id: sensor.house_daily
name: House
color: indigo
children:
- sensor.living_room_daily
- sensor.network_daily_consumption
- sensor.office_daily
- sensor.masterbed_multimedia_daily
- entities:
- entity_id: sensor.living_room_daily
name: Living Room
color: midnightblue
children:
- sensor.utility_daily_fridge
- sensor.utility_daily_living_multimedia
- sensor.living_room_hue_energy_daily
- entity_id: sensor.network_daily_consumption
name: Network
color: purple
children:
- sensor.network_daily_consumption
- entity_id: sensor.office_daily
name: Office
color: darkred
children:
- sensor.office_daily
- entity_id: sensor.masterbed_multimedia_daily
name: Master Bedroom
children:
- sensor.masterbed_multimedia_daily
- entities:
- entity_id: sensor.utility_daily_fridge
name: Fridge
type: passthrough
color: darkblue
children:
- sensor.utility_daily_fridge
- entity_id: sensor.utility_daily_living_multimedia
name: Living Room Multimedia
type: passthrough
color: darkblue
children:
- sensor.utility_daily_living_multimedia
- entity_id: sensor.living_room_hue_energy_daily
name: Living Room Hue
color: darkorange
children:
- sensor.rear_energy_daily
- sensor.left_front_energy_daily
- sensor.right_front_energy_daily
- sensor.rear_table_energy_daily
- sensor.dining_energy_daily
- sensor.reading_energy_daily
- entity_id: sensor.network_daily_consumption
name: Network
color: purple
type: passthrough
children:
- sensor.network_daily_consumption
- entity_id: sensor.office_daily
name: Office Gear
type: passthrough
color: darkred
children:
- sensor.office_daily
- entity_id: sensor.masterbed_multimedia_daily
name: Master Bedroom
type: passthrough
children:
- sensor.masterbed_multimedia_daily
- entities:
- entity_id: sensor.utility_daily_fridge
name: Fridge
- entity_id: sensor.utility_daily_living_multimedia
name: Living Room Multimedia
- entity_id: sensor.rear_energy_daily
color: var(--warning-color)
name: Rear
- entity_id: sensor.left_front_energy_daily
color: var(--warning-color)
name: Left Front
- entity_id: sensor.right_front_energy_daily
color: var(--warning-color)
name: Right Front
- entity_id: sensor.rear_table_energy_daily
color: var(--warning-color)
name: Rear Table
- entity_id: sensor.dining_energy_daily
color: var(--warning-color)
name: Dining
- entity_id: sensor.reading_energy_daily
color: var(--warning-color)
name: Reading
- entity_id: sensor.network_daily_consumption
name: Network
color: purple
- entity_id: sensor.office_daily
color: red
name: Office Gear
- entity_id: sensor.masterbed_multimedia_daily
name: Master Bedroom Multimedia
The energy_date_selection option uses history data from HA. It shows the difference between the beginning and end of the selected period. This is reverse engineered from HA energy dashboard.
So if some entities arenāt showing properly, they either have no history yet, or they have to be configured with state_class somehow.
Best way to debug is to check the history view.
Thanks!
Have made ānewā helper sensors that are not limited in time. Iāll wait and see in the coming days if it delivers, but looking into the history view shows data being built up.
Thanks once again for this awesome card!
I suspect itās to do with the fact there is no remaining energy in Grid Afname to go to Saldo.
Your leftover energy is coming from opbrengst Zon. So you need to sort out the calculations to ensure the energy is going to the correct location.