Gaps in SmartThings’ Zwave Implementation (2024)

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.

  2. added in 2024 at this point most of the competing Z wave hub manufacturers have moved to the series 700 chip, and some are already working on series 800. The SmartThings/Aeotec hub is still on series 500, there’s no Z wave at all in the newest Samsung SmartThings station hub, and Samsung has indicated publicly that going forward they are committed to Wi-Fi, Zigbee, matter over thread, and some Bluetooth, but specifically not zwave. So pretty much anything that requires series 700 or newer is now on the gap list. And that includes the ability to change the zwave frequency of the hub for different regions. It’s possible that aeotec’s ongoing commitment to Z wave, which is different than Samsung’s, may mean that eventually we do see at least a series 700 SmartThings compatible hub from Aeotec, but at the time of this writing, nothing has yet been announced, but they are definitely lagging the competition in this area.


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.


Are you referring to devices like the Zooz ZEN32 Scene Controller, JD?

If that’s the case, it is now possible to run this Scene Controller locally with the Zooz provided Edge driver. I have one and love it! Very reliable, local operation of devices or Scenes (e.g., Manually Run Routines) that themselves run locally.

Edit: as @h0ckeysk8er correctly points out…

1 Like

For v2/v3/Aeotec/SmartStation hubs only.


No, that’s a different device class, “central scene controller.”

“ local scene controller“ is a specific device class in Z wave and refers to devices which are allowed to send commands directly to the end devices without going through the hub. Back in 2015, there were a lot of posts about these, because people wanted to use them with SmartThings, and there was no way to do so because smartthings didn’t know which button had been pushed.

In contrast, central scene controllers like the Zooz do notify the hub. That’s a newer device class, and was needed once everybody started using smartphones and wanted to see the current status in an app on the phone. So a new command class was introduced, “central scene.” Because local scene controllers don’t send their messages through the hub, the hub, and consequently, the app, is often unaware of what’s going on.

Note that, in this context, “scene“ is referring to zwave scenes defined under the Z wave specification. Not to smartthings scenes created in the SmartThings app.


Thanks for the explanation, @JDRoberts–as always! :sunglasses:


I should probably have specified in the first post that this whole thread is going to be in the context of the independent third-party Z wave specification, not smartthings’ terminology. :sunglasses: