What is the correct way to have a persistent state with Edge? In groovy I would just set “state.something” to whatever. I assume this is documented somewhere now, so can someone please point me to where it is documented. I did a search in the StartThings Developers Documentation, but I did not find anything useful. Also, it seems like searches in the forum are returning a lot of groovy related old documentation which is not useful. Even as I write this the system is suggesting I look at a posting from 2014.
@csstup Thank you for this posting. I have a few questions: 1) since [set|get]_field() are used for both, how do you know if you are writing/reading to the transient store or persistent store? 2) Where do you set up the data store? During init? 3) Any examples?
Look at the documentation. It discusses that set_field(…, true) sets it as persistent vs transient. There’s only 1 namespace for both transient and persistent.
You can save data to the datastore where ever it makes sense. It could be during driver init, during device add, as a response to a message from a device, etc. The documentation makes a note about a slight delay in committing to flash but otherwise you consider it persisted when requested.
Thank you. I did read the documentation, just not the specific details of the method call. I see that now. It would be good if in the summary section of persistent store vs transient store they would say this as well. As it reads, there is nothing specifying what is different about accessing the persistent store until you read the description of the method. While the documentation is not incorrect, it is not very clear. Also, it is not set_field(...,true) as you specify, but a table where the persist field is set to true. The way it is documented is also confusing.
For example, instead of
“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”
This:
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. Writing to the persistent store requires that the `additional_params’ parameter value be set to {persist = true} as documented below
@csstup Have you experienced any oddities with set_field not actually persisting a value? I have a piece of test code that saves a value in all of my devices within the driver. It works in all but a single type of device. The device is a bridge with children. I have yet to reproduce it in a sample driver, but as of now, I think it is a bug with devices holding children.
Edit: Maybe it is also related to the device_network_id which is different for that type of device. I know they store values with some sort of key based on the device. Maybe there is some odd logic there.
Not that Ive noticed. I’ve not used type CHILD in production as my usecases don’t find it all that useful. For Mira I use LAN devices with device_network_id/parent_device_id. With CHILD you use parent_assigned_child_key, no?
No. I am using parent_device_id as well. I create a hub device, and then created connected children, setting their parent_device_id. To clarify, only the persistence isn’t working. set_field works for that run of the driver. The values are just gone on restart.
Checked that as well. As a sanity check, I hardcoded a bunch of different field names in there. It happens with all fields on both of my hub devices in that driver. Wondering if the storage is just corrupt at this point.
I need to build a sample driver to see if I can reproduce it and send to the ST team