Improved handling of repeated sensor values (which are presently ignored)

True, “issues” and similar like this have been and will continues to rise, do to the ever increasing features/integrations etc. Size of DB-State/Event-Machine, is “named” as “cause”. I have been/seen other issues ( Forecasts, Attributes etc )
My initial thoughts and still “valid” in my opinion is … Let people Choose/Mandatory or by Option, whether which Entities they want/need in their DB, i believe most people are “aware” of what’s important for them,
And if they don’t they also have to be aware of the fact that. Every thing comes with a Price.
If people want it all, take this into account when dimension their Solution, Or be prepared for an MEM/DISK/CPU expansion by time.
Current architecture Is, record ALL, ALL states/states-changes/events , By Default ( Making people (some) not aware of the consequences, i.e ( some want, or “accidentally” , create a template, or set an entity to “update” every second, instead of i.e every minute, or 10min (Math), … some are not even aware how much is actually “Stored/recorded”, maybe because they have no use of this/certain Data.

So (to make a long story short) Let people choose, what they need/want to store/record, initially during setup of a device/entity/integration, or whenever. This make People “Aware” of what they are “dealing with”
By default storing/recording ALL, make people Unaware, of how things works, and what the consequences of their behavior/actions will result in

PS: Yes, I have only “Include” in my Recorder settings ! (so far :slight_smile: ), so no arguments here :wink: , im referring to the fact that many people have NO idea how much OR what is actually Stored/Recorded, And most likely just have a “weak” idea of what a DB(+recorder) is/do, it just sounds like a good/practical thing ( until it’s causes problems)