Mapping Google's "Blinds" device type to "Window Shade" Capability

Devices & Integrations
1

Hey there, Google recently added the “Blinds” device type to their Google Home Smart Home device types (on March 12th 2019):

This is exciting for me, since I currently have to pretend my blinds are switches for them to work with Google Home.

Currently if you use the official “ZWave Window Shade” device handler, it does not show up in Google Home at all, presumably because the “Window Shade” capability has not yet been mapped to the new “Blinds” device type in Google by the SmartThings team.

I would love for the action.devices.types.BLINDS device type in Google Home to map to the “Window Shades” capability in SmartThings, when can we expect this to happen?

4 Likes
2

The question is… Are “Blinds” and “Window Shades” the same thing?

If not, then the responsibility is not SmartThings to make them the “same”.

If they are not the same thing, then responsibility is for Google: They need to add compatibility with the different Capability “Window Shade”.

3

@tgauchat. In my case I’ve 23 blinds (yes blinds, no shades) controlled by zwave actuators. They only way to handle them accordingly in SMT I’ve found is by using the “Windows Shades” capability. When will I be able to control them from Google Home, as what they are, blinds (or shades, I really don’t mind as long as I can open or close instead of turn on or off). Are there any plan for this? Any workarrounds I can try?

4

I don’t know the specifics of Google Home (nor Alexa) support for particular device types and the associated language cues, etc…

It is not even clear who is responsible for developing the “skill” (i.e., the interface): Is it SmartThings or is it Google & Amazon; or both? I think for the case of smart home skills, it is a combination effort. Both voice platforms are designed to control lots of different brands of smart devices, and thus they at least must try to specify consistent standards and guidelines so that activation of heterogeneous brands is as seamless as possible.

For example, it may be obvious, but not taken for granted, that the phrase “Turn the kitchen light on” must always translate into the applicable “switch.on()” command for each brand of device.

Thus the less common device types (i.e., blinds) are stuck in limbo.

I presume Google Home has a phrase definition to “Raise the bedroom blinds”; but, as stated above, it is not 100% clear whose responsibility it is (Google or SmartThings…) to translate this to the applicable SmartThings Command - and if no directly mappable device type (SmartThings “Capability”) exists, then that same responsible party must decide whether or not they can and should make a (reasonable) assumption that “Raise the blinds” should translate to SmartThings’s “window-shade.open()” command (as documented here: https://smartthings.developer.samsung.com/docs/api-ref/capabilities.html#Window-Shade)

So there are a lot of ways that this could be accomplished and only 1 is within control of us “little people” developers:

  • (a) SmartThings and/or Google agrees that “Blinds” and “Windows Shades” are the same thing and therefore the appropriate Commands to issue are easy for them to agree upon.

  • or (b) SmartThings adds Capability “Blinds” and makes sure its implementation is compatible with Google Home’s existing assumptions about “Blinds”.

  • or (c) The Device Type Handler for your Z-Wave Window Shades needs to masquerade as any Capability (device type abstraction) that is a common denominator between SmartThings and Google Home. At the current time, I think the only practical common denominator is “Switch” (i.e., “on/off”, or possibly “Switch Level” (i.e., dimmer level = percentage open/closed).

5

Thanks for the quick response. I’ve already taken option C myself with a custom DeviceHandler successfully (coming from Domoticz myself, I should way that I was surprised how easy and flexible it was) :slight_smile: .

I understand there’s an agreement between the different vendors and providers, but I don’t agree with you in that “limbo” thing. IMHO, I see more (if not all) responsibility in the SmartThings side. Let me explain myself.

Hardware vendors provide different solutions including actuators and sensors (also more complex devices but that’s another issue). This vendors don’t necessarily tie an it’s sensors and actuators with the usecase they are going to be used for (i.e. I’m using philio PAN06 to control my 12v blinds, but I could be using it also to control an electrovalve, a garage door, etc). IMHO it’s the hubs responsibility to provide the user with the tools to take that low level actuators and sensors and turn them into top level concepts. At this point if for some reason blinds, is not the same as shades for any functional reason, then both “capabilities” should be present in the hub. So if they are not, there are only two possible responses there:

  • SmartThings has taken the decision that blinds and shades are the same from the functional perspective, and thus has offered a single capability for both.
  • SmartThings is lacking the blinds capability.

On the other hand we have the “user agent” provider, in this case the google home. Here there’s indeed an agreement in terms of which one is responsible of developing the bridge between both devices. In this case (may be due to the “power” of the google home devices in contrast to the SmartThings hub, or because Google can’t develop bridge for every device in the market), AFAIK it’s SmartThings’s responsibility to develop that bridge.

So assuming the first option in the list above, the bridge is lacking the mapping between the SMT shades and the GH blinds. Or, if assuming the second point, there’s a lack of a Blinds capability and it’s mapping in the bridge. In any case the SmartThings bridge lacks the mapping and there might also be a lack of a capability.

In either case… Given that Google Home already provides an API for Blinds, I think it is SmartThings’s duty to provide us users with the convenient tools to map our actuators with that API.

Any way, I understand it’s not possible to have every single functionality implemented from day one. I was just expecting some roadmap on this matter (or a workaround if any, that doesn’t imply writing my own google home commands or having to say “switch on/off” to my blinds).

6

  1. Declaring that something is “SmartThings’s duty” won’t make it so. You can’t impose a duty on anyone - it is up to them to decide what roles to perform.

  2. Of course not every function or feature is available. Most functions or features will never be available. The wishlist is always infinite.

  3. SmartThings does not provide “road-maps”. They sometimes give very broad outlines of future features and the Capabilities list on the Samsung SmartThings Developer site does include a few entries tagged “proposed”, but that by no means a complete roadmap nor any sort of commitment.

  4. There is no workaround on the SmartThings side. There is no way for a Device Handler to claim a Capability that does not exist - i.e., There is no way for your Window Shades to claim to be “Blinds”. Perhaps Google Home is more flexible and they can choose to consider Window Shades to be Blinds - but SmartThings cannot.

  5. If you have a problem with any of the above, contact Samsung SmartThings Developer Support (available on the Samsung SmartThings Developer website).

7

Don’t take me wrong (specially for point 1, I was not trying to impose something, I probably should have used a word like task rather than duty. English is not my mother language so I apologize and step back if that sounded rude in some way). I completely understand the problematic behind this integrations. As for a roadmap, I would accept something like “hey guys, as google home now can handle things that open and not only things that switch, we are working on a capability to match that skill” :slight_smile: .

8

You won’t ever hear that from SmartThings, but if you do, then either:

  1. It means it is imminent (i.e., already implemented and in QA or Beta).
  2. or The person offering that statement is unauthorized to do so and has no agency or ability to fulfil the promise.

i.e., Samsung SmartThings does not give announcements of features under development; except when they do, and when they do, they have tended to either deliver very late, never, or very different than implied.

9

This needs to be fixed so so annoying that can’t control my blinds with Google.

1 Like
10

Use my dht and simply say “turn on…”

11

As an update on this, Google Home now supports action.devices.types.SHUTTER as well, see here.
I hope this should fit SmartThings’ needs.

12

This is exactly why I moved away from Smartthings still no native lock or window cover support for Google.