As interesting as it may be to add new and esoteric devices to SmartThings, it seems much more focus should be made to getting the basics to work right. SmartThings is in many ways still too much of a hobbyist platform, where much appears to be “almost good enough” rather than a finished product. Take, for example, dimmer switches. The Smartthings Z-Wave Dimmer device handler still doesn’t support using double-tap and triple-tap via Central Scene to create buttons on a evice. Yes, you can find “community” drivers that provide this, but they can’t run locally. What about Over The Air device firmware updates - ZWave Plus chips have supported this for years, but accessing this is still MIA in SmartThings. Set dimmer switch ramp-up / ramp-down parameter values - still need to find a “community” implementation or write one. Set device association values - nope, can’t do that either. These are all things that have long been in HomeSeer and other platforms so it can’t be that hard to get it done. Yeah, controlling my lawn sprinkler or pool pump might seem interesting, but not when the basic light switches are still
Using date from their cloud platform, SmartThings should be able to figure out the top-100 or top-200 devices and have these 100% working for all features. Its a long-way off from that.
This is a great point, but one that simply doesn’t fit the ST model. Almost every “feature” you name is specific to Zwave and is not universal. It would complicate, clutter and confuse the general user, especially someone who buys a ZigBee device and doesn’t understand why they don’t have the same features. The purpose of ST is that you don’t need association because you can link any device to any other device via a smartapp. ST will always be inferior to protocol specific systems when it comes to integration of protocol features, updates and reliability; but it allows you to pick almost any device and find a way to make it work. It’s the tradeoff you have to live with to use ST.
It drives me nuts, but with a little time and effort, I can add these features or someone else here will. The prime example is what @JDRoberts references below, which could be a simple SmartApp or better yet implementation of association/scenes for zwave and groups/scenes for ZigBee. My favorite example is the Gentle Wake Up that raises a lights dim level every few minutes to simulate sunrise. A lot of the same bulbs that people use with it are capable of being sent one command to slowly dim up over 30 minutes instead, but it would only work for ZigBee bulbs. ST sticks to basics: on/off, light level. That’s it.
Zwave dimmers which use the central scene commandset can capture a double or even triple tap at the device, which removes the problems of cloud latency.
In the US, the new homeseer line can do this and there are a number of community members using it.
In 2017, GE introduced a new line of zwave switches (model numbers beginning with 14 instead of 12) some of which can also do this, but they are just starting to come to market.
In the UK, Devolo makes a device that can do this also.
So it’s doable, but right now only with zwave.
I know I’m a minority opinion in the following, but I think SmartThings should just colorcode devices in the app on the basis of protocol, green for Z wave and red for zigbee and orange for Wi-Fi or whatever. Then colorcode various options and utilities. I think people will figure it out very quickly, and it’s easy for support to work with. I don’t see any reason to pretend that these protocols don’t have significant differences, because they do.
Trying to pretend that everything is exactly the same under the abstraction layer is what leads to People not knowing that they need to update the address tables after they add new repeater devices. Or for that matter, not knowing that different devices repeat for different protocols.
I think you can still have a mass-market friendly user platform without disguising the fact that you’re supporting multiple protocols.
ZWave Plus dimmers often support the Central Scene command class with provided double-tap and triple-tap controls (basically, they switch maps double-tap and triple-tap to button events). Works well, but not supported by default dimmer Device Handler. You have to find or write a Device Handler to support the functionality. That was my original point – too much “basic” stuff is still left to the “community” rather than in the officially supported platform. That’s the difference between a hobbyist product and a “real” mass market consumer product.