Continuing the discussion from Made a Water Leak Sensor (see quoted below):
I’m curious to know more about the exact changes you found you needed to make to the stock/standard Device Type to make this new Device Type.
Frankly, I can guess, and I could also do a diff (friendly suggestion: If anyone creates a new Device Type that is highly based on an existing one, and you’re using GitHub; it is tremendously helpful to first commit a copy of the original base Device Type, and then make or paste in the New one … This makes the changes immediately viewable in the commit history diff view, of course!! ).
But I have a more nefarious motivation:
I believe that SmartThings Device Types
should support inheritance of some sort. They already implement polymorphism and abstraction, so why not go full object-oriented here. With some concept of inheritance, it would be possible to tweak a Device Type without cloning it; you would just override the affected attributes or methods.
In this case, for example, I believe the main logic you are changing is open/closed
to dry/wet
; along with cosmetic changes in the tiles{}
. This idea of “adapt a device” has come up before; for example, the Virtual Open/Close for garage doors, changes the SmartSense Multi
to report certain accelerometer angles as open\close
instead of using the state of the magnetic contact.
There are many ways to handle this model; the current way, cloning and modifying the Device Type is not bad, though it requires manually changing the Device Type assignment using the IDE (not consumer friendly).
The simplest solution I can think of, actually, is to take a lesson from the the “@media{}
” structure available in CSS: i.e., one CSS file can accommodate screen sizes, with only the necessary differences put in @media
sections. For SmartThings, tag could be “@useType{}
”, a preference configuration parameter you set at installation time (e.g., “@useType capability.switch { code for on/off handling here }; @useType capability.waterSensor { code for wet/dry here }
”.
[But I’d like to see if we could figure out an even better way to handle interface variances with inheritence…, actually.]