rbdubz3 wrote:Question on device states - are these only key/value pairs or can a dict/map also be persisted?
My opinion; others may disagree.
You can store anything in device states within the confines of Indigo's base framework (int/float/bool/str). This information is public--that is users can easily query it, and will show up in Indigo UI for control pages, etc. Therefore, I think device states should be limited to information the user may want to see/use. The information will persist until it is changed--states are designed to be changed a lot.
You can store information in device preferences, within the confines of the available control types. For example, you can store a boolean value as a hidden checkbox. This is often helpful when debugging as you can remove/reapply the hidden attribute and display the control as needed. These will persist until changed or until the device is deleted. When hidden, users will not see the data stored there without some effort to expose it.
Similarly, you can store information in plugin properties, within the confines of the available control types. The same behavior applies as does with devices--with the exception that the data will persist even when a plugin device is deleted because the data are stored at the plugin level. The information is stored within the plugin's 'indiPref' file--located in the preferences folder under the name of the plugin. This information will persist until the *.indiPref file is deleted.
Of course, you can also save anything you want to a file and recall that as needed. You could save as JSON or XML (each has advantages and disadvantages) or a text file or CSV or whatever. This approach is probably the safest from the standpoint of persistence, but there are caveats. You'll want to store the data in a place where Indigo will automatically migrate it when it's upgraded. You can store it in the plugin package and Indigo will move it during an upgrade. It will generally persist until the plugin is deleted. IMO, we shouldn't presume to put data into the User's home path without asking because they may be saving those files/folders to other places (like iCloud, etc.) and we might be taking up valuable space. I feel that putting it into a unique place within the Indigo tree (that will get migrated) is the best approach because it also has the added bonus of a bit of extra security since it requires admin privileges (normally).
Oh, and you can't save an object directly to a property as described above -- for example, saving an indigo.Dict() to a textfield -- you'll have to serialize it first (convert it to a string). Same thing goes for lists, etc.
This isn't meant to be exhaustive as there are other nuances and approaches -- but I think these are the main ones.
EDIT: To be clear - information stored in the plugin package will not survive a plugin update. So only use this approach for data you want to retain when the plugin is active. If you want it to persist beyond a plugin update--store it someplace else.