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

[nelgi]

Version of the custom_component

0.0.17 + PR #491

Homeassistant version

2025.10.0

Describe the bug

on 1st of October price data quadrupled, from 1h resolution to 15m resolution. As soon as the Nordpool sensor receives tomorrows data it is unable to record sensor attributes in database and History graph stops being updated, these symptoms last until midnight, when the previous day attributes are removed from sensor, and sensor size becomes below 16kB again..

Screenshot from 19:45, on the graph the senor data stopped updating at 14:15:

And another one from the following morning, indicating the cap:

Log

Logger: homeassistant.components.recorder.db_schema
Source: components/recorder/db_schema.py:663
integration: Recorder (documentation, issues)
First occurred: 14:21:22 (88 occurrences)
Last logged: 19:30:00

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

[silashansen]

I'm seeing this issue as well. For now, I think we need a way to enable 1h resolution.

This is breaking other logic that depend on the 1h resolution data.

I would really appreciate some kind of fix or workaround to get 1H resolution back - at least until we can get our logic adapted to the new resolution.

[willew]

Nordpool prices, at least in Finland, are now split into 15 min periods. This means that the logic utilizing nordpool data must understand the change, This have done and it worked on the first day ok.

To be able to utilize the full data, to my understanding, the amount of data should be decreased. I would vote for deleting the end value in the raw data, since this the same as the start value for the following entry.

[sofkaski]

To be able to utilize the full data, to my understanding, the amount of data should be decreased. I would vote for deleting the end value in the raw data, since this the same as the start value for the following entry.

I support this idea since the semantics of pricing is anyways consecutive time slots without any gaps. Obviously this is a breaking change when removing attributes.

[willew]

When looking at how OpenMeteo publishes the data, it is more compact and also includes the wished hourly data. Perhaps when a breaking change is needed, it could be a place to change the format completely.

watts: 
'2025-10-09T00:00:00+03:00': 0
'2025-10-09T00:15:00+03:00': 0
....
wh_period: 
'2025-10-09T00:00:00+03:00': 0
'2025-10-09T01:00:00+03:00': 0

[willew]

As a temporary fix (I have almost no Python skills) it looks like you can remove the end timestamp from the raw data by making the following change to sensor.py. If you make this change locally, it will be overwritten when you update the module.

    def _add_raw(self, data) -> list:
        """Helper"""
        result = []
        for res in self._someday(data):
            item = {
                "start": res["start"],
                # "end": res["end"],
                "value": self._calc_price(res["value"], fake_dt=res["start"]),
            }
            result.append(item)
        return result

[rwadev8]

the issue is the same on 2025.9.3 also, thanks @willew for the workaround.
besides eliminating the end: value i wonder if it might make sense to also just generate a single data array without the today and tomorrow differentiation. one can always compare the data against the local timestamp to figure out what is in the future.