2.2.3 Database size is now 100 readings deep, max?

In another discussion, the database of datapoints from devices was described thusly:

Is this correct? If so, this would mean that for any regularly-reported datapoint, I cannot even get one reading every 10 mins and have a dataset covering the prior 24 hours. It does not seem wise to reduce the database limit by a factor of 10.

Tagging @mike.maxwell and @bcopeland.

What are you wanting to get at the temperature readings for? Graphs? Browsing?

if my math is right, 100 events will get 24 hours at a 15min interval. For me that seems like no big deal, but yeah, it does seem like 150 events would probably not kill anybody and still be a huge reduction from 1000.

Yeah, hubigraph is just the cat's meow for... everything. Nothing makes a graphic point as graphically as a graph!

I wanna glance at a dashboard once a week or so, and see a "familiar heartbeat" for power and water consumption, entrances and exits, a few key temperatures, and such maybe 6 graphs total. But I need A WEEK of data, not a day's worth.

Its a bummer to have to work out how to get all the data off the hub and onto some kind of server, so no 2.2.3 for me! I think the choice to make the database smaller unconditionally will soon be recognized as a self-inflicted gunshot wound to the foot.

As I understand it the nightly maintenance will cull to 1000 per attribute, like it always has. The backup itself only keeps 100 though.

Checking on my hubs, that appears to be correct as I have >100 events for many individual attributes.

If you need/want more than 1000 events per attribute, then you need to setup an external historian.

EDIT: Sounds like I was wrong. Sorry.

2 Likes

So, last night I updated “Long Term Storage” for HubiGraph. It stores the data locally in the app. Can store up to a month of data (configurable) .Ran a trial last night. It worked.

6 Likes

My understanding is that nightly maintenance is what culls the database to 100 events per attribute. Thus, throughout the next 24 hours, the number of events per attribute will grow throughout the day, until the next maintenance window.

So, just after 2am, your hub will have exactly 100 events per attribute. As the day goes on that number will increase.

3 Likes

Hmm.. Oops. Thanks for correcting me, I edited my post.

You're right, the ones I was checking to validate this had exactly 100 events @ maintenance time, and the qty >100 came post-maintenance.

Sorry for the misinformation! Apparently I can't do simple math this morning. :confused:

3 Likes

I'm just annoyed that I went and checked it on my hub before posting and STILL got it wrong. Need more coffee I guess.

2 Likes

Wow, that's amazing.... precisely the solution needed. I'm sorry, I am still learning this toy, and by no means yet prepared to write any app code.

So, delete all "line graphs", and make them "time graphs"... I missed that part, as I wanted to make things work with the release I had before I updated the underlying app.

VERY Impressive!

Yes; update, delete all line graph and use time graphs. Time graphs are much more capable and support line, area, and bar graphs on the same graph. It also allows features like "dropping" the line when no updates are received and summary overlays. More importantly with the latest update, you can store your data. I have been running Time Graphs for weeks without issue on my home panel for a while. I "update" each morning using Fully Kiosk (due to FK's limitations). My wife actually likes this piece of my automation.

2 Likes

How did you setup this display? I'd love to make something like this