ok i'm confuse. Any reason why there are so many of them then? Do they cause the DB to be so big? Can we limit them to something as well?
Yes, we realise, but it's superflous. It records every track ever played on Sonos. 7 speakers around the house. it records the weather in 5 minute increments. I'd love to turn off the ability to record these events, in the device event page.
1 Like
well you didn't show the entire event screen, nor the driver current states, but lets assume that device produces 10 types of events with a possible 5 values each, 10 * 5 * 1000 = 50000, I can't think of any other way of explaining this.
Please post a screen shot of that drivers current state...
But to your point, sure the more events in your system the bigger your database is going to be, that's where they're stored after all, and why I keep telling people not to create worthless events...
Is this what you're looking for? This is the Environmental Sensor using driver "Environment Sensor EX"
Yup, that's it.
And honestly of the 15 attributes listed only the last 4 are relevent to automations...
So if you don't want 50k events for that device day after day, then modify the driver, then delete and reinstall the device.
Adding a date, and what date that would be would make that cleanup even more complex.
But cant you just limit the total device logs to 1000 (total, not per attribute + specific 2nd attribute).
Maybe limit it to 1 week worth of events total. For those who wants more, they can setup InfluxDB.
Like I said, adding a date to it makes the query extremely complex and even more time consuming to execute, it's also not a high priority at this time.
The solution to database bloat is to use device drivers that only produce relevent events...
Events are for automations, they are not just some handy location to dump whatever you want.
Sonos driver is built in. It is beyond verbose. Why do I need to know the volume 12 months ago?
Please limit to 1000 total. Simple.
But even so... if relevant events hang around forever then that is still going to result in bloat eventually yeah?
here's how many entries i have on the weather driver. Clearly there need to be some publish guideline on this or else my DB will just keeping growing forever?
It isn't that simple, and i seriously dont have the time to explain why.
I've given you all simple ways of understanding and managing these things. In the end the actual size of the database is of little consequence, and with the exception of application calls for event history, does not impact system response.
Creation of excessive events that are of no use does impact system performance, and establishing some lower count threshold for the reqular cleanup job does not in any way prevent these events from collecting throughout the day.
Every single event attribute change value is a write to the database...
Why would you write to a database unless you needed to?, you only write items you intend to use.
This hub is not an enterprise class warehouse RDBMS...
Mike, the driver I'm referring (Sonos) is built in. It's written by you guys. I didnt write the driver.
I didn't make any comments about that driver.
I was wrong about how we select the 1k events to keep. It is simply attribute name not name and value pair. Haven't worked on that section of code for almost 2 years...
So the pruning should be keeping 1000 entries for each attribute?? So 1000 for Motion, 1000 for lux, 1000 for temp for example?
Correct
Gotcha. That at least gives an idea of how many should be there if we think the maintenance job for whatever reason isn't doing its thing. It probably would be good to have that number as a user configurable hub setting somewhere, as a 1000 seems quite a lot really, for each attribute.
I suppose it would be more useful for some attributes over others though.
