Grouping Lutron Caseta Shades?

Devices & Integrations Connected Things
1

Has anyone with Lutron Caseta Shades integrated into ST found a way to group them for the purposes of having one control point for many? For example, I’ve got three shades in a room that I’d like to control with one device in ST and have them all mirror each other. In the lutron app I’ve done this by having a pico remote setup to control all three and using that. I’ve tried Shady and some other app options, but it looks like things that normally want to control z-wave based shades don’t work with the Caseta shades.

2

I’d add a Virtual Dimmer and have a SmartApp control all 3 shades based on Events from the Virtual Dimmer.

Relatively simple SmartApp.

You could modify Trend Setter SmartApp for this too.

1 Like
3

I have forever been confused with virtual devices. How do I assign a virtual device to actual devices? I created the virtual dimmer switch, but that by itself is nothing without actually pointing it to the devices. How do I do this? Seems like a silly question I know.

4

Definitely not a silly question. “Virtual Switches” are not a feature of SmartThings. Seriously - I bet Support has not idea what they are, nor is there any customer facing documentation, help pages, video tutorials, etc; produced by SmartThings.

The engineers recognize their value, but the product managers have not made them an integral part of the product. Virtual Switches are pretty much as distinct from SmartThings as any add-on SmartApp like ActionTiles or webCoRE: The difference is that the latter 2 have specific places to get support, but you have to do a lot of browsing here, perhaps, to learn about Virtual Switches (and other Virtual Devices).

Note: Virtual Devices are sometimes called “Simulated” Devices. The Device Type implementations are sometimes identical regardless of the name.

In short (?):

  • A Device (real or virtual) claims a Capability and the Capability defines the expected Attributes and Commands. e.g., a Switch has a “switch” Attribute with values [on,off], and Commands “on(), off()”.

  • When a Device changes an Attribute Value it fires an Event. SmartApps (including Smart Lighting, Alexa, Automations, WebCoRE, ActionTiles, …) can subscribe to the Events of specified Devices and then reaction to them. Such as when Contact Sensor “front-door” attribute contact changes to open, then send command on() to “foyer light switch”. Or when Switch “hallway” turns on, then send command on to “foyer light switch”. That’s an example of one switch linked to another: mirroring it’s action. Both of the above rules can be implemented with the official SmartThings “Smart Lighting” SmartApp or Automations.

  • Most real (non-virtual) Device Instances get their Attributes set from real-world actions on the physical device. The door sensor opens = the device handler gets a ZigBee or Z-Wave message and then sets its own Attribute to open. Or a physical switch is tapped and that sets the Switch device’s own Attribute to on.

  • Most real (non-virtual) Device relay their Commands to the physical Device. The on() Command is translated by the Device Handler to a ZigBee or Z-Wave or Hue “on” message to be sent over the air to the physical switch, light bulb, or Hue Bridge.

  • The above 2 bullets are not applicable to Virtual Devices.

  • Devices don’t interact directly with each other: A SmartApp must be used (Smart Lighting, Automations, WebCoRE, etc.). You can’t link a Contact Sensor to a Switch without a SmartApp. Nor can you link a Switch to another Switch without a SmartApp.

  • So if you have a Virtual Switch - it doesn’t do anything in the real world. It just has certain Attributes and accepts certain Commands. But like a “real Switch” it can be used by SmartApps to affect other devices. If something - either the Device Tile in the SmartThings App or another front-end like ActionTiles, or another SmartApp Automation, sends the on() Command to a Virtual Switch, then any other SmartApp which subscribes to that Virtual Switch can use it to trigger on() Commands (or other actions) on real world physical devices: Such as a list of lights.

The last bullet is the key:
A Virtual Switch is a just an interface to receive Commands and trigger Attribute Events that can be used by SmartApps which treat them as if they were coming from a real Switch.

Advantages?

  1. You don’t need to install an extra real Switch to control a group of lights. That would get expensive and silly.

  2. You can use Virtual Switches as boolean (true/false) flags to share state information among SmartApps. For example, you could have a “I’m up late” Virtual Switch. And then have your various night-time Automations subscribe to this Switch not execute if that Switch is on. There are many more complex examples.

  3. Virtual Devices can also be used to have a Device of one Type masquerade as another. If you have a SmartApp or Alexa that will not “open()” a Lock, create a Virtual Switch so that Alexa can “off()” the Lock instead. And have a SmartApp subscribe to that Switch, and use it to trigger the Lock.

3 Likes