Extend Groups to support Blinds

Request
The Group and Scenes App effectively creates Lighting Groups, via the associated Group Bulb Dimmer Devices it creates/manages.

There are other Devices that would benefit from [type-specific] Grouping.

eg. Group Blinds

In my case, I'd like to be able to Group my Blinds, and have the RM recognize this as a type-of Blind, presenting actions like up(), down(), and not the colour-related capabilities used in Lighting.

Background

I have 6 Bali AutoView (Somfy) roller blinds and I'd like to control them together (for mode-based night/day operation).

These are registered as Generic ZWave Shade devices.

As a new HE user, fresh from openHAB, I gravitated to putting them into a Group in order to get this behavior.

The current Group definition exposes Lighting options like on and off, and not the Blind options. It's also less intuitive to use this for Blinds.

eg. is "up" on or off ? for a roller shade, a conversation frequently had with SWMBO when I setup Alexa :stuck_out_tongue:

So this led me down a couple of new-user rabbit holes, that I list below for amusement...

  1. RM permits using these Groups in the Raise/Lower Shade options, runtime presents an error.
    The RM UI allows you to make the selection for the Raise/Lower Shade actions, even though the Group it doesn't support the capability. When this action is executed, runtime presents an error:

    [app:386] (http://192.168.6.200/logs#app386) 2019-03-05 07:30:00.686 am error java.lang.IllegalArgumentException: Command 'up' is not supported by device. (allHandler)

  2. RM restricts listing multiple Blinds in it's Raise/Lower Shade options.
    This restriction pushed me even more to trying out Groups, as the logical work-around.
    @support_team : This RM limit is also referenced by @Navat604 here, but not sure if it was ever bugged:

    Somfy ZWave Blinds (Dimmer) - #133 by Navat604

Related Links

Config

  • HE C-5, 2.0.6.112

10 Likes

You want Dimmer Sync. It won't show them up as blinds but at least you would be able to use the setLevel or raise or lower dimmer commands.

The problem with Begin rasinig and begin lowering with blinds....what if they don't move at the exact same rate?

Right now my work-around is to use them as a regular Group, from Groups and Scenes, and tell the Apps (RM, etc) that these are Lights to turn on/off. This works ok for me, since they're roller blinds and I always have them fully open, or or fully closed.

The downside is that other integrations see them as Lights instead of Blinds and, by default, behave differently.

eg. The default "Turn on Family" in Google, for example, interacts with the Blinds... since it sees them as Lights. It used to turn on my Coffee machine for similar reasons.

Luckily there are work-arounds for these cases also, but I'm looking to see if the default behavior could be tweaked to better support the downstream entities (the ones looking at a Device's exposed capability list)

In openHAB when you declare a Group you also declare it's type (eg. Switch, Dimmer, Rollershutter, etc) - avoiding the need for an "Omni Group" that covers all the cases, but has to mess with the Capabilities list.

A workaround for that is to put them in a separate room in Google Home. I have one room for Fans and One room for Blinds. Not a fix but might help.

Yup, that's the work-around I implemented. In some cases, you can also change the type information in the client (Some Alexa devices allow this)

The request is to make the pieces work better together, by default, for all the parts. The work-arounds are great, but it turns out you need a long string of them to get it clean end-to-end.

It'll get to my muscle memory eventually. It'd be handy for new users not to require that knowledge up front (and avoid the same mistakes!!)

+1 for supporting some type on groups - Group of blinds, ground of switches, etc. You can manage some of this with a given UI provider but the group should not have all these commands that do not work / fit the context enabled.

1 Like

Which driver does one use for these Groups? No drivers seem to work for my shade groups... all non-responsive :frowning:

Adding my vote for this feature request. Grouping blinds in Hubitat for use in Alexa is just not working well for me. I've gotten around it (sort of) by creating Alexa routines, but it doesn't give me control to ask for a % open.

SmartThings had a SmartApp called Shady which added this functionality. Worked great with Alexa. Though I do think the changes on their platform has since hobbled that functionality.

1 Like

Hello guys,
Just arrived in HE and this is a nice feature I'm missing.
(Open all blinds, close all blinds, set all blinds to x%)
I've Qubino Flush Shutters working great :slight_smile:
Adding my vote for this feature request!

Adding another vote for Hubitat Group support for blinds/shades, specifically allowing the controlling device that is created to be Blind/Shade.

Exposing the group as a dimmer or switch as currently happens tends to cause problems with subsequent automations using the group. This could be avoided if the group is a Blind/Shade device.

+1 on Group support for blinds/shades. I'm currently working around this using Group Dimmer, but it's commands are "on" and "off" vs. "open" and "close".

1 Like

I also would like to be able to create groups of blinds. My current workaround of using the "virtual shade" device driver is woefully inadequate. It is poorly responsive and does not support partial opening/closing.

2 Likes

I vote for a shades group support as well.
Currently I can't create an automation where several shades are set to a specific level while using generic z-wave shades driver.

+1 from me. I have 3 rooms with multiple shades and have little reason to control them individually.

+1 from me too.
I've just installed 3 blinds in a bay window and would love to be able to group them. Essentially for group messenging purposes so they act in unison - the same as getting rid of the "popcorn effect" with groups of smart bulbs.

Yeah. I know it's at bit picky but having them raise/lower all together would give my OCD a break!

+1

+1 from me on this feature

+1 but implemented with a thought to future proof the application thereof and think "beyond the window shades".

There are a number of "step motor" applications I bet we can come up with where coordinated / syncopated action would be desired.

For example:

Exterior solar blinds / louvers / shades / awnings

Freestanding solar panel array single axis rotation (yeah, there are systems designed for this, but...still)

Coordinated multi-pump fill, mix, or circulate operations

Simultaneous window shield deployment and moat bridge raising for castle entrance and exit.

OK, some more practical than others. :rofl:

And before someone says...."I'd never trust pump operations to an HA system"
I guess I'd say...today we live with cheap HA devices with reliability all over the map, but it doesn't have to be that way ...and likely won't be as time goes on. There is a large chasm between HA and plant, manufacturing, facility/building automation, ...but some common aspects of these will likely get closer in capability & quality sooner than later. Just as the computing power and data storage in your pocket once took a whole building to accommodate.

1 Like

+1 for native blind shade device support in Groups. Also having issues now with Siri not recognizing open/close for groups of shades defined as dimmers.

3 Likes

+1. This would be handy so that my RM rules only send close/open to members of a group that are confirmed to be in the opposite state.