SmartThings Temp/Humidity Sensor


(chuck) #1

Is anyone having trouble with the ST temp/humidity sensor? I just received one, and I am getting wildly innacurate humidity readings. Polling every ten minutes, this morning I had 9%, 81%, 65%, 42%, 88% and 28% in an hour. Can’t decide if it’s something I have done incorrectly or if the unit is simply defective.


iOS update for ST app (1.6.7)
(Convinced ST will never be unbroken…) #2

Sounds borked to me. What could you possibly do to get so many obviously erroneous results?


(Tim Slagle) #3

I wonder if there is a calibration period? I know my netatmo had WILDLY innacurate reading for the first week until it calibrated itself.

@ben, can you comment on that?


(Brian Smith) #4

I’m having the exact same issues. I figured I would let it go another week to see if it leveled out. But, it is right beside a hygrometer and there is a dehumidifier nearby. Both hold steady on their %'s, but the ST sensor is ALL OVER the charts.


(Jeff Christoffersen) #5

I am having the exact same issue but I believe the problem is with the DeviceType code not the device itself.

Let me elaborate, I can see in the logs that I will often get a java exception error that looks like this:

java.lang.NumberFormatException: For input string: "7e.1a" @ line 124

Looking at the example code, line 124 is where the humidity is getting determined. This error occurs any time there is a letter in the last two data cells of the “catchall” string that the sensor sends for the humidity. I believe what should be happening is that the humidity should be handled exactly the same way the temperature is.

To accomplish this, I created a new device type in the developers console and copied the example code from the SmartThings Temp/Humidity Sensor and made the following two changes:

Line 103 was changed from

String pctStr = cluster.data[-2, -1].collect { Integer.toHexString(it) }.join('.')

to

String pctStr = cluster.data[-2..-1].reverse().collect { cluster.hex1(it) }.join()

And line 124 was changed from

return Math.round(Double.parseDouble(value))

to

return Math.round(Integer.parseInt(value, 16).shortValue() / 100)

My only verification point is the that one of my 2 sensors is located in close proximity to my Netatmo and my Nest thermostat. Reassigning the device to my new device type, I get 52% when the Netatmo reports 52% and the Nest reports 54%. I also no longer get an error.

Since I have no idea what the complete requirements for this device type are AND I haven’t done a lot of testing, use the above with caution. The first time I ever looked at Groovy code was trying to figure out what the heck was going on with this thing. My assumptions may be totally inaccurate, although that doesn’t appear to be the case. Regardless, from my standpoint, this looks like a code problem, not a hardware problem. I’ve reported to SmartThings so hopefully they can update the standard driver soon.

If you do this, you will also want to change the name of the device in line 17 so you can find it when you change the DeviceType of your sensor to the modified one.

Jeff


(Ron S) #6

The one I have the humidity is off by 2-3% if compare with a manual AcuRite system or the Frigidaire dehumidifier and the temp. off by 3 to 5 degrees and I had to use the offset. The humidity on Aeon Multi is much worse.


(Brian Smith) #7

This would be awesome if it is simple like this and not a hardware issue. My sensor is constantly telling me my basement is too humid even though it is actually only 40-45% based on the other devices down there. Starting to get a dip in the WAF, so I need to disable the alert.


(Ron S) #8

Fortunately I did not set up alerts for this. The Frigidaire dehumidier does a pretty good job of shutting itself off when the humidity drops below 50 which I have set as default on that and it’s readings are pretty consistent with AcuRite but the only gotcha is these dehumidifiers displays humidity only in multiples of 5. Odd.


(Ron S) #9

And what’s up with the null% humidity? :wink:


(Jeff Christoffersen) #10

Just following up on this issue. It appears it has been corrected in the default device type now so the change above is not necessary.