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.
EDIT: Sounds like I was wrong. Sorry. It does cull everything to 100 events at maintenance time - not just the backups.
Sorry for (unintentionally) spreading misinformation.
So the backup only saves the most recent 100 events to the backup file AND the device database is also purged?
This makes me think that I have "misunderestimated" estimated something, as the purge will drop the last hours in the day of anything reported or polled at an interval greater than 15 mins. So, weather, power, water, and motion are going to be truncated in the backups, unless there is some way to separately backup the WHOLE event database as a stand-alone file.
The problem with "motion" is that vegetation waving in the breeze, feral cats, birds visiting the feeders, and even the rippling of the pool surface can set of motion detectors. It is hard to get a "minimum motion" defined for the few that allow such settings.
Weather data I can get elsewhere, of course. Just a shame I can't monitor it with a purported "central home automation hub". Its no longer the core device, I guess a Raspberry PI or something with an attached NAS drive will have to become the true "core", and the Hubitat a mere peripheral.
Power, and water are obvious - less resolution means that I don't see a familiar "heartbeat" with the little spike at the start of every fridge cycle (the starting current of a motor is always higher than the running current) to show that it is the fridge, I just see a spike of so many watts. I end up with peaks and square waves.
With water... is the toilet leaking every time it flushes, or are the groundskeepers just doing a far better job of washing their hands after using the toilet in these days of pestilence? At 15-min intervals, I'll never know unless I get lucky, and the water leaking his a leak sensor before it does damage.
Almost not even worth the very high cost of the devices to monitor consumption if the data is just going to get dropped on the floor at any decent resolution.
So, I am not just flying blind during the maintenance window, I have amnesia for any event that would be hidden in the noise at a 15-minute interval, or I loose all data collected for some interval before the nightly 2am purge.
I'm going to have to think about this - when I was a postdoc TA, I had to teach the Nyquist–Shannon sampling theorem, so I kinda think I have a problem here. 
I believe that is correct.
There are several ways you can do this yourself (a node-red flow using sqlite is one simple method).
Hubitat’s decision to truncate events in backups doesn’t prevent individual consumers who need more events from doing that for themselves. Indeed, they provide the basic tools necessary for this - such as a WS interface or Maker API.
Hubigraphs app has "long term storage", said to be good for a month of data, so my complaint is mooted, and anyone else can apparently make their own "backup" with an app, once one learns this toy's avionics.
I'm thinking a feature request to make the number settable, say 10-1000.
The database pruning is a job that runs around 2am, just before the automated backup. It is not in line with the event commits.
With few exceptions there is no corelation of retained event counts and hub performance.
Backups take longer and specific methods that fetch event history (not current value) take longer...
It is well thought out once you understand that Hubitat is an event driven automation system, not a data warehouse.
So would it be a PITA to make the number configurable, Mike?
It is already, ping Bobby and he will get you the route...
You can set up a max of 2000 number of events per device/app by using http://yourHubIP/hub/advanced/event/limit/100 link/command.
Just replace yourHubIP with your hub's IP and 100 with number of events to keep
You can check the current max number by accessing:
/hub/advanced/event/limit
@mike.maxwell - No worries, my data warehouse is covered by Hubigraphs "Long Term Storage"... you should get that fellow under contract, as he is adding some serious value there.
There's a thread for that 
.
If you have absolutely no temp data at all, then yes, your database will be marginally smaller. But think of it this way, I have maybe 2 dozen sensor that report temp data, almost every one of them Iris V2 contact or motion. And I have had my system long enough that my database has maxed out. And even when it was at 10000 events the database was still only 14mb. Now it's down to <4. So, again, I fail to see how your database will be out of control with the number of events you are talking about.
You've had your hub for how many months? I've had mine for over 2 years. The database did not continue to grow for the last 2 years. At one point, it stops getting any larger because you have maxed out the number of events that you will log.
No it will not!!! You're not talking about "SOO MUCH" data. Each event is only a few bytes of data. We're not talking the library of congress here. Don't you think if that was the solution to make the hub faster that Hubitat would have done this LONG ago? I mean, stop and think about it for a second. This product is almost 3 years old.
But let me see if I follow you....now you have a problem that the number was reduced? So, you want more events stored? But less of them per device? You seem to want everything. If you want long term logging, you can always log in an outside system too.
While I appreciate the viewpoint from someone who has owned/used a Hubitat longer, there is no need to argue, moreso in the wee hours of a Saturday night.
Joy cometh in the morning, and once again, I can bring some small amount of joy into the discussion.
The database issues (which are admittedly a little complex, but are better explained in my 1996 treatise on databases, if you can find a copy via Amazon: https://www.amazon.com/Special-Using-Informix-James-Fischer/dp/0789706601 or Goodreads: Using Informix by James H. Fischer ) are resolved completely by Hubitat's ruthless daily purging of the database down to a mere 100 events (for people who have no need of historical data), and the "Long Term Storage" option in Hubigraphs, which allows one to keep as much data as one likes for individual sensors of interest.
any links to the not-special edition?
I'm a "Han shot first" kind of guy, so I usually prefer the originals.
"Special Edition" was used by Que books to describe an entire series of books that were not only so thick they could be used as murder weapons, but also included a CD of software of one sort or another, as these were the dark days of dial-up internet, when 56Kbps was considered "fast", and things like github did not yet exist.
Informix was mortally wounded by a stock-pumping and insider stock trading scandal in 1997, shortly after the book was published, and was bought and sold several times, ending up being owned by IBM, so there was no reprinting, or 2nd edition, and in the supercomputing biz, very few people were happy with what IBM did to the codebase, so just about everyone moved to other databases.
The book is so rare, >>> I <<< don't even have a physical copy any more, gave 'em all to friends.
I noticed it's a paperback, and I had a similar thought: "This could crush a human skull far more effectively if only they had gone with a hardcover."
For a clean, humane kill, one simply MUST reach for the O'Reily Sendmail book (aka the "bat book"), as it weighs in at 1300+ pages, as it has for decades.
A accurate one-handed throw of the bat book across an office is considered the mark of a true old skool geek, as the combination of grip strength and bicep/tricep strength is not found in the current generation of bearded hipsters, as they do not change their own oil, and have never seen a raised floor, a punchcard, or a KSR-33 with papertaper reader, nor had to muscle any of them into place or aside when working the beasties of old.
Download the Hubitat app
