Displaying Temperature instead of Motion in SmartApp


#1

I am using a multipurpose sensor simply to check the temperature. I am wondering how I can change the display in the smart app to show the temperature instead of motion. I have searched the web and have not found any direct methods. Note, I am trying to utilize the native app as I know ActionTiles can do this already.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #2

Just to be clear, you mean the “mobile App” (i.e., the Android App or the iOS App).

  • A “SmartApp” is a piece of Groovy code that runs an automation in the SmartThings Cloud.

The Answer:

You can make a copy of the Device Type Handler and change the “main tile” to the desired “sub-tile” name. I’m referring to SmartThings App Tiles, not ActionTiles :wink:

Finding the code for the respective DTH, copying it into your IDE web page, making the small change, publishing “for me”, and then editing the Device instance(s) to apply your new custom DTH … well… those steps are not hard, but someone with a few more minutes than me can either list them or point you to a good description / how-to.


(Robin) #3

Using this handler as a template:

Change line 114:

main([“status”, “acceleration”, “temperature”])

To:

main([“temperature”, “acceleration”, “status”])


#4

you are correct. I use the native app on an Android device and on an iOS device.


#5

Just implemented what was provided, and it works like a champ. I appreciate the quick response.
Thanks


#6

Robin - I’ve implemented your solution (e.g. creating and using a new DH, and changing line 114 as you described), yet the tile in the SmartThings app still shows the status versus the temperature. In the year since this topic was addressed, has anything changed that would be cause for an alternative solution?


(Ron Talley) #7

I’ve been meaning to do some maintenance on my setup and this was on the list. I did the method as listed above it still works for me.


#8

Ron - Thank you. I’m stumped.

I’ll provide more information with the goal of finding the issue.

For completeness, my SmartThings Multipurpose Sensor is showing as “model: multiv4.” Perhaps I am using a different model.

I made minimal changes in using a self-published DH based on the default DH. Please see below.

//	2018-06-03 Re-named to SmartSense Multi Sensor - Temperature and set runLocally to false

//	Original Code
//	definition(name: "SmartSense Multi Sensor", namespace: "smartthings", author: "SmartThings", runLocally: true, minHubCoreVersion: '000.017.0012', executeCommandsLocally: false, mnmn: "SmartThings", vid: "generic-contact-2") {

// 	New Code
	definition(name: "SmartSense Multi Sensor - Temperature", namespace: "smartthings", author: "SmartThings", runLocally: false, minHubCoreVersion: '000.017.0012', executeCommandsLocally: false, mnmn: "SmartThings", vid: "generic-contact-2") {

And

//		2018-06-03 Swapped position of temperature and status in main and details

//		Original Code
//		main(["status", "acceleration", "temperature"])
//		details(["status", "acceleration", "temperature", "battery", "refresh"])

//		New Code
		main(["temperature", "acceleration", "status"])
		details(["temperature", "acceleration", "status", "battery", "refresh"])

Despite using the revised DH, the sensor still shows the Open/Closed status versus the current Temperature in the Dashboard and under Devices in the SmartThings app.


(Robin) #9

Change to:

main(["temperature"])


#10

Robin - Yes, I have also tried that solution without success. I have also tried limiting both main and details to temperature.

//		2018-06-07 Removed acceleration and status from main

//		Original Code
//		main(["status", "acceleration", "temperature"])
//		details(["status", "acceleration", "temperature", "battery", "refresh"])

//		New Code
		main(["temperature"])
		details(["temperature", "acceleration", "status", "battery", "refresh"])

I save and self-publish the new DH and ensured the sensor is using the “SmartSense Multi Sensor - Temperature” DH.


(Ron Talley) #11

Are you sure you are changing the device type in the device settings in the IDE?


#12

Yes, based on what I see in the IDE; screen shot embedded here.

Capture


(Robin) #13

Are you clicking publish > for me, after updating the code?


#14

Robin - Yes, I am using Publish - For Me.

I’ve noticed one difference between my code and the prior recommendations: “runLocally: true” versus “runLocally: false” (or omitting this variable).

I’m unable to set runLocally: true; it prompts the error message: “org.springframework.security.access.AccessDeniedException: Run Locally Permission not allowed for DeviceType” … .

I am still stumped otherwise. The sensor is reporting data properly, and I have tried removing it and re-adding it without the desired outcome.


(Robin) #15

Don’t suppose you accidentally made a duplicate handler with the same name? And have the device set to the unchanged duplicate?


#16

I was optimistic that this could be the issue. I’m disappointed to report otherwise. I restored the device to its original DH; deleted my custom DH; then created, published, and assigned the custom DH (with new name) to the device.

I used a document compare function to compare the default DH with my custom DH and confirmed the only differences are exactly as documented previously.


#17

SOLVED. Based on the thread below, I’ve learned that custom DH do not work in the version of the SmartThings app that I am using. Ouch.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #18

Oh… You could have saved everyone a lot of time by starting with this fact. :wink:.

Seriously … There are very few reasons to use the new SmartThings App… yet.

If I could change the universe, I would make it disappear - until it was actually ready and had feature parity with SmartThings Classic.