Gaps in SmartThings’ Zwave Implementation (2022)

Just putting this here to document some observations. It would be nice if some of these gaps got plugged in the future, but I don’t know if they will. Historically, smartthings has liked to use its custom overlay (originally device type Handlers, now edge Drivers) to hide protocol-specific features from its customers, and that has driven a lot of its design philosophy. But there are some basic features that I would expect to find on any certified Z wave hub from a major company, but which are currently missing from smartthings. :thinking:

  1. The ability to easily review and set zwave associations through the official features

  2. The ability to run a Z wave replace utility

  3. The ability to set up an automatic schedule for running a Z wave repair as part of regular maintenance. Most of the competitor hubs recommend running this either once a week or every night, but smartthings support has from time to time told customers not to run repairs because they can make zwave problems worse under the smartthings architecture. :disappointed_relieved:

  4. ability to easily set up zwave central scenes through the official features

  5. a mapping tool to display the full zwave network map, not just an individual route capture as the IDE has done

  6. most competing hubs will support at least 150 Z wave devices. (The spec allows for a maximum of 232, but memory restrictions on hubs do sometimes limit that.) A couple of “LITE“ models such as vera LITE recommend no more than 75. Several different people have said that smartthings support has told them they shouldn’t be using more than 30 to 35 zwave devices in a smartthings set up. If that is true, the hub should be labeled LITE on the box so that customer expectations are set appropriately.

  7. ability to support local scene controllers, although I would set this feature as a lower priority since there aren’t very many of these around anymore.

  8. ability to address multi endpoints on a single device easily, including for control by voice assistants. Also, to avoid future mistakes, note that a single device can have many endpoints, and should not be artificially limited to two or four or six as smartthings has historically done. (Also, all the maximums are going to go up with series 800, although obviously that’s still in the future.)

I have previously listed a number of specific models as multi-endpoint examples, so I’ll just put two here:

The Heltun Quinto touch panel allows for five inputs and five outputs in a single device and up to 20 association groups. The matched Quinto relay has 5 endpoints and up to 16 association groups.

The popular Zooz double switch has two buttons: a dimmer control for a light and an on/off button typically used for a bathroom extractor fan.


Smartthings customers should be able to use Alexa or Google Home to individually control these multiple endpoints, and be able to give them custom names for use in the Smartthings app.

  1. support zwave controller shift

  2. support “over the air” OTA updates to zwave devices. This can be done at present but requires that customers add a secondary Z wave controller and buy the software from a third-party. It should be a standard feature for the primary hub.

Support of OTA firmware updates for Z-Wave / Z-Wave Plus devices

  1. add and manage secondary zwave hubs through the official UI.

These are all very valid needs and requests thst should indeed be included in the hub of what is concidered an industry leader but in the grand tradition of Samsung… ignore requests of basic useful features and instead throw together some smart apps that only work on Samsung Gear/devices (aka Air Care, Energy, Cooking, Clothing Care, Home Care). I mean seriously, how many people actually use these smart apps considering they only work on certain Samsung products? As worthy and valid as your post is JD, it will only fall on deaf ears…Samsung is only interested in useless fluff.

To be honest, I put this here more for the community’s use, so that if they find references elsewhere to various zwave features, including in product descriptions for devices they were considering, it would be easy to see if those features were missing from the smartthings implementation.