Questions on Undocumented Capabilities and Commands

General Discussion
,
1

There are a few SmartThings-created SAs and DTHs that contain a number of undocumented capabilities. I was wondering if anyone could explain the functionality and use of:

  1. capability “Health Check”
  2. capability “Bridge”
  3. DeviceWatch? sendEvent(name: “DeviceWatch-Enroll” …)

And my personal favorite:
4) valueTile(“doNotRemove”, “v”, decoration: “flat”, height: 2, width: 6, inactiveLabel: false) {
state “default”, label:‘Do not remove’

Also - I see that the documentation lists a capability “Bulb” and a capability “Light”. What (if anything) is the difference between these two capabilities? When should I include one over the other? If a device has either the “Bulb” or the “Light” capability, then is it necessary (or recommended) to still include the “Switch” capability?

2 Likes
2

Quite a few Smartapps look for the .switch capability, including the official smartlighting feature for “turn switch on/off.”

IMG_2124.PNG1536×2048 167 KB

As for the distinction between light and bulb, no idea, unless it just has to do with the icons.

@jim might know.

3

It would be nice if w could have our apps distinguish between an actual switch and a bulb.

1 Like
4

One of many problems with SmartThings “Capability” paradigm is that capabilities are used both as filters (i.e., “Input: Select from your lightbulbs?”) and abstractions (attributes and commands inherent to each Capability.

Any binary sensor+actuator = a “Switch”.

But from a UI perspective, one does not want to present the Customer with Locks … or even, Appliances… along with the list of “Lights”.

Except in cases were we do want a broad filter and any switch is good…; i.e., something like CoRE where “any” binary (on/off, lock/unlock, open/close) sensor+actuator is appropriate.

The answer is “inheritance” (all binary Device Type Capabilities should be built upon Switch and just have additional characteristics and/or filters added).

But; though there’s rumors of a big overhaul to Capabilities, it’s gonna be a long wait.

2 Likes
5

To me, it looks like they abstracted the capabilities from the existing third-party standards, particular Zwave. To Z wave, a bulb is a switch, as is a pocket socket and an in wall receptacle and a relay. If you can send it an on and off command (that specifically means an “on,” that’s not a general term) then it’s a switch. A lock is not a switch because it would ignore a zwave “on” command.

Zigbee used to be very similar, but jumped ahead when the ZLL devices were added.

1 Like