To the best of my knowledge, this can be “easily” implemented with a SmartApp (and perhaps some Virtual Devices to trigger and/or hold scene state data if necessary).
Ref: Scene Machine as a pretty good Proof of Concept.
Reference this thread that I rather dislike because too many participants dismiss “Scenes” as unnecessary in SmartThings, smh.
But you know of this thread already since you’ve participated extensively…
So, in Summary…
Without taking this Topic on a further tangent (we can, however, start a new Topic if desired for discussion…):
-
SmartThings should not imply they are “fully” or comprehensively Z-Wave compatible, unless “partial compatibility” is de facto in the industry and marketing materials across Z-Wave products.
-
SmartThings should improve their “Works With SmartThings” web page (NB: pre-sales web page!) to clearly distinguish “full supported devices” vs. those that are partially supported, in development, in Beta, Labs, etc… I think the hover “
i
” indicator is insufficient, but, well, at least it’s there. -
Given #1 (i.e., SmartThings is not and may never be a fully Z-Wave (or ZigBee?) compliant / compatible system), Customer and Developers should never expect the Z-Wave and/or ZigBee definition of “Scenes” to be implemented. This should be made clear pre-sale as well. However, many of the elements of those standard definitions of “Scenes” can be emulated without any platform architecture changes (i.e., can be implemented with only SmartApps and/or Virtual Scene Devices). It would be interesting to explore, confirm, and document the exact aspects of “Scenes” that can be implemented in ST (i.e., the minimal incremental feature request), and then compare this implementation of “Scenes” bullet-by-bullet with the Z-Wave and ZigBee standards, and any other applicable similar standards (Lutron?).
I hope my Summary is accurate, but respectfully suggest we spin off to a New Topic for further discussion, and/or move to an existing applicable Topic.