Looking to drop Wink (yes, lesson’s learned) and have the following items on the network that would need to be compatible. While there is a good change some of the basic binary devices will connect, would be interested in knowing if anyone has these devices successfully connected before going into the investment of the purchase and time to experiment. Thank you in advance.
Wink/Quirky window/door sensors
Skybell (ideally w/some real functionality)
Yale lock (looking for more than the binary lock/unlock, such as temporary codes)_
Nest Thermostat
Nest CO2/Smoke Detector
GE/Jasco Outlets
GE/Jasco Light Switches
Wink/Quirky water sensors
Zooz valve control
Chamberlain MyQ Garage Door
Quirky Pivot Power Genius
Quirky Refuel
Wanting to add:
Ceiling Fan/Light controller
Controller for VLUX Skylight (which uses a rather poor OEM remote control currently)
(I moved this to the projects category since you’re asking about so many different devices, and we try to keep the devices category to one device class at a time. Otherwise it becomes really hard to go back into the archives later and find anything.)
There is an official compatible devices list. You’ll find the GE/Jasco switches and outlets on that for both zwave and Zigbee.
Unlike wink, smartthings allows you to upload a custom device handler to your own account. This makes it much easier to add compatibility for devices which are not on the official list. This is a very powerful feature.
Many community members enjoy the challenge of integrating new devices, and will post their device handlers in the community forum section available for those. That way other people can use them as well.
However, you then run into two potential issues. First, smartthings may make a platform change which breaks custom code. This happens pretty often. Usually the code author will then find a way to make it work again, but it’s something to be aware of.
And sometimes the custom code is actually a violation of your terms of service with the device manufacturer (this is true for both nest and Chamberlain my que and sometimes the custom code is actually a violation of your terms of service with the device manufacturer (this is true for both nest and chamberlain myq) which means you then run the risk that the device manufacturer will shut down the integration. This actually just happened this week for myq.
Finally, at the present time custom code is not eligible to run locally if the Internet connection to the smartthings cloud is down. So that’s just something to be aware of as well.
The process of using custom code is very straightforward.
Link to forum section with community-created custom device handlers:
Authors are encouraged to submit their custom device handlers to SmartThings for official publication, but this can take a long time, and there’s no guarantee that it will be accepted. Again, a good example is nest, where there has been working community code for I think two years, but it is not official because it’s using an unauthorized communication method.
One of the main issues that device manufacturers have is that smartthings is a very powerful developer platform in that it gives you access to pretty much all of the features of the device that have been “exposed” (that is, that someone has found the code for). However, several device manufacturers would prefer to limit third-party access to a specific feature set. This could be for security or stability reasons.
Wink, for example, because it doesn’t allow for custom programming, qualifies for some official partnerships that smart things does not, just because the feature access under wink is limited.
On the other hand, because smartthings allows customers to modify device handlers, it’s way easier to add new zigbee devices which are certified for the zigbee home automation profile to a SmartThings installation than it is to a wink account.
So from a customer point of view, there are pros and cons to each approach.
The Yale lock is a perfect example Of where smart things approach to custom code opens up a lot of features.
Some Yale locks are on the official compatibility list, but with a limited set of features. ( check the exact models under consideration.)
On the other hand, community members have created custom code for it which opens up the feature set considerably. This is a very popular option.
So if you just look at the official list, you’ll see one set of features. But if you check the community, you’ll find a much more powerful integration which is very popular.
Regarding the skybell, One of the employees said just this week that they are getting close to unofficial SmartThings integration, but it’s not released yet.
Meanwhile, since both SmartThings and skybell have an IFTTT channel, you can get indirect integration that way. If you’re not currently using IFTTT, you want to check to see how much lag you get. At my house we get a pretty reliable eight second lag for most IFTTT requests. But people who live in other parts of the country have reported lag of as much as two minutes when a recipe fires.
In addition, you can be a polling delay of up to 15 minutes to fire a recipe if it’s based on a switch or sensor reporting.
So it just comes down to your own use case as far as whether the IFTTT method will work for you or not.
)