Quarter hour price update

[Teme-V]

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]

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

[peternorlander]

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

[dan-sweden]

Works 👍

[koopee]

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]

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]

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]

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]

See comments in #496

[developerfromjokela]

@Hellowlol please merge this asap

[oleg-d]

we need a 0.0.18

[AndersHoglund]

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]

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]

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]

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]

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]

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]

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]

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]

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

[friskens]

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]

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]

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]

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]

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]

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]

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]

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]

LGTM!

[mcsrobert]

So what's blocking this?

[peternorlander]

The problem with 16k attribute exists already now, with or without this PR right? The data is already there. So it shouldn't stop this PR but be threated as a separate problem.

[developerfromjokela]

So what's blocking this?

Nothing and it's getting ridiculous how long we're not approving this PR. I can't call this anything but incompetence

[peternorlander]

So what's blocking this?

Nothing and it's getting ridiculous how long we're not approving this PR. I can't call this anything but incompetence

Please, that is a really unnecessary comment. This is a nice person that has spent a lot of creating something for other people to enjoy. I understand your frustration but this person probably just have a life that came in between, so please refrain from those kind of comments.

Edit: typo

[developerfromjokela]

So what's blocking this?

Nothing and it's getting ridiculous how long we're not approving this PR. I can't call this anything but incompetence

Please, that is a really unnecessary comment. This is a nice person that has spent a lot of creating something for other people to enjoy. I understand your frustration but this person probably just have a life that came in between, so please refrain from those kind of comments.

Edit: typo

I'm sure they're nice person, but for some reason all are obsessed over a warning message that isn't related to the problem of this PR. They've had multiple opportunities to merge but didn't do so.

And it's okay to have a life, but if it leaves no time to maintain the repo with high quality, I'd suggest adding another maintainer that can actively maintain this repo.

[wizzor]

I want to also say that I feel criticizing the maintainer is not going to increase their motivation of spending their free time for our benefit.

What we can do here, is to come up with a workaround while this gets sorted out.

Can anyone recommend a good way for me to run this fork in a way that doesn't require me to change every entity ID I have? I have installed the extension via HACS.

My current plan is to simply overwrite the files in HACS's component directory with these ones and restart HA. If I'm right the IDs should remain the same, no? When the component is eventually updated, it should overwrite my changes and I live happily ever after.

That's the theory anyway.

If no one offers a better solution I will try this and report my findings so others can at least avoid whatever mistakes I end up making.

[developerfromjokela]

I want to also say that I feel criticizing the maintainer is not going to increase their motivation of spending their free time for our benefit.

What we can do here, is to come up with a workaround while this gets sorted out.

Can anyone recommend a good way for me to run this fork in a way that doesn't require me to change every entity ID I have? I have installed the extension via HACS.

My current plan is to simply overwrite the files in HACS's component directory with these ones and restart HA. If I'm right the IDs should remain the same, no? When the component is eventually updated, it should overwrite my changes and I live happily ever after.

That's the theory anyway.

If no one offers a better solution I will try this and report my findings so others can at least avoid whatever mistakes I end up making.

Nobody is criticising the author, but if he has little to no time to maintain the repo, I think it's beneficial for everybody to add new maintainers to keep the repo alive. You don't seem to get the point what I mean.

I'm not here to throw rocks at anybody, I want you guys to face the reality, nothing has been moving for a month now. You may not like or want to accept the truth, but it is the truth.

@Hellowlol do you agree? What do we do next?

[peternorlander]

I want to also say that I feel criticizing the maintainer is not going to increase their motivation of spending their free time for our benefit.

What we can do here, is to come up with a workaround while this gets sorted out.

Can anyone recommend a good way for me to run this fork in a way that doesn't require me to change every entity ID I have? I have installed the extension via HACS.

My current plan is to simply overwrite the files in HACS's component directory with these ones and restart HA. If I'm right the IDs should remain the same, no? When the component is eventually updated, it should overwrite my changes and I live happily ever after.

That's the theory anyway.

If no one offers a better solution I will try this and report my findings so others can at least avoid whatever mistakes I end up making.

Yes, that is exactly what I did on day one. I download the code for this PR and then simply dumped the code overwriting what hacs had downloaded. It's been working great since then. 🙂

[wizzor]

I promised to report back. Works like a charm. I downloaded the zip from the package, extracted it to a separate dir and copied the relevant subdirectory over the current installation.

Have been running it like this for a few days, everything looks fine. From what I can see this can be merged.

[os11k]

Can anyone recommend a good way for me to run this fork in a way that doesn't require me to change every entity ID I have? I have installed the extension via HACS.

I just added https://github.com/Teme-V/nordpool.git to HACS as custom repository, obviously first you need remove this one.

[peternorlander]

Great stuff @Hellowlol nice to see you got some spare time this christmas! Thank you! ♥️ If you feel you are running out of time to maintain this repo then maybe one of the people who did this merge would be interested to support this?

[developerfromjokela]

Great stuff @Hellowlol nice to see you got some spare time this christmas! Thank you! ♥️ If you feel you are running out of time to maintain this repo then maybe one of the people who did this merge would be interested to support this?

+1 we do need someone to maintain the repo to keep it healthy

[Tommixoft]

yeah fire Hellowlol, for doing crappy job. Close repo if don't wanna maintain it. Simple as that. 15min nordpool data fix was added here in october, and only now you able to release it so people using HACS can finally upgrade. Add people to repo so they could do that instead of you if you have no time or no longer want to do this.
No but really, problem was fixed with 3 small line changes... 3 months to release update.. geezus.

[Hellowlol]

Locking the comments because the discussion is no longer productive. Right now, it’s honestly tempting to archive or delete the repo. If anyone is genuinely interested in helping out, I’d really appreciate the support.