Questions about temperature data in ST

Based on my only marginally informed review of this code from the SmartSense Motion/Temperature Sensor Device Type . . . .

def getTemperature(value) {
	def celsius = Integer.parseInt(value, 16).shortValue() / 100
	if(getTemperatureScale() == "C"){
		return celsius
	} else {
		return celsiusToFahrenheit(celsius) as Integer

. . . . I’ve concluded that the raw form of temperature that ST gets from the sensor is °C x 100. then, the Device Type Handler converts to °C by dividing by 100 and then converts to °F if necessary and rounds/truncates to an integer. Please let me know if I have any of this wrong and if there is a reference somewhere that spells this out.

So, it seems like if I want a SmartApp to use temperature to a tenth degree resolution, I have to also create a new Device Type Handler. Right?

This doesn’t seem difficult but then you have a SmartApp dependent on the use of a particular Device Type Handler. Is there a way, instead, for the SmartApp to ‘go around’ the Device Type Handler and pick up the raw value? Alternately, is there a mechanism available to a SmartApp to verify that a device is using a preferred Device Handler Type?

Don’t take this as argumentative, (and this comment may not be valid depending on the response to the above) but how was it decided that no application is going to care about tenths of a degree? If we now decide that this is wrong, what is the path to correct this? Can the mainstream Device Type Handler be modified with a new attribute, ‘temperatureToTheNearestTenth’’, to be available as well? This way, nothing current breaks but future SmartApps have access to tenths of a degree.

I also saw a post where @pstuart was complaining that the Device Type is truncating to an integer rather than rounding. If this is true, this probably should be fixed, I would think, and would be an easy revision to the code (for someone who knew what they were doing).

Someone tell me if bumping is against the explicit or implicit rules of the forum . . . please. Assuming it’s OK, TTT. Also, @pstuart, I kind of expected you be able to answer some of these questions and have some opinions on this topic. If my good will account with you can stand another withdrawal into the red . . . could you please share your knowledge and wisdom on this?

I struggled with this too, can’t remember exactly how I fixed it will have to dig through my github to find the fix for my devices. But all my temp sensors report and display tenths of a degree.

I think the trick was to change the display type to a string / text and keep a state var for the decimal value.

I think I even had a rant a few months back on the rounding (or truncating) the default devicetypes were doing… So I feel your pain… Been there, done that, fixed it myself, shared the code… But really can’t go much further…

Just for a few searchable references for this issue.

@pstuart. Found this in your repo:

Is this the code you are talking about that addressed this? I just did a 30 second scan and I see where you have cast the temperature as Double (if I’m interpreting it correctly). I will dig in a little more when I get a chance. Thanks!

yeah, that might be it, I think I also addressed it in my ubi screen scrape code. Honestly, don’t have a ton of time to dig in right now… Maybe in a few weeks. Crazy season here…

No worries, @pstuart . I can take it from here. I am contemplating a specific application where I might want to know temperature in tenths and, perhaps, the idea that ST should, in general, support temperature in tenths rather than as integers. I need to get my head around how sensor reporting and ST events interact before I can organize my thoughts. I have another thread on this topic (that I need to bump . . . no traction). Thanks again

Keep in mind, if you convert the display value to a string, you might break smartapps that use essentially integer values for temp.

Stupid system… Honestly, temp should always been a decimal and then let the smartapps format it for usage, but when 74.234 doesn’t equal 74 a smartapp wont work… Too simple and too limiting for me.

But truncated 74.9 to 74 is plain stupid.

Understood. I was thinking in terms of a new attribute of the temperature measurement capability: ‘temperatureDecimal’ or something like that. Leave the current integer value there so existing apps don’t break but include this other, more precise, attribute for new apps that want/need it.

+1. This is easily fixable without breaking stuff, I would think. Maybe this could be proposed as a separate thing. I may include this in my crusade if/when I launch it.

We are looking into the truncation issue. We should be rounding, not truncating.



Why is when one calls

def v = device.currentValue("temperature")

on the new SmartSense Temp/Humidity Sensor, it throws a NumberFormatException?

Same problem with humidity for SmartSense Sensor and power for TCP bulb.

@625alex can you provide some more context to your question? Is this happening all the time, only in certain conditions, etc.?

It’s happening all the time. You can try it with any basic app.

Also, if you call device.supportedAttributes on SmartWeather Station Tile, you get this exception:

org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object ‘temperature’ with class ‘physicalgraph.device.cache.AttributeDTO’ to class ‘physicalgraph.device.Attribute’

@Jim, in case you missed that, I’m just giving you a poke because I really want to get to the bottom of this.


Hey @625alex - I’m assuming you are still experiencing these issues in getting a NumberFormatException in all your reported cases?

I’m going to get someone from engineering to look into this. Apologies for the delay.

Yes, I encouraged users of ActiON Dashboard to keep reporting it to support.

Current problem is humidity capability of SmartSense Temp/Humidity Sensor. It used to work a short while ago and now it’s broken again.

Thanks for looking into this!

Yep, we’re able to reproduce this issue as well now. We’re looking into it.

Also, please check battery readings for ST temp/humisity sensor.

Also, when you call smartWeatherTile.supportedAttributes, same exception is thrown.

Hello all. New to Smartthings and device handlers. Found some code to post temperature readings to Grovestream. While I was able to get temperature from all of my devices that support this capability, I am finding that the readings I am getting from my Smartsense Multi Sensor are +/- 1 degree which, when plotted against the Aeon Gen 5 multisensor, look horrible… almost unusable. I expect this thread may be heading in this direction. Was there ever a device handler that addressed this short coming? Is there an alternative solution?

I don’t know if Grovestreams can do this, but with my graphing package (Grafana) I apply a moving average function to temperature data to smooth the line out and reduce those spikes.


Any chance you have been able to get a zigbee device to produce event reports for temperature with a different delta than 1deg? I have many ST Multi Sensors and for most of them I don’t care about temperature and would like to simply suppress the event log entries. Since I cant seem to make them stop looking for a larger delta of say 5deg would quiet them down quite a bit!!!