I agree that it is a UX challenge more than anything else, so I’ve spun off a new Topic. We can also discuss via Private Message and/or a phone call sometime, though, @Tyler, to go in more detail…, whatever works!
The gist is that though “theoretically” a SmartDevice Type is an abstraction of the Thing sufficiently comprehensive that any SmartApp can deal with managing custom “features” via interaction between other Things. But that doesn’t acknowledge that SmartDevice Types are actually richly featured in themselves (they can have multiple-controls, can spin-off child devices, and we’ve been told will have richer interfaces allowing HTML5, etc., etc.). Thus, sure, a simple light-switch isn’t a problem. But a Button Controller could be represented and handled may different ways (e.g., perhaps showing the buttons as sub-tiles, or not – perhaps spinning off the buttons as individual child-Things); and something like a Nest Thermostat … wow… there are definitely may ways to handle both the UI and the API.
The closest analogy I can think of is the PC “Mouse Driver” for Windows. The generic driver provided by Windows is fine … but Logitech and other vendors provide their own drivers so they can feature different functionality. (And there are examples where one vendor’s device can be supported by your choice of driver too.)
This discussion will be interesting; but it may take a few concrete examples to demonstrate the value of having a choice of multiple certified SmartDevice Type Handlers for the same brand/model of various devices.
Funny, i was actually thinking about the same thing but in a different light… My thought was “Why do we have so many device types for z-wave and zigbee devices?” Why can’t there be just one device handler that reads the capabilities of the device and puts together a UI/UX based on the capabilities of the device separated by normal use and advanced functions/options. With the ability to rearrange the UI/UX if it doesn’t fit a particular users needs.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
3
Yes – this “problem” (Topic?) can be thought of from a lot of different angles.
I genuinely think that SmartThings’s architecture with respect to SmartDevice Types was / is dual-personality:
On the one hand, the purpose of a SmartDevice Type handler is essentially a hardware abstraction layer to encapsulate the physical device into to the official “Capability” taxonomy, so that it is plug-play-replace with any SmartApps utilizing that Capability.
On the other hand, the Platform allows you to define somewhat rich devices with more than just the essential Attributes, Commands, and User Interface elements (Tiles). You can have any ad hoc Attributes, Commands, and … well, various Tiles and Child-Devices, Service Managers, etc., etc…
Further to the previous bullet: Richer UI elements are in demand from the Community, thus hints that HTML5 of various sort will be permitted.
So while #1 could imply there is a single “efficient and effective” Device Type Handler that exposes all the functionality of any Smart Device (regardless of protocol) … and, in fact, this might even be a “super-driver” that is almost self-generated…
For better or worse, #2 and #3 imply that various Developers can absolutely choose unique ways to implement the interface to a particular physical device, all the way from the API layer (Attributes and Commands) through to the Presentation (UI) layer … which Tiles, Controls, Colors, Sub-Tiles, Children, etc.
And because the can do this for very valid creative and functional reasons, the Platform should allow Developers to offer alternative SmartDevice Type Handlers, and, in turn, Customers to choose what interface is appropriate for themselves.
Don’t downplay this. I think it’s one of the most likely scenarios.
Let’s say I write up a device type for a new widget and it gets certified. Then you come along and make an improvement to it that the community really wants. Does my version remain the canonical one? Do they switch to yours? Merge?
It becomes even trickier if the original author disagrees with the change.
I feel this is an issue where each different perspective will have a completely different response. I think that from a “Support” point of view it has to be like Highlander “There can be only one”. I’m sure its difficult enough supporting 1 device type per device and even more so when you add in multiple per device even when the changes between them are minor.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
7
I don’t think it is that much different than supporting multiple SmartApps with “similar functionality”; which is inevitable if the SmartApp “Market” is similar at all to Apple App Store and Android Play Store.
There’s no way that SmartThings Customer Support will be able to directly provide service for Third-Party SmartApps.
So do the same for SmartDevice Type Handlers:
at the time of device “add” by Customer in the UI, recommend or default install the certified official “Supported by SmartThings” Handler.
at anytime, the Customer can go into Thing preferences and select an alternate handler acknowledging the loss of tech support (like Windows allowed “uncertified” driver installation with user permission). SmartApp’s could have meta tags to prompt Device Handler overrides where necessary.
ensure that the Device Handler version and source’s name is easily determined by clicking on the setting gear of the Thing Tile.
NB: I’m not saying that alternate Device Handlers won’t be reviewed at submission time, just that, indeed, only one can be the default certified official supported one; but there are valid reasons to permit others to be listed for end-Customer selection and installation.
From a network engineering perspective, I don’t have any problem with multiple device handlers being available for the same device as long as it’s very clear what each is for.
Just as an example, we commonly had three:
all supported device features
forced energy savings, only low energy features available
high security version, only encrypted options available, might eliminate some features that created potential vulnerabilities
As a SmartThings example, it would make perfect sense to me to have three device handlers for the new Aeotec lightbulb, one using only secure mode, one using only nonsecure mode, and one supporting everything. Because honestly, how many people need encryption for a light bulb? And I’d bet using encryption increases power draw. And mixing the two creates potential problems in some networks if the app writers don’t understand what they’re doing.
The idea is that sometimes a stripped version of a device handler helps you enforce network management conventions on future app writers. Of at least makes them conciously identify some choices.
That said, I hate the way ST implements device handlers since there’s a lot of stuff in there I’d push back up to the app layer. So I don’t have a whole lot to contribute to this conversation.
But I did want to mention that it’s not unusual to have devices that can be deployed in different modes (most typically energy saving vs not and highly secure vs not) and sometimes that is enforced, or at least identified, by having limited option device handlers.
FWIW.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
9
I definitely agree. Clarifying the layers of a device handler would likely make it obvious that customization is mostly in two distinct (and, therefore, ought to be separated) areas:
low level protocol; could be customized via easily supported parameters sub-module selection (eg, encrypted vs. not) only.
presentation layers (extra Attributes and Commands, and UI preferences)… Essentially “Apps with APIs and/or UIs”.
Haven;t been a programmer for years. But, I have been lurking enjoying this thread and the possibilities it offers tor us.
Another thing that ST really needs is a way to auto update the Device Handler, or SmartApp without the use of external sites to enable. They essentially need to build a full app ecosystem similar to the various Android/ IOS app stores. As you go to install you can select the appropriate device handler from the list for the particular application.
Remember to make HA more accessible it has to be easy to setup and understand for the common non techie user. Simple is better for most.
I would like to see a process that when a new device is added to the network, that it polls the capabilities of the device and builds a basic handler. Is that even possible?
Then as new devices became available, the issue of “Is this supported” becomes non-important as the platform automatically generates the handler, and all you have to do is find a ST App that supports the type of device that you have.
Of course that would mean that certain other tasks happen, a new sensor with a new type of detection, say infrared, ST may not have that ability in the handlers, so it would have to somehow modify internal code on the fly to add that capability into the ST ecosystem. And then add it to the documents so that we know that capability is available.
I know I am going way of course here, but this thread just got me thinking on how we can make the ST system easier and more robust with less management on ST
