Continuing the discussion from Lock Code Manager:
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.