recommended methods for storing device state

Posted on
Sat Dec 26, 2020 2:22 pm
rbdubz3 offline
User avatar
Posts: 189
Joined: Sep 18, 2016
Location: San Diego, CA

recommended methods for storing device state

I'm looking to extend an existing thermostat plugin to add 'learning functionality' . Basically I'd like to be able to store info about changes to the preferred temperatures throughout the day in order to recall them later.. So basically I need to capture and store a dict/map of data. What are the preferred Indigo methods to use for storing state of a single device? This 'state' is really only needed by my plugin at this point, and I am thinking I only really need to store/retrieve the data at plugin start/stop.

Any recommended Indigo methods for this purpose?

One related question from experimentation - I was testing the replacePluginPropsOnServer method. It seemed to cause the specific device to be stopped/restarted by Indigo - the deviceStartComm / deviceStopComm methods were triggered. Is this expected or maybe just something with this plugin?

I automate because I am lazy :D

Posted on
Sat Dec 26, 2020 2:53 pm
neilk offline
Posts: 471
Joined: Jul 13, 2015
Location: Reading, UK

Re: recommended methods for storing device state


Posted on
Sun Dec 27, 2020 11:33 am
rbdubz3 offline
User avatar
Posts: 189
Joined: Sep 18, 2016
Location: San Diego, CA

Re: recommended methods for storing device state

Thanks for the tips @neilk - good to know about that didDeviceCommPropertyChange method.

As I dig into this a bit more - this info I am storing is more appropriately modeled as a 'device state' vs. a 'plugin property' for the device. So I believe I should be using the updateStateOnServer call instead.

I automate because I am lazy :D

Posted on
Sun Dec 27, 2020 1:25 pm
FlyingDiver offline
User avatar
Posts: 5335
Joined: Jun 07, 2014
Location: Southwest Florida, USA

Re: recommended methods for storing device state

rbdubz3 wrote:
Thanks for the tips @neilk - good to know about that didDeviceCommPropertyChange method.

As I dig into this a bit more - this info I am storing is more appropriately modeled as a 'device state' vs. a 'plugin property' for the device. So I believe I should be using the updateStateOnServer call instead.


Plugin properties are stored and recalled when a device stops/starts, or the plugin restarts. Device states have no persistence. So if you want the data to be saved, then use the properties.

joe (aka FlyingDiver)
my plugins: http://forums.indigodomo.com/viewforum.php?f=177

Posted on
Sun Dec 27, 2020 2:09 pm
rbdubz3 offline
User avatar
Posts: 189
Joined: Sep 18, 2016
Location: San Diego, CA

Re: recommended methods for storing device state

FlyingDiver wrote:
Plugin properties are stored and recalled when a device stops/starts, or the plugin restarts. Device states have no persistence. So if you want the data to be saved, then use the properties.


Thanks for the info @FlyingDiver.. Though as I play around with this a bit - basically doing a plugin reload - it looks like some of the device state is maintained in between restarts. I can see this info as part of debug logging in a test script - the device.states dict contains the key/value I am changing - but I can't seem to find it anywhere in the device.ownerProps (which I think is same as pluginProps).

I automate because I am lazy :D

Posted on
Mon Dec 28, 2020 11:15 am
jay (support) offline
Site Admin
User avatar
Posts: 16815
Joined: Mar 19, 2008
Location: Austin, Texas

Re: recommended methods for storing device state

I think you're conflating states and properties. States are defined and maintained by the device's owner (plugin, interface, etc). Plugin A can't update the states of plugin B unless plugin B defines an API (actions) that plugin A can call. State values are persistent between restarts - once the state value is updated it's written to the DB.

I can't tell if you're writing a plugin that defines it's own thermostat device or if you are just wanting to store information about other thermostat devices. If it's the latter, than you can just use the sharedProps on any device and add whatever data you need. You can also add props to any device that are only writable by your plugin if you need them to be more protected from changes.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Dec 29, 2020 9:58 am
rbdubz3 offline
User avatar
Posts: 189
Joined: Sep 18, 2016
Location: San Diego, CA

Re: recommended methods for storing device state

At this point my plan is to extend a thermostat plugin (looking at Unistat plugin code). The state I am planning to store is changes to the preferred thermostat heat/cool setpoints at an hourly time period. These preferred setpoints will be later recalled throughout the day. Funny you mention 'conflating states and properties' as it feels like this could be modeled either way - it could be added to the configuration UIs but it's a more natural user-experience to collect it as a user changes the thermostat setpoints.

Think I'll set it up as follows:
* initial heat/cool setpoint - a plugin property for the device
* learned setpoints - device states collected at runtime

Question on device states - are these only key/value pairs or can a dict/map also be persisted?

I automate because I am lazy :D

Posted on
Tue Dec 29, 2020 11:21 am
DaveL17 offline
User avatar
Posts: 5909
Joined: Aug 20, 2013
Location: Chicago, IL, USA

Re: recommended methods for storing device state

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.

I came here to drink milk and kick ass....and I've just finished my milk.

[My Plugins] - [My Forums]

Posted on
Wed Dec 30, 2020 11:06 am
rbdubz3 offline
User avatar
Posts: 189
Joined: Sep 18, 2016
Location: San Diego, CA

Re: recommended methods for storing device state

@DaveL17 - Thanks for the thorough explanation of the various options

I automate because I am lazy :D

Posted on
Wed Dec 30, 2020 12:34 pm
DaveL17 offline
User avatar
Posts: 5909
Joined: Aug 20, 2013
Location: Chicago, IL, USA

Re: recommended methods for storing device state

My pleasure. I've received a lot of help over the years here and am always happy to return the favor. :D

I came here to drink milk and kick ass....and I've just finished my milk.

[My Plugins] - [My Forums]

Posted on
Mon Jan 04, 2021 1:01 pm
rbdubz3 offline
User avatar
Posts: 189
Joined: Sep 18, 2016
Location: San Diego, CA

Re: recommended methods for storing device state

Ok - making some progress on my plugin with the states..

Tangentially related question here - I see all of my custom states available in the Indigo UI. I'd like to replicate some of these for easy viewing to the 'Device Details' section of the UI (see screenshot).. At present this plugin is defined of type 'Custom'. Any tips on how to customize the 'Device Details' and other aspects of the UI (BTW - I'm trolling thru the plugin-examples included with the SDK - very helpful)

Screen Shot 2021-01-04 at 11.00.14 AM.png
Indigo UI - Device Details/Custom States
Screen Shot 2021-01-04 at 11.00.14 AM.png (20.57 KiB) Viewed 578 times

I automate because I am lazy :D

Posted on
Mon Jan 04, 2021 1:09 pm
FlyingDiver offline
User avatar
Posts: 5335
Joined: Jun 07, 2014
Location: Southwest Florida, USA

Re: recommended methods for storing device state

Only pre-defined device types show data there. So you could use sensor types to show an on/off state or a value. But you can't put arbitrary data there.

You can, however, set an arbitrary string as the value in the "State" column in the UI.

If you make your device a "thermostat", then you'll get the thermostat controls.

joe (aka FlyingDiver)
my plugins: http://forums.indigodomo.com/viewforum.php?f=177

Posted on
Mon Jan 04, 2021 1:15 pm
DaveL17 offline
User avatar
Posts: 5909
Joined: Aug 20, 2013
Location: Chicago, IL, USA

Re: recommended methods for storing device state

Indigo does not generally expose what goes in the Device Details pane to plugins, beyond the built-in device types (relay, etc.). Instead, you'll generally need to use the Indigo UI fields for things like State, Address, etc.

<echo></echo>

I came here to drink milk and kick ass....and I've just finished my milk.

[My Plugins] - [My Forums]

Posted on
Mon Jan 04, 2021 1:33 pm
rbdubz3 offline
User avatar
Posts: 189
Joined: Sep 18, 2016
Location: San Diego, CA

Re: recommended methods for storing device state

gotcha - ok thanks for the info - saved me a bit of time digging thru forums and code examples..

BTW - I did consider extending an existing thermostat plugin for this effort - but figured this would be more flexible as a standalone plugin. As a standalone - it can be used with any thermostat device type for automatically managing the preferred setpoints - fwiw :)

I automate because I am lazy :D

Posted on
Wed Apr 28, 2021 7:17 am
rbdubz3 offline
User avatar
Posts: 189
Joined: Sep 18, 2016
Location: San Diego, CA

Re: recommended methods for storing device state

Forgot to post back into this thread after submitting the plugin... So I got all of the state management working - but kinda sat on the plugin while I did some dogfood-testing myself - guess a few months have elapsed :shock:

If interested in adding some smarts to your thermostats - the plugin is available here: https://www.indigodomo.com/pluginstore/250/

I automate because I am lazy :D

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 5 guests

cron