Any Z-Wave Thermostat?

I don’t care how automated your thermostat is, if you have a wife, eventually it better be easy to adjust every 30 minutes… :blush:

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 :wink: . . seriously

2 Likes

He didn’t try that on the next wife, did he?.. LOL

5 Likes

Please remind me to remind you to put this response into a FAQ, as soon as @April creates the FAQ category!

1 Like

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. :wink:

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?

  1. 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?

  2. 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 :wink:

1 Like

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”?

I use the typical definition of scenes, both zigbee and zwave use it. Network Engineering 101. The terminology may be slightly different, but essentially

One button can cause multiple different actions to occur at about the same time on different devices with different parameters being sent to each device. (Note that this is different from sending the same command to every device but having it cause different actions just because of the device type.)

Usually there’s a schedule table as well.

In full option scenes, which zwave offers, you can send any command with all the parameters supported by the receiving device.

Zigbee is different because there are different types of scenes (like colour vs noncolour) and not all device types support scenes. So zigbee right now offers limited option, limited device scenes. I don’t know what’s going to happen in zigbee 3.0

Common assumption, but not how the ST hub actually works at present. Some stuff is just missing, which is why some older GE handheld remotes and keypads can never be made to work with the ST v1 hub unless the remote is initialized by a different hub like Vera first. You can’t code your way around it. Search the forum for the 45631, you’ll find lots of discussion.

1 Like

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…):

  1. 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.

  2. 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.

  3. 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.


BINGO!

@jwindsurfer
I strongly suggest that you & everyone assume the device of your choice will NOT work with SmartThings unless it is in the officially supported list, and observe the footnotes as well. (And, see related discussion that I think this list could be more accurate too).

Come on over and join the new Topic / Conversation… :smiley:

I’m not sure what you meant by ‘certified’ in this context, but just to set the record straight, SmartThings hub is an officially certified Z-Wave product. Its certification number is ZC08-13080013.

Just for clarification, Z-Wave certification does not require device to implement every Z-Wave command and feature imaginable. It only requires device to implement what Z-Wave calls mandatory commands for a particular device class.

Smart Things hub is a certified Generic Static Controller and as such, must implement only Basic Command Class. That’s ALL! Of course, it implements more than that (the full command list is in the Certificate), but the “missing” Controller Replication command class is not of them.

Bottom line, Z-Wave certification does not require controller to implement replication. We can argue whether it’s good or bad, but it certainly does not make Smart Things hub non-compliant with Z-Wave specification.

Thanks for the correction!

You’re quite right, the ST hub is zwave certified as a generic static controller at the Basic level, but as such it supports fewer than 20 command classes, as compared to the typical 25 or so from the competition.

ST
http://products.z-wavealliance.org/products/878/embedpics

Vera lite:
http://products.z-wavealliance.org/products/1005/embedpics

Staples Connect DLINK

http://products.z-wavealliance.org/products/1145/embedpics

But then the Wink is the same set as ST, so at least they’re not the only ones at that level.

I’m curious, though, the conformance statement doesn’t show schedule entry lock on ST’s conformance statement, but the ST developer doc says it’s supported. So I’m guessing things have been added since certification testing?

Also is the meter class supported?

Thanks, and apologies again for previous misstatements, I’ll clear those up over the next day or two.

1 Like