Can someone briefly explain the following that I see in the code of apps and drivers?
device.getSetting from a driver
setting.some_name from an app
getDataValue from a driver
The documentation is a bit sparse. For example, getDataValue is basically described as getting a data value for this device.
getDataValue reads the "data" for a device object. The Data section is at the bottom of the device page. You can read existing data or you can store new data there.
settings.settingName is where the settings/preferences values are stored so you can use them in the driver code.
I think this only works in a driver, not an app.
I think deviceObj.getSetting does the same thing but it was created so you could get the settings values from within an app.
EDIT: See below for corrections from @bertabcd1234
Thank you very much.
You should help write the documentation.
I tested updateDataValue and saw where the data appeared.
What is this data typically used for?
How does putting data there differ from using state.some_name = some_value which I have also seen.
Thanks in advance.
For me it is the visibility, the states are little easier to work with but they are at the top of the device page, but I try not to clutter than up too much because to me its ugly. Also the states are not available to apps.
The Data I see as more of a long term storage, but it does not take kindly to saving some data types directly (like a map). Data is available to apps through the device object.
I am sure there is some underlying difference in how the hub reads/writes to those as well. I found if you are reading/writing to the data a lot you can step on top of yourself due to multipole functions running at the same time. So I now am just keeping the data in a Field variable to work with in the driver, and writing it out to the data as a backup for when the hub is rebooted.
This works in either.
This won't quite work; you won't be able to call
getSetting() on an arbitrary device (e.g., on a device you've selected) from within an app. The
device.getSetting() example is literal in that it literally must be called on the
device object itself (from within that same driver code), or
app.getSetting() if it's an app.
getSetting() is just "convenience" for the above, i.e., these are all the same in the end, which I'll spell out since it may be helpful for the OP:
mySetting (a bit of magic; setting/input names are "elevated" to fields so you can just use them directly, too)
Thank you. That is the kind of information that is most helpful and probably should appear somewhere in the online documentation.
It's a bit confusing that settings and preferences seem to be essentially two words for the same thing. But perhaps I am missing something there.
Also just to be sure I understand could you clarify the term "field"?
Thanks in advance.
It's there. Things in "Device Object" or "InstalledApp Object" are available on the
app objects, respectively, but this could probably be clarified. (And things in "Common Methods" are available as-is in either.)
Yes, "Preferences" is the user-facing term that users see in the UI. The internal data structure in which these selections are stored is called
settings (as are all methods that relate to this in app or driver code).
This is a Groovy term, not a Hubitat term, and just means that the variable/name is scoped to your entire app or driver (i.e., available for use anywhere in your code). See: Field (groovy 2.4.9 API)
You have been a great help. Thank you VERY much.