Sorry, I got wrapped around the terminology in my previous reply (note to self, pluginPrefs != pluginProps). To clarify, from within your plugin's code:
- In the __init__ method, pluginPrefs are the global plugin properties that are defined in the plugin's config dialog (or added directly by you at any time for that matter)
- Where dev is an Indigo instance of one of your devices defined in Devices.xml, dev.pluginProps (and dev.ownerProps) are just shortcuts to globalProps["your.plugin.id"] and are specific to the device instance.
- Where anotherdevice is an Indigo device instance not owned by your plugin, anotherdevice.pluginProps are a shortcut to globalProps["your.plugin.id"] (which you can modify at will) and anotherdevice.ownerProps are a shortcut to globalProps["owners.plugin.id"] (which may only be modified by the owner of the plugin)
Hopefully this clarifies. So, any config item that's specific to a device instance should be stored in your device instance's pluginProps (which is the same shortcut as ownerProps when used from inside your plugin). These aren't editable by anything except your plugin and aren't visible to users in the UI (but they can open a scripting shell and inspect an instance and see them there but not change them). In your example, this is where you'd store the token since it's specific to the device instance.
geoffsharris wrote:I also have a list of functions and variables that are accessible through the cloud API that I would like to store on a per device basis. I would like these to be persistent with the device, ie not refreshed every time the plugin is restarted and I can easily make an "action" to refresh them if it is needed. I do not need or think it is very helpful to the user to have them stored as device states, but I would like them to be accessible to the plugin so I can make the API calls. If it was you, how/where would you go about storing this info? I apologize if this is a read the manual situation, but I haven't found a clear answer to where to store persistent information on a per device basis that is for device function rather than as user accessible states.
I'm not clear on what you mean by "store on a per device basis", but I'm going to guess that you mean a specific device type (not Indigo device type but some type defined on the remote system). If that's the case, then I'd create my own Python class(es) to represent those device types. You could then instantiate an instance of the appropriate type every time an Indigo device that you define is started (in the deviceStartComm method). Pass in whatever you need from the Indigo instance into your custom device (like the token) and store a plugin-wide map that maps an Indigo instance to your instance.
Then, when any of the Indigo API defined actions (or your custom actions) get called with an Indigo device instance, you look up the associated custom object instance and call the appropriate methods on it to perform the action.
When the deviceStopComm method is called, delete that from your map.
So your class is a proxy object for the Indigo device instance object, one that knows how to do the specifics for your device type. I think this (or a similar) pattern is what's used by many developers (and by several of our internal plugins).