I am relatively new to the SmartThings environment. I have a general understanding that a Device communicates with the SmartThings cloud (and SmartThings Hub) by virtue of its Device Handler. I have also noticed that the IDE can be employed to change Device Handlers (eg, to use a custom device handler so something like the ZWaveTweaker device handler).
I noticed that changing the Device Handler for a particular device not only changes the functionality (to some limited extent), but also the user interface (eg, the screen that appears in the Classic App when you select the particular device associated with that device handler). The simplest example is ZWaveTweaker, which provides a ācustomā interface for changing a deviceās parameters.
I am wondering how (and the extent to which) the device handler can control the user interface that shows up in the Classic App. Can someone point me to the place in the Smartthings documentation that explains the APIs or other mechanisms for controlling not only device functionality/communication, but also the UI in the classic app?
I see. Does the code in the device handler get executed in the SmartThings cloud (or on a local Hub), or is some or all of that device handler code sent to and executed by the App itself (eg, on an iPhone client)?
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
5
Both. Like any client-server situation.
Changes a bit in the New SmartThings App, but thereās still split and sharing of duties.
Does that mean the App (Classic or New) can interpret Groovy code, or are there just API calls (whether or not published) governing the communication between the App and the SmartThings cloud or hub?
I also just noticed that the new App appears to be adding back much of the functionality found in the Classic app (and more). It seemed a bit on the slow side, but I only tried it briefly. I had been ignoring it due to a lack of functionality, but maybe itās worth giving another look at this point.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
7
No.
The Groovy Code in legacy Device Type Handlers contains a āmetadataā section which the platform translates into whatever data structures are used by the Classic App to render UI elements.
The New App offers an HTML5-type of descriptive language for custom device UI plug-ins. But thatās all detailed in the online developer documentation.
The built-in groovy device type handlers in the SmartThingsPublic repository are required for all hub connected devices whether youāre using the new or classic mobile app so I wouldnāt consider them legacy handlers, but the ātilesā and āpreferencesā sections of the metadata are only used by the classic app.
The āvidā attribute in the metadata definition determines which UI it should display in the new mobile app and the ātilesā section of the metadata allows you to define all the tiles that should be displayed in the classic mobile app.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
9
I think there are plenty of device types which do not have source code in the public repo.
And I presume there is a growing number of device types (even for Hub connected) which are only written using the new, non-Groovy, legacy deprecated API.
Can you name one z-wave or zigbee handler that isnāt in the public repository?
I agree that theyāll probably get rid of the groovy code base at some point, but Iām pretty sure that all z-wave and zigbee devices require a groovy handler in order to work in either mobile app.
Iām basing that off of the publication process for hub connected devices in the new developer workspace and the way theyāre using that vid attribute to tie the device code to the UI, but I could be wrongā¦
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
11
