Welcome to the community and thanks for posting! Am I understanding correctly that this is used with something like horizontal blinds that can raise/lower as well as change the tilt level of the slats?
Would you mind sharing a link to the driver / device handler if it’s a community developed integration? I’d love to take a look at the driver/handler to better understand the use case.
Thank you for warm welcome. Yes, that is the case, blinds with tilting slats. 
See below link for official device handler. I’m using customized version with implemented switch capability.
or this one
It’s an interesting proposition and I can definitely see the value in certain situations like this. Community feedback is a key part of how we prioritize what we work on, so creating your post is a good first step. The more people that voice an interest in specific features, the more likely they are to get prioritized.
I’ve gone ahead and split this discussion out of the Multiline Hero Attribute and Sorted List - #12 thread and into it’s own topic to give it a bit more visibility as well. (Feel free to rename the topic title if you don’t like my summary) 
In the meantime, a common workaround for other device types which either have multiple on/off states or multiple controllable levels is to use child devices.
Often times, the core control is all possible on the main ‘parent’ device using custom commands (like the setSlatLevel() command in the device you linked to.
Then the ‘parent’ device might also have child devices for convenience. For example, a ‘Slat’ child device that offers a standard setLevel() command under the Switch Level capability so that it can be used in other apps like SharpTools which implement things against the capability standards that SmartThings has defined. (This also opens up functionality with a bunch of built-in SmartThings apps as well)
–
For example, my custom Wink Relay device handler… the device has two relays built-into it meaning it can control two different loads. Using an on/off command on the parent device will cause both relays to turn on or off. The parent device also has custom relay1On() and relay2On() style commands for controlling each relay. It also has a child device for each relay… so you can directly use standard on/off commands on each individual relay making it easier to use in various SmartApps (including built-in ones like Smart Lighting and the Custom Automation builder).
Perhaps you could suggest this to one of the DTH developers to see if it’s something they would consider adding? Or if you’re up to it, you could perhaps contribute the modifications. 
Thnx for forking this into a new thread, hope it gets some community support.
An alternative approach could work; unfortunately, we have 12 windows shades in our house, and this will duplicate the number of tiles and clutter the dashboard. Nevertheless, I will try this approach for the most important windows. 
You mentioned that roadmap is influenced by the community, I was wondering if the current roadmap publicly accessible?
I guess I’m rescucitating this thread, but this is something I’d really like to see as well. I’ve got four sets of Lutron window shades which raise/lower as well as have slat tilt levels (0-50). I can read the tilt attribute, but I’d really like to be able to set it (or at least toggle between two levels).
What platform and driver/device handler are your Lutron shades using?
From what I recall, the challenge with the device mentioned at the start of this thread is the secondary ‘slat’ position was using a custom command for setting the position. If it used a standard supported capability (and was exposed as a child device), then it could be added to a dashboard multiple times with control for each part of the shade exposed.
You could use a rule to ‘toggle’ between your preferred positions.
I’m using the Lutron Integrator app on Hubitat Elevation. It exposes the shades in Hubitat with the following available commands: calibrate, close, off, on, open, parse, refresh, setLevel, setPosition, setTiltLevel, startPositionChange, stopPositionChange. State attributes: level, position, switch, tilt, and windShade.
Thanks for the tip on the rule. I think that gets me close to what I need, though I haven’t figured out how to make it a toggle using a single tile yet. I think if I play around with it, I may be able to make something work between a SharpTools rule and HE rule engine, maybe with a virtual switch in HE.
EDIT: Never mind… just discovered the conditional logic… Now I have a proper toggle.
There’s a few options here:
$.runRule() syntax
Since you can run a rule directly from a dashboard tile, you don’t need any Triggers in the rule. So you could just go straight to your flow and determine what action and conditions you want to take each time the rule is run.
Conceptually, something like the following might work
IF tiltLevel = 0
THEN
setTiltLevel(50)
ELSE
IF tiltLevel <=50
THEN
setTiltLevel(100)
ELSE
setTiltLevel(0)
Or in a Super Tile, you might have a few different preset ‘buttons’ on the tile to set your various tilt levels directly.
Excellent… thanks, Josh. Those are indeed some good options. I think I’ll end up using the toggle with a Super Tile. That should get me what I need. The hyperlink is also a great option. I’ll explore that some more as well.
Really appreciate the assistance and quick responses!
Are you trying to access the command from a custom Groovy Device Type Handler (DTH)?
The new SmartThings platform requires that a device implements custom commands and custom attributes using a custom capability. On Groovy DTHs, most developers just declared the custom command without a custom capability, but SmartThings no longer supports this.
Have you identified an Edge Driver to move this device to?
I found that ST provided a new Edge Driver, SmartThingsEdgeDrivers/init.lua at main · SmartThingsCommunity/SmartThingsEdgeDrivers (github.com). Unfortunately, I don’t know why it is not used on newly joined Qubno shutters.
Do you see that with new edge drivers it should work?
Yes, if the Edge Driver implements it as a multi-component device or implements a custom command in a custom capability, then it will work.
It’s a bit hard to follow what they’ve done with this particular driver, but it looks like they plan on a version that has two components - one for the main up/down level and a separate one for the tilting of the blinds… the problem is, I don’t see any fingerprints that match the shutter/venetian profile. 
In that case, you might have to check if the community has come up with anything.
Do you still have a custom DTH installed for that device? It will try to pair with a custom DTH before trying to use an edge driver. Usually, you’ll want to remove the DTH before reonboarding the device in order to get it to use a driver.
For this particular driver, I don’t think it will match your device in the production channel. I believe you would need to join the SmartThings Edge Beta channel for this device to pair.
You can identify this by navigating up the file tree in the GitHub repository you linked until you find a folder with a fingerprints.yml file. That’s what their system uses for identifying if a device fingerprint matches. For whatever reason, they still have a lot of fingerprints commented out for a number of devices/drivers. You can change the branch to production in order to see what they have released and what’s commented out:
Thank you for the detailed instructions, much appreciated. I will try the Edge Beta channel while removing the old custom DHT, and will report back soon.
With the SmartThings driver, I suspect that the device will rejoin, but only with control over the main shade level (not the tilt level). It looks like they stubbed out a profile for shade+tilt, but it doesn’t match the fingerprints of any devices.
Yeah, I just came to the same conclusion, qubino-flush-shutter-venetian profile is unused - a new dead end for now. Maybe over the weekend, I find time and create a custom Edge driver.
Today, I have had time and went thru the code once more. I found that the profile is changed dynamically based on the configuration value - if venetian operation mode is selected profile is set to “qubino-flush-shutter-venetian”.
Full of new optimism, I removed and reincluded my shutters, and surprisingly everything worked as expected.
SmartThingsEdgeDrivers/init.lua at beta · SmartThingsCommunity/SmartThingsEdgeDrivers (github.com)
Now I have two devices in Sharptools shutter and venetian shutter, together they represent shutter. I want to combine the shutter level and the venetian shutter level on a single tile. Super tile came up to my mind, but it seems I would need to create 15 super tiles for all my shutters. Did I miss something is there any different way to achieve this - super tile template?
There’s a feature request for that here if you want to cast a vote and perhaps post a comment to bump the thread for visibility:
Along those lines, you might also be interested in the following feature request to be able to use the Dimmer / Slider controls within a Super Tile:
