Hello,
I'm working on a driver for my shades and can't figure out how to run a 'toggle' Custom Action from a button. It seems that the windowShade capability is not included in the list. I think this is a bug, but wanted to confirm with the forum first.
I am able to add the 'switch' capability to the driver and run Custom Actions from the switch; however, this is not accurate and is more of a work-around than a proper solution.
Bug or not, I don't know, but the reality is that what capability you choose here doesn't really matter; you have access to all the commands the device/driver implements regardless of what you choose, so presumably this is just something they implemented to make the list of devices a bit smaller. Chances are a window shade would also implement another capability here, like Switch, Battery, or Actuator (that last one is a "catch all" you might want to have anyway if you don't like having Switch; it does nothing on its own but is intended for devices that accept commands, sort of the complement to Sensor). So, it's possible the omission was intentional.
Thanks for the prompt reply. I suppose the next best capability would be either DoorControl; however, this capability doesn't work with any of the standard Actions.
Seems convoluted to have multiple device capabilities. Is there any practical use cases where one capability isn't enough? Ideally, the windowShade capability should include a toggle() command.
Why would it include the toggle command? No capability includes the toggle command, even the switch capability does not. Do a search for toggle on the driver capabilities document. You won't find it.
It's very common (I'd say the norm) for drivers to implement multiple capabilities. For example, a wall dimmer might implement Switch and Switch Level at a minimum, plus Actuator. Most (depending on what the device can really do) would also implement ChangeLevel. That's not even considering "scene switches" (as many new Z-Wave ones are) that would implement at least PushableButton but likely all the button capabilities.
In the case of window shades, it looks like the WindowShade capability could technically handle anything you should want to do (assuming the device is just a shade and doesn't have battery reporting, a way to refresh, or anything else you'd to best to specify a capability to implement). In this case, I'd at least consider adding the Actuator capability, which again is something you'll normally find in devices that accept commands (most drivers "implement" at least Actuator or Sensor; they do nothing on their own but they do help in situations like this--RM always allows you to choose either, for example). That being said, many shade drivers implement Switch and sometimes even Switch Level to give them compatibility with a wider variety of apps (lots are meant to turn on/off switches, but far fewer are designed to open/close blinds, for example). How "pure" you want to be there is up to you.
(I'm assuming "toggle" is a custom command you implemented in the driver and are using a custom action in RM to do that. It should be noted that with the Switch capability, RM's built-in "Toggle" actions might do what you want, but specifically, they'd send an "off" if the switch attribute currently reports "on" or vice versa. If you go this route, it is common for on() to be equivalent to a open() and off() to close(), though you can again do whatever you want.)
Thanks for the details and explanation. That makes sense and I was actually using a few already like Initialize and Refresh!
I will test a few more things and see what works best. I found the actuator capability to be the most cosmetically appealing solution thus far, but don't love it. Would think that adding a 'Window' option on the list of Custom Action capabilities for the Button Controller App would be the freshest solution, but from the sounds of it that might not be the wisest approach for Hubitat since not too many users focus on drapes and shades.
Thanks again for taking the time to help!
BTW - The driver is keeping track of the last direction the shade was moving and therefore handling the toggle internally without RM.
Why not? Your device accepts commands. It's an actuator. 
Glad you got something figured out in any case!
You are absolutely right... I guess I'm just surprised that toggle isn't a standard command for certain devices that aren't binary. I haven't tried toggle with RM, but it seems the problem is that shades and drapes aren't always just open or closed.
With my custom 'toggle' command, the shades stop when the button is pressed & the shade is still moving; it will move in the opposite direction it last went if it is not moving. This allows my wife to control the shades position with just one button.
Am I wrong to think that 'toggle shades' should be added to the list below?
I'm not sure if RM "should" have an action like "toggle shades," but if it did, I'd expect there go be some gray area since there are multiple possible shade states (open, closed, partially open, etc.) as opposed to only two possible switch states (on or off, so just get one to the other when toggling) and I'm sure someone would want it implemented the other way no matter which way they did it. 
But yes, they certainly could add something like it. But as with switches, "toggle" is just an RM concept--the logic is handled on the app (RM) side and not the device itself, which only knows whether it's off or on and and only be commanded to turn off or on, not toggle per se. Since you implemented a custom toggle() command, calling that directly is probably better (you're handling the logic on the device/driver side instead of the app side).
If you did want RM to be able to use a "Toggle"-type action natively, I'd consider just implementing the Switch capability in your driver. Then it will send an "On" command if the switch reports as "off" and an "Off" command if the switch reports as "on," and in your driver, you can handle reporting the switch attribute however you want to get the toggle behavior to match what you want. This might be cheating a little, but again, it's pretty common with WindowShade drivers; these capabilities aren't quite as commonly used as others like Switch and Switch Level, so lots of drivers implement them too to open up compatibility with a wider variety of apps.
My two cents (worth 0.2 cents with inflation): Hubitat has a set of defined capabilities that all drivers are supposed to use. This allows apps (like rule machine) to know that a device with capability Window Shade has the commands open, close and set position and has a certain attribute. Basically, this allows the app to interact with the device knowing both device (driver) inputs and device states (attributes). Without this, the apps would be very limited in scope.
If you did not know, the list is at: Driver Capability List - Hubitat Documentation
An example is Window Shade with the below data:
So, if you want to add toggle, it would be to add it to the capability Window Shade. At the same time you should add Stop as a part of Window Shade. This would then make toggle and stop accessible to any app recognizing Window Shade.
I definitely have a much better understanding of how hubitat Apps and Drivers now work. The information here has been well worth it.
So... I'm now trying to see if I can get Rule Machine to conduct the same/similar ' functionality. The first thing I notice is that WindowShade aren't even an option for RM. You need to select 'Custom Attribute'!
The WindowShade provides the 'opening', 'closing' and 'partially open' attributes so I figure I can ask RM to use these attributes to open the shade when it is either 'closed' or 'closing' and close the shade when it is either 'open' or 'opening' (easy enough).
However, next step is what to do when the shade is 'partially open'? I would need to tell Rule Machine what direction it moved last so that it will do the opposite. Seems a 'lastDirection' attribute is the missing link.
The driver I'm using keeps the 'lastDirection' as a state variable (string) and when the toggle() function is called it evaluates it to determine what to do when the shade is 'partially open'.
What would be the logical way to accomplish this with RM? I've just installed RM for the first time as I've been doing everything via scripts, but I'm thinking using RM might be more robust.
What's more, I can't seem to attach a custom attribute within RM! It seems the button for continueing is missing on my HE:
Working for me. Try selecting the attribute again (the down arrow). They you should get a comparison question>
First and foremost. I'm going through these motions so that I may better understand my hubitat. I'm hoping to use this knowledge to help the community as much as I can.
So I've been testing RM and I can't seem to figure out how to make the actions run smoother; i.e. with RM the actions take a second or more to react. It was taking about 100ms with the toggle() function triggered directly by the button via the Button Controller App.
I'm using a Lutron RadioRa2 keypad and have taken account in both cases that the lutron keypad has a 1.8-2 second delay between button pushed due to Lutron's implementation of Telnet (first button pressed is nearly instantaneous).
Here's my RM rule in case you see something wrong with it.
So for know I will stick with my driver's toggle() function and deal with my OCD.
I don't see anything wrong with that RM rule. RM is a pretty massive app, and things may often run slower it compared to slimmer purpose-built apps, but 1 second seems like a pretty unusual penalty, so I'm not exactly sure what might be wrong (unless you're noticing general hub slowdowns, in which case a graceful reboot from Settings might at least temporarily relieve the problem).
Nearly 2 seconds is also an unusual delay for Lutron, but I have seen several seconds of delay if it's the first time I've triggered a particular button-using app since I rebooted the hub (guessing it's something to do with Groovy compiling or caching), so it could explain that much if that's also what you're seeing.
Since you're apparently writing a custom driver and can do it this way, handling the logic for toggling within your driver might be faster--fewer evaluations in RM (which has to do a bit more work than direct Groovy) and more in your driver, so likely a better experience. Just not sure it should be that drastic...
To be clear, toggle isn't a "standard command" for any devices in Hubitat. Most of the places where toggle shows up, it is done via software. But there is no toggle capability and toggle doesn't appear in any of the standard capabilities either.
Adding a command to a capability means that you would have to update every single driver that uses that capability and then every app that interacts with those devices. That is a HUUUUGGGEEE undertaking and one we are not likely to see for Toggle Shades.
Hi @bertabcd1234! The lutron delay is inherent on how Lutron handles TelNet messages. There is no way to hasten the delay between 'button pressed' and 'button released' and therefore can't receive a seperate button press until Lutron finished sendin the previous button released and that has a hard coded delay from Lutron which is like 1500 milliseconds.
@johnwick- no need to do anything with it, just surprised that a native toggle command hasn't been implemented. It won't be long until devices handle it. Anyway, wouldn't a new toggle command just 'do nothing' if an old driver was used or would the driver break?
Looks like the relevance of the toggle command within smart automation has finally been realized by Hubitat! Thank you for including this on the new Basic Rule app. phew!
It's actually cleaned up my programming on multiple fronts with the addition of restrictions based on time, etc.
Keep up the great work!
Download the Hubitat app
