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. 
-
The ability to easily review and set zwave associations through the official features
-
The ability to run a Z wave replace utility
-
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.
-
ability to easily set up zwave central scenes through the official features
-
a mapping tool to display the full zwave network map, not just an individual route capture as the IDE has done
-
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.
-
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.
-
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.
https://products.z-wavealliance.org/products/3840?selectedFrequencyId=2
https://products.z-wavealliance.org/products/3858?selectedFrequencyId=2
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.
https://products.z-wavealliance.org/products/3791
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.
-
support zwave controller shift
-
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
- add and manage secondary zwave hubs through the official UI.