Small idea for further reducing json size a little

[mpw96]

In the description for 2025.12.1 your are giving this example for the new structure:

{
  "range": {
    "start_utc": "2025-12-05T23:00:00+00:00"
    "deltas_in_minutes": [15, 15, 15, 15]
    "values": [0, 1, 2, 3, 4]
  }
}

Since the field name is start_utc one could scratch the tz information from the timestamp itself:

{
  "range": {
    "start_utc": "2025-12-05T23:00:00"
    "deltas_in_minutes": [15, 15, 15, 15]
    "values": [0, 1, 2, 3, 4]
  }
}

What do you think? One could also argue that the most flexibel version is to name the field start and keep the tz information in the timestamp. Then there would be the chance to be able to handle other timezones...

[marq24]

You are right, that the _utc and ´+00:00` is doppelt-gemoppelt and I have to admit, that I had a different plan - I wanted that this value would be à int - a unix timestamp. But while I was writing the release notes, I realized that the code was not doing what I had initially wanted...

At the end I decided to keep it as it is right now... Just to get some rest in this topic - so that the users don't have the need to adopt to all the changes again and again...

When we need to further reduce the size, then I would replace the deltas_in_minutes array by a single value - since so far I have only seen constant values in this array... [and I also realized, that one value is missing in this array to make my compression fully bi-directional...

[mpw96]

When we need to further reduce the size

Can you please explain like I'm five why size is a problem? What is the limiting factor? Some response size? Does maybe pagination need to be used?

[marq24]

Home Assistant have a limit of 16384 bytes concerning the state+attribute data that can be saved in a single data point in the database.

When your (your = integration developer) attributes data exceed this size limit, the users will get a message like this:

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

See also here #214

With the change to switch the time delta from 1 hour to 15 minutes in the evcc forecast and price data the size of the evcc objects increased by factor four. That was the first time, that one of my integrations have hit this size limit for the first time this limit with the origin objects from evcc.

So that was the moment when I started to convert the existing evcc data objects to archive a smaller size. The first approach was to switch to the Unixtimestamp format (int) instead of the ISO Format that used by evcc.

[mpw96]

Hmm, I understand. Please excuse me asking (I admire this plugin and your work), but isn't that some kind of wrong design putting the whole series into one datapoint? I have no good understanding of the situation. How often is a datapoint written? Are we storing the whole series every couple of minutes/seconds? Don't bother explaining it if you have it already thought through and it's just not possible...

[marq24]

I did not spend a lot of time, trying to understand the database design of home assistant.

My current understanding is, that an entity will store all its current values as soon as the framework detects that the state (the main value of an entity) has changed. The attribute data is part of this set of values.

So yes, with every state value change the complete data-array will be stored. It could be that the framework evaluate, what part of the data set has actually changed and only stores the delta... But thats beyond my current knowledge. Home Assistant core does crazy things - crazy on the first look, but when you start to understand the edge usecases that exists, then this crazy stuff can become smart... well at least sometimes.

As integration developer I just can use what exists in the core... well this is not true... I can implement my own persistance and all other stuff by myself... but this is IMHO not the idea of an integration.

When the user want to display a time series that is going into the future, then to my best knodlege this is only possible via an entity that is providing a data list (and not a single value). I have not tried yet, to manually create a data point for an entity (and manipulating the timestamp).

So (again that is just my current knowledge) providing the forecast & tariff data via the attributes of an entity is the only option I have (when I want to stric to the standard of the core).

Thats also a reason, why these entities are not enabled by default. I have the hope, that the users have the pricing and solar forecast data anyhow in theier HA via other integrartions.

[mpw96]

Thank you for the explanation.

[mpw96]

Oh, btw, with 2025.12.4 I seem to be getting -15 (and not 15) as deltas_in_minutes:

[marq24]

that is a rendering issue of HA... they display all entries as bulletin list items. When you access the object via the templates you will see, that this is 15.

[mpw96]

Thank you. Facepalm.

[mpw96]

Frohe Ostern!