Hello,
I apologize if this has been asked many times before, I wasn’t able to find the answers using search.
I’m getting ready to buy a bunch of ST products as well as some Z wave products. My question is, do I need to buy any addition hardware for Z wave products to work with ST? Do I need some sort of Z wave receiver? Or can the Z wave products (EG: Thermostat, GE switches) connect directly to ST hub?
Thanks for your help!
SmartThings Generation 1 hub (the one currently being sold) contains controller and antenna hardware for both Zwave (but not Zwave plus*) and zigbee (using the zigbee Home Automation 1.2 profile**).
So you don’t need any additional hardware for most zwave devices.
However, ST doesn’t support all Zwave command classes (it is certified for the Basic command set) so if a device is not on the official “works with SmartThings” list it’s a good idea to check the forums to see if others are using it and if not, why not.
Make sure to read the tiny “I” Notes on the compatible products list as not all features may be supported. Also, if it says “SmartThings Labs,” that’s a Beta integration.
*Zwave Plus devices have longer range, better battery life, and over the air firmware updates. The devices are backwards compatible with Zwave, so you can still use the devices on a SmartThings network, but some of the features, in particular over the air updates, may not be available. So most community members do buy zwave plus when available just to get the better range and battery life for the individual device.
**Zigbee HA 1.2 devices should be compatible. Devices using ZIgbee Pro profiles (including Zigbee Home Automation Pro) may not be. ST has added some Pro features support, but not all.
JD you are the man. Thanks for such a quick reply!
What is the difference between Zigbee and Zigbee Pro?
Right now (this will change with zigbee 3.0) there are several different “zigbee profiles” which are used for communication. These vary a lot, even the addressing schemes are different.
The zigbee pro profiles were originally designed for industrial installations and have built in encryption and some other feataures intended for very large installations.
The original zigbee home profile didn’t include these features.
http://www.eetimes.com/document.asp?doc_id=1276377
AMI (Advanced Metering Initiative) is the profile used in smart meters. There’s also a profile for medical devices, one for telecom devices, one for retail etc.
http://www.eetimes.com/document.asp?doc_id=1278223
With zigbee home automation 1.2, a number of the Pro features were added to the Home Automation profile.
http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbeehomeautomation/
“Zigbee Home Automation Pro” isn’t an official standard, it was originally an alternative name for what is now officially called Zigbee Building Automation. Intended for large installations with significant security and energy management requirements, plus some specific certification requirements. Just as an example originally there was no lock management in zigbee Home Automation, you had to use Zigbee Building Automation to get that. (But that changed with 1.2)
Coming soon will be zigbee 3.0 which will fold together the most popular public zigbee profiles: Home Automation, Light Link, Building Automation, Retail, Healthcare, and Telecommunication. (Notably not included in the first phase is Advanced Metering, now called Smart Energy.)
The main point for SmartThings is that devices which are certified for Zigbee Home Automation 1.2 have a good chance of working with SmartThings. Devices that use one of the other profiles, including Zigbee Building Automation and Zigbee Smart Energy, are less likely to work SmartThings at the present time.
But with zigbee there’s always the possibility that a manufacturer has added some customized profile elements which will make the device not work outside of their own ecosystem. Zigbee 3.0 is also intended to address that by limiting the 3.0 certification to interoperable devices.
As for why there were such differences between the profiles–encryption is costly at the end device level. The devices have to be smarter, which requires more energy draw. The same was true for some of the addressing and routing schemes. So Zigbee tried to offer the cheapest possible hardware solution for each of the expected use cases. This meant varying the feature sets offered.
Over the last five years, though, particularly with the advent of SoC devices, this became less critical and demand for wider feature sets grew. So finally market demand changed the way zigbee was presented, and now the profiles are being combined (with full backwards capability). That doesn’t mean all devices will have all capabilities, just that there’s no artificial division into profiles.