Is it possible to put value in the “now lable”?
Can somebody help me with the additional costs for the Norpool intergation. I use the ENTSO-e atm and when I use the template for the extra costs from ENTSO-e in Nordpool I get a higher price. I think the integration adds te price.
My template:
{% set s = {
“bijz_accijns”: 0.50329,
“energiebijdrage”: 0.002042,
“kost_gsc”: 0.01166,
“kost_wkk”: 0.00430,
“fluvius”: 0.0459,
“btw”: 1.06,
“marge_procentueel”: 1.038,
“marge_per_kwh”: 0.0393
} %}
{{((((current_price * s.marge_procentueel) + s.marge_per_kwh) + s.bijz_accijns + s.energiebijdrage + s.kost_gsc + s.kost_wkk + s.fluvius) * s.btw) | float}}
I just wanted to share my integration with lovelace. Works also in light mode but colors need to be adjusted.
- type: "custom:apexcharts-card"
graph_span: 1d
span:
start: hour
offset: -4h
experimental:
color_threshold: true
all_series_config:
color_threshold:
- value: -1
color: "#6EFDEF"
- value: 0
color: "#6EFD99"
- value: 10
color: "#FDE86E"
- value: 20
color: "#FD6E6E"
type: column
series:
- entity: sensor.***YOUR NORDPOOL SENSOR***
data_generator: |
return entity.attributes.raw_today.map((entry) => {
return [new Date(entry.start), entry.value];
});
show:
in_header: false
- entity: sensor.***YOUR NORDPOOL SENSOR***
data_generator: |
const now = new Date();
let latestData = entity.attributes.raw_today[0];
entity.attributes.raw_today.forEach(entry => {
const entryDate = new Date(entry.start);
if (entryDate <= now && (!latestData || entryDate > new Date(latestData.start))) {
latestData = entry;
}
});
return [[new Date(latestData.start), latestData.value]];
show:
in_header: true
name_in_header: false
in_chart: false
now:
show: true
label: Now
header:
show: true
title: Electricity Price
show_states: true
2 Likes
This is a good color pallet. The colors are equally spread based on human perception of color differences (with the exception of the first color which was added manually to stand out).
- value: 0
color: '#2085e3'
- value: 0.05
color: '#04822e'
- value: 0.1
color: '#12A141'
- value: 0.15
color: '#79B92C'
- value: 0.2
color: '#C4D81D'
- value: 0.25
color: '#F3DC0C'
- value: 0.3
color: '#F4C616'
- value: 0.35
color: '#EFA51E'
- value: 0.4
color: '#E76821'
- value: 0.5
color: '#E33F20'
- value: 0.6
color: '#DC182F'
2 Likes
This may be a bit old thread but I had great help designing my chart highly customizable ApexChart and wanted to share it back with the community.
3 Likes
Sorry for my lack of HA knowledge here, but suppose I’m not interested in displaying the average price of next 3 hours, but rather just have it available as a numerical value (an Entity?) to be able to use the value to change the color of a light to show the wife (and me) if it’s time to do laundry and run the dishwasher. The color change depending on current price I’ve managed, but the price for next hour I can’t access with my skill-set. It’s better than nothing, but with low price now and very high price the next hour, it misses the point.
Maybe this helps: GitHub - TheFes/cheapest-energy-hours: Jinja macro to find the cheapest energy prices
I’m not using it myself but it looks useful.
1 Like
I have a variable tariff for extra costs, similar to the example on Github. I am on a time-based tariff, so from April to October it uses the low fare, and on November 1st it starts to switch between the two tariffs. However, I discovered that future prices in the attributes are not calculated correctly.
From what I can tell, it’s using the actual current time when prices are calculated, instead of the time the price actually is for. Kind of hard to explain but here is my template sensor for my additional costs:
{% set s = {
"hourly_fixed_cost": 0.081,
"low_tariff": 0.096,
"high_tariff": 0.56,
"energy_tax": 0.428
}
%}
{% if (now().month >= 4 and now().month < 11) or (now().weekday() >= 5) %}
{{ s.low_tariff + s.hourly_fixed_cost + s.energy_tax | float }}
{% else %}
{% if now().hour >= 6 and now().hour < 22 %}
{{ s.high_tariff + s.hourly_fixed_cost + s.energy_tax | float }}
{% else %}
{{ s.low_tariff + s.hourly_fixed_cost + s.energy_tax | float }}
{% endif %}
{% endif %}
What happens is that if prices are calculated before 22:00, it will always use the high tariff. If I wait until after 22:00, all prices have changed and it’s now always using the low tariff.
I’ve filed a bug report on GitHub but I wanted to know if anyone else is experiencing the same thing, or if I might have missed something basic. It wouldn’t surprise me if this just happens to my install, because as the integration is completely useless without accurate future prices I’d imagine there would be more people complaining if it didn’t work as intended.
I also don’t know if this issue is new. I tried downgrading the Nordpool integration but then the sensor became unavailable and I don’t want to create a complete mess in my home assistant install. Please note that the current version of the Nordpool integration is 0.0.15 but it still says 0.0.14.
it’s using the actual current time when prices are calculated , instead of the time the price actually is for
I have been notified that this behavior is by design. If you want to use additional costs to calculate future prices correctly, it cannot be done through a template sensor, it needs to be done in the integration configuration directly.
I really wish the docs were clearer. For a lot of the integrations.
Anyone had any luck adding the Norwegian government subsidy of only paying 10% of any price above 0.73 NOK?
I’ve got this far through the help of chatGPT but doesn’t work
{% set s = {
"extra_cost": 0.0312,
"winter_night": 0.3028,
"winter_day": 0.4020,
"summer_day": 0.4740,
"summer_night": 0.3722
} %}
{% if current_price > 0.73 %}
{% set subsidy = 0.73 + (current_price - 0.73) * 0.1 %}
{% else %}
{% set subsidy = current_price %}
{% endif %}
{% if now().month >= 4 and now().month < 12 %}
{% if now().hour >= 6 and now().hour < 23 %}
{{ (subsidy + s.summer_day + s.extra_cost) | round(4) }}
{% else %}
{{ (subsidy + s.summer_night + s.extra_cost) | round(4) }}
{% endif %}
{% else %}
{% if now().hour >= 6 and now().hour < 23 %}
{{ (subsidy + s.winter_day + s.extra_cost) | round(4) }}
{% else %}
{{ (subsidy + s.winter_night + s.extra_cost) | round(4) }}
{% endif %}
{% endif %}
create a new nordpool sensor with “Add cost”
Change values in Bold with your own tarifs
{%set hour = now().hour%}
{%set extra = 0.0%}
{%if hour > 21 or hour < 6%}
{%set price = extra + 0.3593 %}
{%else%}
{%set price = extra + 0.5018 %}
{% endif %}
{%set threshold_for_subsidy = 0.9125%}
{%set subsidy = max((current_price-threshold_for_subsidy)*0.9,0)%}
{{(price - subsidy) | round(4)}}
Hi all! Now that the Nordpool sensor is integrated as an official integration all my Apex Charts that were using the HACS version stopped working, since the HACS version gets not loaded any more. I have now configured the official integration and it creates a bunch of sensors but none has a raw_data attribute. I’ve been looking at my lovelace code with the charts and all of it ( a mashup of code in this thread) uses the raw_values attribute in the HACS version, which is not there in the official integration. Anyone has already changed the APEX cards to work on 2024.12.0? I have tried a couple of times, but my APEX card knowledge is failing me…
Regards
1 Like
Note: unless you only want the current energy prices (with some basic sensors for the average price), don’t use the core integration.
There are talks about adding price forecasts to Home Assistant, but it’s going to take a while. Until then, the HACS and core integration each have their benefits.
Since I want to use the forecast graph, I’m only using the HACS integration and it still works as long as the core integration is not configured.
You can rename the HACS integration (to nordpool1 for example) or remove the device/service from the core integration.
The documentation for the core integration will be extended shortly (pending approval of the pull request) to better describe the sensors and how to add additional costs and VAT.
1 Like
Well, the HACS version does not work any more for me when I updated to 2024.12.0. It does not get loaded and complains about the ‘config flow’. Am I the only one with problems with the HACS version?
Thanks for the info. Since I rely heavily on the HACS version, what do you suggest med to do? I haven’t updated yet to 2024.12 just because if this…
Yes, that cost me a few hours yesterday. Tried to get the official integration working with the Apex charts “standard” code for Nordpool but realized much to late that the essential attributes where not available in the new rendition of Nordpool. Will sit on my hands for a while, waiting for an update there… With the new effect tariffs arriving I guess a broader audience would long for all sorts of e.g. best time for charging-functionality etc. of sorts.
I have been running 2024.12 since beta1 and am now running 2024.12.1.
The old HACS integration is still working fine and is reported as replacing the official integration.
If it stopped working for you, I suggest to check if it is the latest version (0.0.16).
Even so, I do question if it was wise to add a new official integration with identical name as an existing and popular custom one - especially as the official integration still is inferior to the old.
For me the old/custom integration still works as before after updating HA to 2024.12.x. I did not add the official integration.
Only difference is that now the custom integration icon is red instead of orange and hovering the mouse over it displays a message:
I got it running now. The python path inside the HA container does not find the dependencies, so I had to go into the container filesystem and fix the python path for python 3.13 so that it would work. It works now iaf
Same here.
As I was sloppy in reading the 2024.12 release note I was not aware of the now core integration. The HACS integration works unchanged.
I feel that it is a failure from the core perspective to seemingly not have collaborated more closely with the existing HACS integration community. From a layman perspective the initial step would have been to incorporate the latest HACS version, not to start a new solution from scratch, with new sensors and data structure - this does not make migration as smooth as i could be.
By raising the HACS integration to core the original work is honoured.
On other hand, there are other integration where the core solution is not up to it, resulting in a thriving HACS counterpart, time will tell where Nordpool ends up. For now I’m staying on HACS.