The "Window Blind" capability is missing from the capability dropdown in current and previous versions of Rule Manager.
I wrote a driver for the Sunsa Wands blind controller (available via HPM), which implements the WindowBlind capability, It has limited usefulness if it can't be controlled by a rule. Or am I missing something here?
The WindowBlind capability is relatively new and RM doesn't expose every capability as a default option, so this isn't too surprising, but I don't see WindowShade there either (which has been around since the beginning, if not soon after). That I was surprised by. I suppose this is a choice they make of the most "popular" or likely attributes and what capabilities they are generally associated with. That would be a choice staff would have to make, so I can't comment on that.
In the meantime, anything you do can do with pre-provided options (or I guess just the ones that correspond to device attributes) you can also do with "Custom attribute." So, no functionality should really be missing--just use that and select the relevant attribute for your device. Depending on how you wrote your driver, "Dimmer" may work if you use SwitchLevel (capability) and level (attribute) as synonymous with the tilt/position-related aspects of blinds/shades drivers. Many drivers do this (likely to increase compatibility with apps that work with level), though I've noticed a lot of new ones try to be "pure" shades/blinds drivers that don't--but at least with a custom driver, you have the option either way. 
I don't think that's the case. If so, then what's the point of a device capability if you can't actually do anything with it?
Sure I can hack something up like adding the dimmer capability, but then the window blind is going to appear in the list of light dimmers (or other inappropriate places).
I think someone just forgot to update the list when new capabilities are added.
Thank you, that was helpful if not a bit head-scratching.
Adding "actuator" as a capability worked, but it's non-intuitive. It has no commands or attributes, so what's the point? Seems to me that any capability that provides some sort of "actuation" would inherently imply that it's an actuator, for whatever internal purposes the actuator capability serves.
Why would this make sense to a non-developer who just wanted to automate something and couldn't find it in the list of device (capability) types?
If I was a more advanced user, I might look in the driver code to see what capabilities it provides. Then when creating a rule, I would expect those capabilities to be found in a control that's labelled "Select capability of action device". Why are some capabilities in the list and others aren't?
As a developer the logic of this escapes me. As a non-developer end user, this seems the kind of friction that would end up in frustration over trying to do something that ought to be straightforward.
Theoertically, it should be added to any device that you can run commands on (as opposed to "Sensor," which is similar in that it has no attributes or commands--but is intended for devices that just report things back to the hub). This can serve as a "catch all" selector for apps that don't want to use, say, capability.* (and probably had some use in the SmartThings model Hubitat largely re-implemented, but I don't recall the history there).
You can; there are more apps out there than Rule Machine, and some of them may select for capability.WindowBlind. But even with RM, this should be usable with a custom attribute selector, as described above, at least once you implement "Actuator" (again, a good idea in general for this kind of device) so there's a capability it implmenents somewhere that the UI does let you select.
(That being said, this certainly could be added to the UI, but unlike some other capabilities, there's not necessarily any obvious choice since the capability defines two attributes...or at least I think it's supposed to and assume there is a copy/paste error in the docs. So, they'd have to make a choice, and if it's not what you were looking for, you'd need to go custom anyway. Not our choice, in any case, but maybe in the future this will change...)
I suppose, But if a device has commands, then that would imply actuator anyhow so I don't see its purpose, unless it's some legacy sort of thing. Not a big deal though.
It does fix the problem, but it's certainly not intuitative. At least not to me and probably not you either given the conversation you pointed me to. If a dropdown lists capabilities, it ought to list all the capabilities the system defines. Or at least, all the capabilities that are implemented by installed device drivers.
Anyhow, not trying to shoot the messenger. Thanks for the assistance.
It's never been the intent that RM cover all capabilities. As there is user clamor for one not covered, we tend to catch up and add it. 'Actuator' and 'Sensor' capabilities are catchalls that allow devices of any capability to be used, even if not built-in to RM. For sending commands, Custom Action can be used to pull up all of the commands supported by a device. It's worth noting that many devices whose capability is supported by RM have commands that are not directly supported. Custom Action allows access to these commands. For use in conditions and triggers, Custom Attribute can be used to pull up all of the attributes supported by a device. RM usually only supports the main attributes of a device, and many devices have additional attributes and associated events.
But only if the user knows to select the Actuator capability if a more specific capability isn't in the list. I know this now, but that would be (IMO) non-intuitative for a new or non-technical user. I don't think the term "actuator" would immediately come to mind when a normal user is thinking about a blind, or probably most other devices.
Ok, but a "normal" user could not be expected to know that. It would be reasonable for a user (esp. a new user) to expect the creation of a rule controlling blinds to be same as creating one to control a switch, thermostat. etc. Especially if one of your goals is to make the product more accessible to the non-geek crowd. Just my 2 cents, FWIW.
Where's that dropdown located? In RM? I don't have any entry labelled "Activate Scenes, Adjust Shades or Fans".
You're right. It is also a documentation failure, but who reads documentation!
'Activate Scenes, Adjust Shades or Fans' will only show up if you have a device with either WindowShade or Fan Controller capability, or a Scene installed.
Can't argue that point.
Hmmm. I wrote a driver for one of these: Smart Blinds by Sunsa Homes | Automated Smart Blinds
I didn't use WindowShade because I thought "shade" was intended for a shade that rolls up and down. WindowBlind seemed more appropriate since it has a "tilt" attribute and this device controls the tilt of the blind slats. It can't control the blinds position so I left those commands unimplemented (just writes info to the log).
Should I use WindowShade instead? Or in addition to WindowBlind? At least until WindowBlind get the same respect that WIndowShade has? 
Possibly. I don't know how your driver works, and whether or not it has commands open and close. If it does, then adding the WindowShade capability will make it show up in RM, where those two actions are available.
Yes. open, close, All the commands specified in the capability definition.
So if I add the WindowShade capability, do I still need Actuator? What's the guidance for that capability? Always if a device implements a command, or only sometimes?
Probably not. Actuator, as described above, is simply a catchall capability. It would appear that adding WindowBlind to RM is not a big deal. The two capabilities are the same but for the setTiltLevel() command and tilt attribute. I'll see if this can be done for the next release.
Thanks!
Now is there anything I can do to get a raw encrypted socket added? I'd be willing to give you my first born in exchange.
As someone expecting a Sunsa Wand today, I salute you.
Easy there, pilgrim. I think we'd have to get written approval from both parents and at least one grandparent to OK that exchange. 
I said I'd be willing to give him my first born in exchange. Didn't say I actually had one.
Download the Hubitat app
