Quarter hour price update #491

Teme-V · 2025-09-30T23:42:56Z

Update sensor price every quarter hour

maakuth

Works as described in my system

victorwm7

Works for me too! Thanks for fast programming! 👍

nelgi

I have checked these modification on 2 different systems and they seem to work without errors.

Newspaperman57 · 2025-10-01T09:03:56Z

For reference, this PR fixes issues #496 and #477

peternorlander · 2025-10-01T09:42:32Z

Works for me as well, great work - thanks! 🥇

dan-sweden · 2025-10-01T09:54:59Z

Works 👍

koopee · 2025-10-01T10:20:48Z

Does this take into account situations, where the price does not change every 15 minutes?
I'm thinking would it work if the next update time would be taken from each period end_time

Newspaperman57 · 2025-10-01T10:43:57Z

Does this take into account situations, where the price does not change every 15 minutes? I'm thinking would it work if the next update time would be taken from each period end_time

The only nordpool market NOT on 15-minute MTU in DayAhead is ireland, which is on 30 minutes. In that case, every other update will just return the same price, since the sensor updates every 15 minutes

koopee · 2025-10-01T10:54:56Z

The only nordpool market NOT on 15-minute MTU in DayAhead is ireland, which is on 30 minutes. In that case, every other update will just return the same price, since the sensor updates every 15 minutes

Fair enough. I was just fancying myself of an implementation that would work on any intervals if they are for some reason ever to be changed again in the future.

I had also some time ago problems with the nordpool sensor updating more often than the actual price updates and made a request to make state changes more robust and predictable: #379

nsimb · 2025-10-01T10:56:09Z

added the changes manually to my files and it works, it now updates the prices to reflect the 15 min interval on the sensor (sorry i know i should probably help out in a more proper way but have not learned how yet) still since I did some manual tests I thought it would not hurt to add the comment

kristofferwiklund · 2025-10-01T12:49:23Z

See comments in #496

developerfromjokela · 2025-10-02T14:46:14Z

@Hellowlol please merge this asap

oleg-d · 2025-10-02T19:55:21Z

we need a 0.0.18

AndersHoglund · 2025-10-03T07:42:50Z

Thank you, works very well. Except for one little thing, the quick/small history you get when just clicking the entity. Seems as afternoon numbers are missing. Full history works fine. This PR probably triggers a problem in that history card.

AndersHoglund · 2025-10-03T08:14:40Z

There are still symbols and comments referring to hourly prices that needs to be fixed. Here:

$ grep -ril hour .
custom_components/nordpool/aio_price.py
custom_components/nordpool/events.py
custom_components/nordpool/services.yaml
custom_components/nordpool/services.py
custom_components/nordpool/sensor.py
custom_components/nordpool/const.py
custom_components/nordpool/__init__.py
custom_components/nordpool/misc.py
README.md
lovelace_example/README.md

Do a grep -rin . for full details.

developerfromjokela · 2025-10-03T08:16:50Z

There are still symbols and comments referring to hourly prices that needs to be fixed. Here:


$ grep -ril hour .

custom_components/nordpool/aio_price.py

custom_components/nordpool/events.py

custom_components/nordpool/services.yaml

custom_components/nordpool/services.py

custom_components/nordpool/sensor.py

custom_components/nordpool/const.py

custom_components/nordpool/__init__.py

custom_components/nordpool/misc.py

README.md

lovelace_example/README.md

Do a grep -rin . for full details.

Symbols don't matter, what matters is the logic. it could be just comment lines, not actual code.

AndersHoglund · 2025-10-03T08:29:38Z

Symbols don't matter, what matters is the logic. it could be just comment lines, not actual code.

Comments and symbols must match actual code for readable and maintainable code. Basic rule.

developerfromjokela · 2025-10-03T08:31:33Z

Symbols don't matter, what matters is the logic. it could be just comment lines, not actual code.

Comments and symbols must match actual code for readable and maintainable code. Basic rule.

What I'm saying is that did you just run grep and post the results or did you also check each file and the occurrence of it?

Newspaperman57 · 2025-10-03T08:35:01Z

There are still symbols and comments referring to hourly prices that needs to be fixed. Here:

$ grep -ril hour .
custom_components/nordpool/aio_price.py
custom_components/nordpool/events.py
custom_components/nordpool/services.yaml
custom_components/nordpool/services.py
custom_components/nordpool/sensor.py
custom_components/nordpool/const.py
custom_components/nordpool/__init__.py
custom_components/nordpool/misc.py
README.md
lovelace_example/README.md

Do a grep -rin . for full details.

I did some of the work in this PR: #497

I agree that the changes should be done, but i believe in "make it work, then make it pretty", so while it's important to make maintainable code, first and foremost it should work, and right now it's not, which is why i closed the PR in favour of this one.

I'm not going to finish my PR with the Readme-files and changes to the apex-chart, etc, so someone else feel free to fork my repository and continue

mtrekker · 2025-10-04T06:59:03Z

Is #491 now somehow causing conflicts for HA Core 2025.10.1 (October 3) ?

Nord Pool 15 minute interval was was fixed in Core (#153350) and there is also #491.

@Newspaperman57

AndersHoglund · 2025-10-08T15:37:37Z

Yesterday HA stopped showing and recording new NordPool prices. Last entry at 23:45. Needed a HA restart to start working again.

Then I see this in the logs:

Logger: homeassistant.components.recorder.db_schema
Source: components/recorder/db_schema.py:663
integration: Recorder (documentation, issues)
First occurred: 13:26:35 (17 occurrences)
Last logged: 17:15:00

State attributes for sensor.nordpool_kwh_se3_sek_3_10_0 exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored

AndersHoglund · 2025-10-08T15:56:08Z

This log entry also shows up from time to time, not sure what it means. Maybe a side effect of above size warning.?

Logger: homeassistant.components.sensor.recorder
Source: components/sensor/recorder.py:275
integration: Sensor (documentation, issues)
First occurred: 13:30:10 (1 occurrence)
Last logged: 13:30:10

The unit of sensor.nordpool_kwh_se3_sek_3_10_0 is changing, got multiple {None, 'SEK/kWh'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (SEK/kWh). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this

sippe2 · 2025-10-08T23:14:42Z

Yesterday HA stopped showing and recording new NordPool prices. Last entry at 23:45. Needed a HA restart to start working again.

Then I see this in the logs:

Logger: homeassistant.components.recorder.db_schema
Source: components/recorder/db_schema.py:663
integration: Recorder (documentation, issues)
First occurred: 13:26:35 (17 occurrences)
Last logged: 17:15:00
State attributes for sensor.nordpool_kwh_se3_sek_3_10_0 exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored

Actually same happened here. I just restarted the Nordpool entities and everything worked again but I have feeling that something strange is happening under code...

AndersHoglund · 2025-10-09T12:01:05Z

Theory on the missing afternoon price in the small/quick history view.
At this time, the next day prices become available and the entity with all its attributes basically doubles in size. Probably too big for this history card. The logged size warning must be taken seriously and fixed before merging this PR.
/A

AndersHoglund · 2025-10-12T07:58:24Z

Suggestion, remove the raw_* data attributes.

nordpool$ git diff master
diff --git a/custom_components/nordpool/sensor.py b/custom_components/nordpool/sensor.py
index 2db5a96..e933981 100644
--- a/custom_components/nordpool/sensor.py
+++ b/custom_components/nordpool/sensor.py
@@ -387,8 +387,6 @@ class NordpoolSensor(SensorEntity):
             "today": self.today,
             "tomorrow": self.tomorrow,
             "tomorrow_valid": self.tomorrow_valid,
-            "raw_today": self.raw_today,
-            "raw_tomorrow": self.raw_tomorrow,
             "current_price": self.current_price,
             "additional_costs_current_hour": self.additional_costs,
             "price_in_cents": self._use_cents,

EDIT: never mind. Do not do this, there are other integrations depending in those attributes.
For example EV Smart Charging. https://github.com/jonasbkarlsson/ev_smart_charging

peternorlander · 2025-10-12T10:31:48Z

Hi, For me, removing the raw attributes is a deal breaker. I use those for all of my automations of when to use the planned electricity usage. I scan through those and select when to heat my house, water, pool, charge the car and so forth. I think those are the great thing about this integration?

…

On Sun, 12 Oct 2025, 09:58 Anders Höglund, ***@***.***> wrote: *AndersHoglund* left a comment (custom-components/nordpool#491) <#491 (comment)> Suggestion, remove the raw_* data attributes. nordpool$ git diff master diff --git a/custom_components/nordpool/sensor.py b/custom_components/nordpool/sensor.py index 2db5a96..e933981 100644 --- a/custom_components/nordpool/sensor.py +++ b/custom_components/nordpool/sensor.py @@ -387,8 +387,6 @@ class NordpoolSensor(SensorEntity): "today": self.today, "tomorrow": self.tomorrow, "tomorrow_valid": self.tomorrow_valid, - "raw_today": self.raw_today, - "raw_tomorrow": self.raw_tomorrow, "current_price": self.current_price, "additional_costs_current_hour": self.additional_costs, "price_in_cents": self._use_cents, — Reply to this email directly, view it on GitHub <#491 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKPWGQTKSPENVZDMMUHIH33XIC3NAVCNFSM6AAAAACH6L5LD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJUGA2DSMZYHE> . You are receiving this because you commented.Message ID: ***@***.***>

developerfromjokela · 2025-10-12T10:55:47Z

Suggestion, remove the raw_* data attributes.


nordpool$ git diff master

diff --git a/custom_components/nordpool/sensor.py b/custom_components/nordpool/sensor.py

index 2db5a96..e933981 100644

--- a/custom_components/nordpool/sensor.py

+++ b/custom_components/nordpool/sensor.py

@@ -387,8 +387,6 @@ class NordpoolSensor(SensorEntity):

             "today": self.today,

             "tomorrow": self.tomorrow,

             "tomorrow_valid": self.tomorrow_valid,

-            "raw_today": self.raw_today,

-            "raw_tomorrow": self.raw_tomorrow,

             "current_price": self.current_price,

             "additional_costs_current_hour": self.additional_costs,

             "price_in_cents": self._use_cents,

EDIT: never mind. Do not do this, there are other integrations depending in those attributes.

For example EV Smart Charging. https://github.com/jonasbkarlsson/ev_smart_charging

I also chime in, to not remove them. They are very useful for automation and most importantly, rendering proper charts!

Hellowlol · 2025-10-12T11:08:12Z

I think the best solution is to create two sensors one for today and one for tomorrow that way it is possible to keep the raw

developerfromjokela · 2025-10-12T11:09:37Z

I think the best solution is to create two sensors one for today and one for tomorrow that way it is possible to keep the raw

When are you gonna merge this PR? People are waiting 😅

Hellowlol · 2025-10-12T12:11:03Z

It cant be merged as is as this introductions other serious issues.

developerfromjokela · 2025-10-12T12:12:58Z

It cant be merged as is as this introductions other serious issues.

what issues? maybe I missed something, but for me it's been problem free experience for the past week.

sippe2 · 2025-10-12T21:09:30Z

Hello @Hellowlol @Teme-V

Could this issue be solved by not storing the heavy list attributes in the database at all? That way the attributes would remain usable, and as far as I can tell we’d at least avoid exceeding the 16384-byte limit. I can’t think of a reason the lists need to be written to the database, so perhaps those could simply be omitted. This might be one possible solution.

I have this kind of workaround at the moment and looks like it works.

Under sensor.py

class NordpoolSensor(SensorEntity):
    "Sensors data"

    _attr_device_class = SensorDeviceClass.MONETARY
    _attr_suggested_display_precision = None
    _attr_state_class = SensorStateClass.TOTAL
    # Do not write list attributes to database.
    _unrecorded_attributes = frozenset({"raw_today", "raw_tomorrow", "today", "tomorrow"})

friskens · 2025-10-13T00:21:15Z

Regarding the 16384Byte limit i just removed the endtimes in my code thus cutting bytewise size into almost half and now it all fits in "one" sensor "block", I'm a heavy addict of carcharger and diverse electric usage appliances and i've yet to find any Integrations that use the endtimes for anything. Could this perhaps solve something (I added a 23:45 endtime back into the code to "mark" the end of the day). Seems everyone has remained sane and not used the START and END time for blocks instead just extrapolating from when the next "expensive" time after it starts to mark the end of the previous one thus saving tons of redundant code ...

peternorlander · 2025-10-13T05:42:42Z

I have actually started to use the end date. I use it for two purposes: 1. Determine the length of the slot, I built this so it automatically would work then switching between 1h to 15min MTU. So I know how much charge I will get and so forth. 2. Determine which points are next to each other after certain slots have been filtered out.

…

On Mon, 13 Oct 2025, 02:21 friskens, ***@***.***> wrote: *friskens* left a comment (custom-components/nordpool#491) <#491 (comment)> Regarding the 16384Byte limit i just removed the endtimes in my code thus cutting bytewise size into almost half and now it all fits in "one" sensor "block", I'm a heavy addict of carcharger and diverse electric usage appliances and i've yet to find any Integrations that use the endtimes for anything. Could this perhaps solve something (I added a 23:45 endtime back into the code to "mark" the end of the day). Seems everyone has remained sane and not used the START and END time for blocks instead just extrapolating from when the next "expensive" time after it starts to mark the end of the previous one thus saving tons of redundant code ... — Reply to this email directly, view it on GitHub <#491 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKPWGTEVDQDC6PKB6UT4U33XLWBDAVCNFSM6AAAAACH6L5LD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJVGUYDQOJRGQ> . You are receiving this because you commented.Message ID: ***@***.***>

sippe2 · 2025-10-13T06:09:06Z

I have actually started to use the end date. I use it for two purposes: 1. Determine the length of the slot, I built this so it automatically would work then switching between 1h to 15min MTU. So I know how much charge I will get and so forth. 2. Determine which points are next to each other after certain slots have been filtered out.

Same here. If you have time, just try my solution if it's possible for you.

peternorlander · 2025-10-13T06:32:43Z

I have actually started to use the end date. I use it for two purposes: 1. Determine the length of the slot, I built this so it automatically would work then switching between 1h to 15min MTU. So I know how much charge I will get and so forth. 2. Determine which points are next to each other after certain slots have been filtered out.

Same here. If you have time, just try my solution if it's possible for you.

I have been running this PR since it was pushed. I see the error in logs and from what I understand of the log message it states "Attributes will not be stored". And that is just what you are proposing to do, so your solution sounds nice and easy. Not sure what happens if those attributes aren't stored. For example upon restart I guess the data will be missing and it would need to fetch the data again?

jonasbkarlsson · 2025-10-13T07:06:57Z

Hello @Hellowlol @Teme-V

Could this issue be solved by not storing the heavy list attributes in the database at all? That way the attributes would remain usable, and as far as I can tell we’d at least avoid exceeding the 16384-byte limit. I can’t think of a reason the lists need to be written to the database, so perhaps those could simply be omitted. This might be one possible solution.

I have this kind of workaround at the moment and looks like it works.

Under sensor.py
class NordpoolSensor(SensorEntity):
    "Sensors data"

    _attr_device_class = SensorDeviceClass.MONETARY
    _attr_suggested_display_precision = None
    _attr_state_class = SensorStateClass.TOTAL
    # Do not write list attributes to database.
    _unrecorded_attributes = frozenset({"raw_today", "raw_tomorrow", "today", "tomorrow"})

I have been using _unrecorded_attributes for a long time in another integration to avoid the 16384-byte limit. So I think this is the solution.

AndersHoglund · 2025-10-13T07:32:38Z

Makes sense to not record those large lists. But will that solve issues with other integrations or automations having too small sensor buffers? (or maybe this is a non-issue?)
Question is why there are two forms of the same data, when there are size restrictions, today vs raw_today and tomorrow vs raw_tomorrow? If the raw_ variant can't be removed, maybe the other could?

sippe2 · 2025-10-13T14:34:00Z

Makes sense to not record those large lists. But will that solve issues with other integrations or automations having too small sensor buffers? (or maybe this is a non-issue?) Question is why there are two forms of the same data, when there are size restrictions, today vs raw_today and tomorrow vs raw_tomorrow? If the raw_ variant can't be removed, maybe the other could?

Removing features after the fact should always be done with serious consideration. This integration has existed long enough that many other integrations and functionalities undoubtedly rely on these attributes. In this case, removing attributes doesn’t seem justified simply because someone doesn’t need them. Any removal or change will inevitably break other functionality for many users, making the integration unusable from their perspective or forcing significant rework to restore functionality by other means. We cannot assume that what isn’t important to me isn’t important to someone else. There are multiple ways to solve the 16-kilobyte limit, so removing attributes is not justified in an established, widely used integration. I suggest considering solutions more "kindly".

In my view, the best fix is simply to keep the list-type attributes out of the recorder. That way nobody loses the attributes they rely on. I also struggle to see why these lists should be stored or what value it adds... unless we’re talking about something like Holt-Winters style forecasting with seasonality for data analytics, and even then there are probably better places to do that than a Home Assistant and integration. :)

developerfromjokela · 2025-10-13T16:43:20Z

I don't understand why issue with 16k bytes is brought to this PR, can @Hellowlol just merge this PR asap and then we can figure issue with 16k in another PR?

I think this PR is more important than 16k issue which has no harm in it.

developerfromjokela · 2025-10-24T08:28:12Z

LGTM!

Teme-V added 2 commits October 1, 2025 02:40

Quarter hour price selection

5c15217

Update sensor every quarter hour

1df0aaa

maakuth approved these changes Oct 1, 2025

View reviewed changes

victorwm7 approved these changes Oct 1, 2025

View reviewed changes

This comment was marked as duplicate.

Sign in to view

victorwm7 approved these changes Oct 1, 2025

View reviewed changes

This comment was marked as duplicate.

Sign in to view

nelgi approved these changes Oct 1, 2025

View reviewed changes

Newspaperman57 mentioned this pull request Oct 1, 2025

Implement quarterhourly prices #497

Closed

developerfromjokela approved these changes Oct 2, 2025

View reviewed changes

nelgi mentioned this pull request Oct 2, 2025

Nordpool sensor attributes not recorded in database because maximum sensor size of 16kB exceeded #499

Open

AndersHoglund mentioned this pull request Oct 12, 2025

If Nordpool sensor has values past midnight in raw_today, EV Smart Charging does not pick it up. jonasbkarlsson/ev_smart_charging#425

Closed

koopee mentioned this pull request Oct 13, 2025

16k attribute limitation #504

Open

jonasbkarlsson mentioned this pull request Oct 16, 2025

16k attribute limitation #505

Open

Yatzi050 mentioned this pull request Oct 29, 2025

15-minute MTU instead of 60-minute MTU. #501

Open

Quarter hour price update #491

Are you sure you want to change the base?

Quarter hour price update #491

Conversation

Teme-V commented Sep 30, 2025

Uh oh!

maakuth left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

victorwm7 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as duplicate.

Uh oh!

This comment was marked as duplicate.

Uh oh!

nelgi left a comment

Choose a reason for hiding this comment

Uh oh!

Newspaperman57 commented Oct 1, 2025

Uh oh!

peternorlander commented Oct 1, 2025

Uh oh!

dan-sweden commented Oct 1, 2025

Uh oh!

koopee commented Oct 1, 2025

Uh oh!

Newspaperman57 commented Oct 1, 2025

Uh oh!

koopee commented Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nsimb commented Oct 1, 2025

Uh oh!

kristofferwiklund commented Oct 1, 2025

Uh oh!

developerfromjokela commented Oct 2, 2025

Uh oh!

oleg-d commented Oct 2, 2025

Uh oh!

AndersHoglund commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AndersHoglund commented Oct 3, 2025

Uh oh!

developerfromjokela commented Oct 3, 2025

Uh oh!

AndersHoglund commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

developerfromjokela commented Oct 3, 2025

Uh oh!

Newspaperman57 commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mtrekker commented Oct 4, 2025

Uh oh!

AndersHoglund commented Oct 8, 2025

Uh oh!

AndersHoglund commented Oct 8, 2025

Uh oh!

sippe2 commented Oct 8, 2025

Uh oh!

AndersHoglund commented Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AndersHoglund commented Oct 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

peternorlander commented Oct 12, 2025 via email

Uh oh!

developerfromjokela commented Oct 12, 2025

Uh oh!

Hellowlol commented Oct 12, 2025

Uh oh!

developerfromjokela commented Oct 12, 2025

Uh oh!

Hellowlol commented Oct 12, 2025

maakuth left a comment •

edited

Loading

victorwm7 left a comment •

edited

Loading

koopee commented Oct 1, 2025 •

edited

Loading

AndersHoglund commented Oct 3, 2025 •

edited

Loading

AndersHoglund commented Oct 3, 2025 •

edited

Loading

Newspaperman57 commented Oct 3, 2025 •

edited

Loading

AndersHoglund commented Oct 9, 2025 •

edited

Loading

AndersHoglund commented Oct 12, 2025 •

edited

Loading

sippe2 commented Oct 12, 2025 •

edited

Loading