Persistent Store and the "Cost in Wear"

I’m curious about how dangerous it is to use the persistent store, the documentation pretty much says that you should avoid it at all costs except for things that you write once in the lifetime of the device.


Similar to the transient_store, this is for use for driver specific information, however, unlike the transient_store, information written here will be stored and persisted through restarts. This carries with it a cost in wear, as well as time delays associated with the writing and reading. This should also be accessed through the device:set_field and device:get_field methods. A good example of a target for the persistent store would be something like the number of lock codes a lock can support. This is something that only needs to be read once when the device is first joined, and won’t change for the lifetime of the device. This could be read every time the driver restarts, but it is reasonable to read once and store for the lifetime of the device. In order to protect the longevity of your hub device, we limit how frequently values are actually written to flash. This does, however, come with a potential loss of information. When the persistent store for your driver is “written” it is cached in memory and will actually be written to flash on a schedule and on graceful shutdown. This means there is potential information loss in the case of a power loss.

Will writing an integer few times a day actually decrease so badly the lifespan of the user’s hub?

I would find it useful to store info of timers that would span minutes or hours and wouldn’t survive a hub or driver restart otherwise. But not at the cost of the user’s equipment.

Hubcore takes care of that, you can’t determine when to “write”, only if you want the hub to store it permanently. It will write when appropriate (e.g. before a restart, at specific intervals etc). Obviously don’t write something you don’t need access across a restart.

1 Like

Looking at the Device module implementation it looks like the state_cache, where it saves the last state of each component, and the “persisted fields” use the same persistent store so there’s really nothing to be afraid.

For small data that needs to be persisted it’s not going to be any cost in wear compared to the regular use of the devices. Persisting a field or emitting a component value seems to be pretty much the same in terms of “cost in wear”.