Will most Z-Wave thermostats work on the system? Or can I only use the listed ones easily?
What about Z-Wave in general? Can I use most Z-Wave products without having to custom code some kind of driver? (Excepting of course occasional incompatibilities or poor z-wave implementations.)
Thanks.
The point of z-wave is that everything just works . . . . at least the core functions. A device-type (driver) is required, however, in SmartThings. A good strategy is to search here for a device you are considering to see if there is any experience that has been shared and/or device-types written by community members.
There’s a difference between “works with zwave,” “controllable through the standard app supplied,” and “supports all zwave functions for a certified device of the declared standard type.”
SmartThings just recently joined the zwave Alliance, which is good, but at present the ST hub is not a certified zwave device, so it falls into the “works with zwave” category. Meaning most, but not all, certified zwave devices can be made to work with it at least in an on/off fashion through custom code, but not all zwave supported features are offered. or available through the standard app.
A perfect example is zwave scenes. The standard ST app has Hello
Home Actions, which are limited option scenes, but you do NOT have the ability to set every standard parameter for every zwave certified device. Just some parameters for some devices.
Another example is secondary controllers. Some zwave certified handheld remotes work with ST, some only work after they’ve been initialized by a nonST hub. The ones that don’t work are an older type using a command that ST doesn’t support. But zwave is supposed to be backwards compatible, older shouldn’t really matter for a certified device.
People in this forum have been very generous and offered many custom device types, which is great, but the concept of zwave is that custom code should not be required for certified devices doing zwave supported functions. Only if the devices offers nonstandard functions.
With the announcement of the second gen hub and the very recent announcement of zwave alliance membership I am optimistic that by summer 2016 the ST hub will be zwave certified and offer full support through built in standard device drivers and that the new rules engine (announced separately) will allow full zwave scene management.
I really like the support ST offers for those who enjoy custom coding. But while I can code, i don’t want to. (I am quadriparetic, and using voice to enter and debug groovy is tedious.) So I want to see full standards adherence PLUS the development platform.
I’m really happy that ST lets me mix zigbee and zwave devices and wifi devices under one controller. But I want the same granular control I would have if I installed any certified device under a vanilla certified controller. Including backwards compatibility if the certification supports it.
that’s not what we have today, though. We have some support for some devices under some control features. With much more support for many more devices and more control features donated freely by individual coders through custom code.
I do like ST and it works well for several important use cases at my home. I’m definitely getting my money’s worth at the present time. But I don’t buy any new device without first verifying here whether it will work in a way that meets my specific current need. And I’m waiting on some big projects until less custom code is needed. 
edited to add
@gecko corrected me to note that the ST hub is zwave certified as a generic static controller at the basic level, which does not require support for all command classes, only Basic. ST staff have also noted that some additional command class support has been added . All good. I had been trying to avoid mentioning the competition, but I should more accurately say that the conformance statement for the v1 ST hub supports fewer command classes than, say, Vera, something I found surprising.
OK, thanks, both of you. That answers my question. I’ve been “researching” controllers, hubs, technologies and clients for the past several days and there’s way, way more offerings now than the last time I looked at home automation several years ago. I was just about ready to pull the trigger on Vera, and then a final review of recent reviews came up less than satisfactory bad. I’m disappointed and actually surprised by the lack of full Z-Wave support, which I assumed was greater simply because the controller says it supports Z-wave. But I like the apparent support of 3rd party development.
I’m going to go all Z-wave so that if I want to I can change controllers without changing anything else down the road. I’m not sure I want the thermostats listed. None of them look like the screen is very readable. My thermostat is in a dark hall and my sight is not that great, but I also don’t want some bright light either, so big writing and lots of contrast is in order. I don’t need weather report or other extra information I have a huge computer screen or TV for that. Just the temps 
Good rundown. I think the further they get toward standard, out-of-the-box z-wave functionality, the better the system will be. Scene control would be great as well as plug and play.
something to consider. . . in an automated home, you wouldn’t really ever have to interact directly with the thermostat.
I don’t do things on a predictable schedule, so what I end up doing is setting my thermostat schedule to be very conservative, and then manually increase the comfort when desired. Then several times a day have it scheduled to return to the conservative setting. Yeah, I guess even then, I could use my phone, but I think sometimes the thingy on the wall will seem more convenient to me and definitely to a guest.
I don’t care how automated your thermostat is, if you have a wife, eventually it better be easy to adjust every 30 minutes…
And I mean no offense. It’s just a fact at a certain time in life.
yea, sure. But your system can understand who’s home and when, what rooms have activity, how often doors are open etc. I think the ultimate goal of home automation is to understand why you twidle with the thermostat and do it for you. Not to just run a schedule. Scheduling is just one aspect.
I think I’m going to market a fake thermostat for spouses (don’t want to assume we are all guys here even though we mostly are) that just has a display, a number, and up/down buttons that change the number. I knew a guy who was testing a new thermostat. . . left the old one on the wall. . . and his wife, for weeks, continued to twidle the old, disconnected thermostat and feeling as though she was adjusting the temperature 
. . seriously
He didn’t try that on the next wife, did he?.. LOL
Please remind me to remind you to put this response into a FAQ, as soon as @April creates the FAQ category!
Thanks, but I wouldn’t put it into a FAQ because it includes my completely unsubstantiated guesses about future certification and functionality. We don’t know ST will ever move out of the “works with category.” Maybe they’ll just improve the process of finding and installing custom smartapps and not worry about things like the older remotes. We just don’t know.
Like I said, ST solved a couple of critical use cases for me as is, and I definitely got my money’s worth–for now. I’m happy with my stage 1 set up. But I’m waiting to move forward until some big brand offers me plug and play solutions, with full scene capability for the other use cases I need. Could be Samsung, could be Apple certified partners, could be nest, could be Insteon. Could be somebody new. But because my particular use case requires a wearable and microlocation, I’m guessing Samsung or Apple.
But right now, no one has a plug and play solution for everything I need. And a lot of big brands are investing in the space. I’m willing to wait and see for another year or so.
SmartThings lets me unlock my door with my ipad, turn off a couple of lights in different rooms from my bed, use a couple of touchless switches even if they have to be strangely placed, and have a couple of lights turn on at sunset. I have the Minimote but I use it mostly for system tasks. None of that required custom code. I’m getting one more toggle switch which probably will require a custom device type so we’ll see how that goes.
My house is smarter, but it’s not smart yet. And most of my Things are smarter than my hub. Or at least better educated.
But as for the future, who knows?
I should go back and reread your post and distill the relevant requirements and definitions, but…
Can you give me the Readers Digest version?
Given a Device is listed as “works with SmartThings”, what is needed to make it “plug and play” that is currently lacking? Aren’t “most” such Devices plug & play, or most not? Which examples?
Scenes, in my definition, can be implemented with SmartApps and Virtual Devices in SmartThings. What do you think ST cannot support in your requirements of “scene capability”?
If there’s a one button install in the mobile app AND it supports all the nonproprietary functionality of a certified zwave device, that’s plug and play in my definition.
If I have to use the IDE or cut and paste anything, it’s not, in my definition.
A “sorta works” example from the “works with” list is the Schlage touchpad door lock.
I agree that requiring any use of the IDE is not “plug and play”.
Do you have an example SmartThings certified Z-Wave Device that doesn’t require the IDE to install, but also does not support the desired Z-Wave functionality? Next, can this functionality be replicated using STs platform?
Ie… What lock functions are missing?
Fibaro door/window sensor.
Just run down the supported items list and hit the “more information” little i button. Several products which are not in the lab say “only X is supported. Y is still in development.”
For zigbee, check any SmartenIT device with multiple functions, including energy metering or even just two toggles.
I have no idea which of the missing functions are caused by deficiencies in the hub or just the mobile app UI. And to be honest, since I don’t want to use custom code, i don’t care.
You know the line: “It just works.” That’s what I want for zwave certified devices.
The reason device manufacturers don’t already provide custom coded Java device types (which would also work in groovy) for their products is because customers aren’t supposed to need custom device types for certified devices!
The device itself tells the hub which standard zwave command classes it supports. Only if you hit “proprietary” should you need a custom type, and then the manufacturer should be providing that.
Yup… It’s listed on https://www.smartthings.com/product/works-with-smartthings/
What doesn’t work about it?
Hit the “i” on that item’s entry on the page. According to that:
“Fibaro Door/Window Sensor Open/Close Z-Wave
Only open/close is functional. Battery and other alerts supported by the device coming.”
Well, this is all good stuff to know. This was what I was not clear about. I think that any device that is fully Z-Wave compatible and well made can be made to be supported by writing your own driver, or smart app or whatever. And I’ve only just ordered my stuff, so will delve into that further. Worse comes to worse, I’ll have only spent $100 on the hub. As always, I’ve got big plans
Dang… I know of the “i”, but it doesn’t appear on mobile Chrome.
Regardless, I’d say then that SmartThings should make two lists and not bury this in the fine print (or hover text)… It is disingenuous to not make this clear at a glance.
So… In the meantime, let’s consider any device with that type of documented disclaimer as “not supported”.
Are there some on the list that don’t have a disclaimer?
And what about your definition of “Scenes”?