I can’t speak to Google, but certainly it’s available on Apple HomeKit and other Home automation platforms. Quite often it’s called “plug-ins,“ and they may be provided by the manufacturer or other community members.
Apple definitely has these.
The Device Handler Concept
Before going into more specifics, I think we need to talk about the architecture a little more. I would have to somewhat disagree with this characterization of the whole concept:
In other words, in SmartThings, the device-specific functionality lives EXTERNAL to the device (whether on the hub or in the cloud). So, the manufacturer of a device (eg, a light switch) creates that handler (and perhaps allows third parties to modify/replace it) to interface its device (and its own built-in firmware) with the SmartThings platform.
The device specific functionality always lives in the device itself. The device type handler is simply a driver, just like a printer driver on a PC. It exposes certain functionality of the device to the platform and formats messages to the device in the expected format. But that’s all it is, a driver. If you add functionality to the DTH that is not in the device itself, it will not be performed. A printer which is black-and-white only will not turn into a color printer because you use a different driver. A smart switch which is only a binary on/off switch cannot be turned into a dimmer because you use a different DTH. If a battery operated sensor does not report battery levels, there’s nothing you can add to a DTH to get them.
The functionality is in the device. The DTH is the driver that allows you to process messages to and from the device to access that existing functionality.
That’s the same way that plug-ins work on other systems, like Homeseer or Vera, and that’s how apple’s development program works.
Amazon
Amazon does this through “skills.”
Cloud or Local
In general, local systems like homeseer, vera, or Hubitat Will run these drivers locally if possible. Cloud-based systems like Amazon, smartthings, or Homey Will run them in the cloud.
On the current smartthings platform, all custom code, whether it is a DTH or a smartapp, runs in the cloud. Only a few stock Features, basically smart lighting and some bits of smart home monitor, can run locally. Even the app cannot communicate with the hub locally. This is true for all hub models.
https://support.smartthings.com/hc/en-us/articles/209979766-Local-processing
Responsibilities of the Device Manufacturer
If so, must a device manufacturer create this external device handler for each separate platform (without being able to reuse code because each platform has its own language and development environment)?
In general, yes, because the way in which custom drivers are utilized varies by platform even if they are using standardized message command sets.
There are a few exceptions.
-
If you want a system with very similar code to smartthings that does run locally, look at Hubitat
-
if you have a device certified to one of the third-party home automation protocols, such as Z wave or zigbee 3.0, then you can assume that any hub/controller certified to that same protocol will have a “generic“ driver that will be able to access the basic functions of your device. So if you manufacture a simple open/close sensor or a standard dimmer using one of these protocols, you as the manufacturer do not need to provide a driver for your customers: Their hub should already work with it.
That does not mean that a device intended to work with HomeKit will suddenly work with Z wave. Those are two separate protocols. It just means that a device intended to work with a certified Z wave hub should work with any certified Z wave hub at the basic level.
Note That the plugin structure is typical of home automation platforms, but is not typical of home security platforms. Home security systems quite often want to lock everything down to just a few specific device models using only drivers that the company itself provides. That’s intended to manage both reliability and security. ( it may also be part of the business model.) so all of the above in this post applies only to home automation systems, not systems sold primarily for home security.