Hi,
Can anyone tell me what “capability Actuator” is actually used for ? It has no attributes and no methods.
Thanks,
Serge
Actuator is intended to show that devices can change something. As opposed to sensor which is for devices that only report the state of a sensor.
1 Like
So basically any form of motion sensors, contact sensor etc …
Thanks,
Serge
Those would have the Sensor capability. Actuator would be a thermostat, door lock, switch, dimmer, etc. Devices that can do something.
1 Like
I don’t know what SmartThings intends the capability to be used for @Jim ? @Duncan ?) but in a zigbee sensornet nodes are either “sensors,” “actuators,” or “controllers.” Where in a zwave installation they are “sensors,” “switches,” or “controllers.”
In most engineering, an “actuator” is a device that causes another device to start/stop.
Since there is a similar capability called “sensor,” if I had to guess, I would guess this is a terminology leftover from when SmartThings was just starting and they took zigbee and tried to build a universal overlayer over the top if it.
But I still don’t know what SmartThings intends it to mean if a device has capability sensor or capability actuator. I mean I know what they are in the physical world, but I don’t know what the smart device type, or a device handler, is going to do with that fact.
1 Like
Thanks, from what I am seeing their has been a lot of cut and pasting of code, probably for lack of documentation, and so things are just getting carried around from code to code for no reason which then makes it even more difficult to make sense of everything.
So bottom line regarding “actuator” capability. Should I be including it or not for a motion sensor for example ?
Thanks,
Serge
Not for a motion sensor. You define the capabilities that your device supports. This helps other SmartApps discover and select your device for use. A motion sensor has the capability.sensor and capability.motionSensor. Capabilities is an area in desperate need of clean up and documentation. Take a look at this:
1 Like
Until the documentation clean-up / expansion for capabilities is done, here’s what I have learned:
The Actuator capability represents that a device can do something; i.e., has commands. The Sensor capability represents that a device has attributes.
They are similar to Java “tagging” interfaces like Cloneable, in that they don’t define any attributes or commands, but serve as tags to indicate that a device has commands (Actuator) and/or has attributes (Sensor).
So, any device type with attributes should have the Sensor capability and any device type with commands should have Actuator.
2 Likes
Ok, but is there a way to mark input field as actuator + switch for example? One could define a device type having only actuator.
No, you would just use the switch capability in this case.
1 Like
What difference does it make whether the device type itself lists both actuator + switch or just switch?
Yep, and that is one of the reasons the current capability situation needs a rethink.
For filtering purposes. From my conversations on the support calls and elsewhere, specifying capabilities is a way of allowing smart apps to filter for the required devices. I can require capability.actuator if I want to write a smart app that controls a water shut off.
Yeah, but once you get such a device as input, you won’t have any know commands to call!
How would yo know if you got a valve or a garage door?
You won’t know. Right now you would have to code for actuator and switch and the leave it up to the user to select only a water valve if that is what your app is intended to control. Specifying capabilities is very generic at the moment. I think deeper API integration could mitigate some of these issues. Require actuator, but be then be able to query the device as to what type of actuator it is.
Speaking as someone who majored in Computer Information Systems and worked as a Network Engineer, this makes no sense to me.
Nor does it line up with existing ST documentation, which says attributes are the values that can be passed in a command. (Which does make sense to me.)
http://docs.smartthings.com/en/latest/device-type-developers-guide/anatomy-of-a-device-type.html
Even ignoring the documentation, plenty of actuator devices have attributes and plenty of sensor devices process commands. (Polling is an obvious example.)
I don’t know why every technology company feels they have to invent new terminology, but at least they could stop reusing existing words in incompatible ways. (Wink “robots,” I’m looking at you! 
)
It sounds like “actuator” and “sensor” are really intended as generic device classes, probably to be associated with some basic supported commands for both. Which commands would have some standard attributes.
But to say one group has commands while the other has attributes honestly requires a whole new dictionary.
They are not mutually exclusive. For example, the CentraLite Switch device handler has both the Actuator and Sensor capabilities (along with several other capabilities, like Switch), since it has both commands and attributes.
1 Like
If I write an app and I ask for an actuator or sensor, I’m screwed, because I have no remote idea about the device that I’m dealing with. Which leads me to question: why do we have it in the first place and why isn’t it deprecated already if actuator and sensor capabilities serve no purpose?
It would be useful, if one could perform logical OR and AND on capabilities when enumerating devices. For example a security application would ask for all motion, contact and smoke sensors in one input section instead of three separate ones. The way it’s currently implemented is too primitive, imho.
You can query device capabilities, attributes and commands in runtime, so technically the app can figure out what devices it’s dealing with and ignore the ones that are not compatible, but it’s certainly not the way it should be done.
A good example of this is the way Android handles sensors.
http://developer.android.com/guide/topics/sensors/sensors_overview.html
You know that a device has sensors, but an app can require that a device have the appropriate sensors. This should be discoverable at the time of install.
The way I would be using it when writing a device handler, would be as a generic capability. A motion sensor would include a motion and sensor capability. A switch would include a switch and actuator capability.
Makes me wonder, which device would not be a sensor nor an actuator?