This will give you a reference to the device, and you can call commands on it like a regular Groovy method (the same way they are implemented, if you happen to be familiar with the flip side).
So, something like tstatSet.setCoolingSetpoint(75) is an example of a call you could make that would do what you want in an app.
This, on the other hand, is what you could do in such a driver to actually change the value of the reported coolingSetpoint attribute (in real devices, normally after a report for such is received; in virtual devices, usually just in response to a command since there's nothing "real" behind it).
Not relevant but thought I'd point it out since you might have tried. (You actually can generate an event in the app too, but app events are very rarely used in Hubitat and it wouldn't affect any devices.)
To add to this, the commands (methods) available on a device depend on its capabilities in the driver definition and are documented (along with the attributes) in the capabilities list you can find here:
For a specific device, the device detail page will also show you all commands and (usually, unless the developer failed to specify these for custom commands) parameters -- but technically the only ones you can count on being there for an arbitrary device are the ones required by the capability you used on the input type.
is really superfluous? And the function is only to get the device ID?
And (not being practical but) Is this the same device ID found in the UI? If so, in theory you could hard code the deviceID and have it work. I understand this would be ill advised, just asking to help me "sink in" the concepts/relationships.
Thank you. I've used that list for an app that reads the temperature and state of a thermostat. However I couldn't see how to setup a "write" to method.
Do you mean "can I get rid of input?" If so, no--it is absolutely necessary. It's kind of hard to tell given how Groovy allows the creation of domain-specific languages that can look a lot like English, but input is a method that is taking parameters (parentheses are optional but would also work and might make this clearer if you are used to other langues that require them: input("tstatSet", ...)).
No, you can't do much with the device ID. You need a reference to the device object itself (technically a DeviceWrapper, but you don't really need to know much about the class itself). The ID alone won't help, nor do you really need to know the ID to use the object.
This is part of Hubitat's user app security model: they can only work with devices the user (even if it's yourself) has directly selected via inputs in the UI, like the above.
I was unclear about the "input" question. My though was the inference by the word "input" is not technically correct. While I'm not advocating a change, I would think "assign" would be more intuitive than "input"
I think of it as building a declarative UI (years before such frameworks were popular): you are defining an "input" as displayed in the interface.
It helps me to remember that this is analogous to paragraph and href (other kinds of things you can display instead of inputs) and even the pages and sections in which all are (usually explicitly) contained. Or at least that's what I think.
(You actually can generate an event in the app too, but app events are very rarely used in Hubitat and it wouldn't affect any devices.)
