i use use indigo timer objects to implement certain behaviors. an example is detecting when no heartbeat signal has been received from an insteon leak detector device.
i was poking around in the indigo sql database and i discovered that every state change to an indigo object results in a record being added to the sql logs... my timer objects have hundreds of times more records in the database than any other type of object. i have over a dozen of them. thus, i have hundreds of millions of records in SQL representing these (largely meaningless) counter decrements.
the way timer objects are implemented in indigo would seem to be that the devices' attributes are updated every second. several device attributes change including longStatusString, and timeLeftSeconds. just as an implementation issue, i'm a bit puzzled by why a timer object should change its state every second. it seems more intuitive to me that a timer object, once set, remains essentially static (until perhaps it undergoes a change from active to inactive or something). it will get checked regularly against current time (i.e. at some fixed interval such as once per second), but i don't see much value continually updating object state (or multiple states, in this case).
i noticed that i have "store device state changes in database" checked in the plugin configuration for SQL Logger. is this the standard configuration? i may have modified this years ago and forgotten about it... offhand, seems like my system is spending a *lot* of cycles continually writing these meaningless changes to the database... (and then pushed to backups, etc.)
this seems useful for debugging, but i wonder - do i lose much if i turn this off? is this needed for example to have indigoplotd plot thermostat values and such?
my system has been doing this for years and i never really paid much attention to it. perhaps i should just forget about it and let it keep going. glad i am not paying per CPU cycle or per byte written to disk. on second thought, however, i have on a few occasions had my entire sql log db get corrupted - perhaps that was made more likely by the heavy volume of database updates i've been generating...