view history data

[michapr]

Hi,
thank you for this great integration!

A question - what will happen with older data removed from states table in database?
Is it possible to view the history data from statistics / statistics_short_term tables? Will it taken by default then?

(Could not try it because I just some days ago try to move to HA ;) ...)

Thanks!

[dbuezas]

That's a brilliant idea!
At the moment, the card only reads from the "short term" history from here, namely /api/history/period/<timestamp>

Do you know how to access the statistics via the API?

[dbuezas]

I'm not quite sure what you are after. Could you invent a yaml that would do what you need? (Just assume the feature existed)

[michapr]

Hi, I have no ready yaml for this.
I made an additional table in SQL database for ("middle-term") statistics - it will not be purged by system after x-days. So I have the short-term values from HA, the long term values from HA (grouped by 1h) - and my values (grouped by 10min - for 30days).
For create a chart I make device.csv for these devices and read this csv via JavaScript call. This is realized just now in ApexChart.

Additional want to show the average value of 2 sensors (temperature) and the minimum value of sensors in greenhouse - without creating a new sensor with template. This are only a few ideas - what could be possible if make the data generation dynamic (like in ApexCharts).

So this is not a real missing feature, but a "nice to have" ;)

[dbuezas]

I see. you can make javascript calls inside the lambda, and then map the timestamps in the x axis to dates.
`{x: xs.map(x => new Date(x)), y: your_y_array}´
Check the docs for Date here.

To be honest, native support for that is a bit far fetch at the moment. It depends too much on your specific use case. But still thanks for the suggestions!

[michapr]

Ah, ok, if I can make javascript calls inside here - all is fine!

The more interesting part (for most users, I think,...) is the statistics table access below ;)

THANKS!

[dbuezas]

yes, the lambda is pure javascript! you can share things between plots by writing things to window (window.chart1 = {x,y}) it is very hacky, but it will work.
And yes, the statistics table is really interesting. I'm short on time at the moment but will take a look when I can :)

[michapr]

I have seen that in statistics-graph the statistics table seems to be used. Maybe you can check it - how they access to it?

Would be really nice to have the possibility to check older data ;)

[FrnchFrgg]

No, at least this particular API is "ask and get". The real question is not really how the cache class stores the histories. I saw in fetchSingleRange() that entries stored in history are essentially the entries returned by HA's API with entry.state modified if the user asked for an attribute, and entry.last_updated modified too.

I also saw that the user can get access to the actual entry in lambda. My question is "what content of entries is expected/used by the graphing code besides entry.state and entry.last_updated" and consequently "what mandatory content should I provide in that structure".

[dbuezas]

All without a question mark (optional) in the type of the history object

[FrnchFrgg]

What happens with extraneous fields in the state object returned by HA API ? Are they ignored if not present in the type ? Included anyway ? Or is there an error because the type doesn't match (in that case how are you sure that HA will not include new fields in state objects) ?

If the extraneous fields are not included then my initial plan of caching the statistics object and adding suitable state and last_*ed fields will not do. The interesting part with this approach is that users would then have access to the complete object and thus all of mean, min, max, start, end fields and would thus be able to do interesting things in lambda will all this info.

[dbuezas]

What happens with extraneous fields in the state object returned by HA API ?

Yes, ignored. The types in typescript are compile time only.

I just gave this a quick test, and it is indeed a good fit! :)
Switching to WS for the normal history may also make things slightly snappier, good finding!
I'll wait for your PR :)

I suggest the user can pick statistics vs normal by either:

• appending ::statistics::min (or max or mean or sum), or
• via an extra property in the entity trace

- entity: sensor.xyz
  statistics: min

I like the idea of dumping all attributes for usage in lambdas too. Maybe inside a sub attribute "statistics"
Anyway, I'll give feedback on the pr. Looking forward to it

[FrnchFrgg]

Can you take a look at https://github.com/FrnchFrgg/lovelace-plotly-graph-card/tree/statistics ? That's my first try, probably with a lot of mistakes since I don't have yet an npm environment setup and this code has not been built nor run. It is late tonight so I'll postpone setting one up to tomorrow.