Smartthings Multipurpose Sensor - unreliable?

Devices & Integrations
1

I’m using a Smartthings Multipurpose Sensor on my garage door. I’ve seen old references in this forum to the “new” vs. “old” sensors - mine was purchased a week ago and has the coin battery in it.

I have configured it for use on a garage door, and oriented it correctly on the door (with the raised bar on the cover oriented vertically, on the right side of the sensor).

It works totally reliably when the door is opened, giving me both a vibration alert and showing “open”.

Roughly 25% of the time when I close the garage door, it subsequently shows status as still “open”. It does, however, give the vibration alert when closing. Tapping the sensor seems to make it unstick and report “closed”.

It is mounted on the top panel (of 5 panels I believe), to give the earliest possible indication that it is open. To my untrained eye that top panel looks just as vertical as the rest of the panels, so I don’t think the cause is that top panel being not quite vertical.

It is reporting temperature OK. So this means it’s not out of range, correct? I would expect if it was out of range it would report null for temperature (which maybe the GUI would report as -273 Celcius?:grin:). In case it might be a range issue - the sensor is located one floor down, and about 15’ horizontally from the hub.

Battery is at 100%.

Any suggestions on what I might be doing wrong? I’d like to improve reliability of it reporting “open” only when it is actually open.

Thanks … Mike

2

What does the Three-Axis value say in the Thing detail tiles?

3

How do I get that detail? I can’t see it from the ST app (My Home > Things > The sensor > Right Now) - I can just see Active/Inactive, temperature, battery, and a refresh logo.

1 Like
4

By gosh, you’re right! They removed it from the device detail view:

This used to contain an “x,y,z” value indicating the orientation!

Pasted image664×805 44.2 KB

Login to your graph*ide page, however, and visit “My Devices” and find your Device, then look at the “Current States” values:

5

I don’t think they report temp as often.

6

When closed: 31,-31,-1033
When open: 1032,-31,-86

I have opened/closed it three times and each time the sensor correctly identifies it as garage-closed. Murphy’s Law dictates that I can keep opening and closing and fail to reproduce the problem until after I am away from my PC.

1 Like
7

IF I understand the source code for the Device Type Handler correctly, then I believe it only responds to the “Z-Axis” to indicate open or closed. < +/-100 = open, > +/- 900 = closed.

1 Like
8

They removed it in an update a few months ago; IIRC, to make the display less noisy. :cry:

9

I’ll check the Z-axis value next time it fails (with my luck it will be when I am leaving for work and I won’t be able to check until I get home, at which point I will open & close the garage door again and it will probably not fail that time).

I wonder what unit it is measuring? Clearly not whole degrees, since it needs to be at least 900 to register as closed. And there’s this whole range (from 100-900 where the state remains unchanged.

10

It measures G force (acceleration), where 1024 apparently ≈ 1g along the particular x, y, or z Axis.

Using trigonometry, you can combine the three vectors to determine the orientation and even the movement of the device in any 3D vector.

11

Ah yes, measuring G makes more sense. I wondered if the max was a nice round hex number. 1033 is bigger than 1024 - maybe I’m in a gravity well :grin:.

I hasn’t failed since. Maybe I scared it into submission.

You’ve given me some ammo for checking this out next time it fails,thanks.

1 Like
12

OK, it failed this morning (probably did not fully register the “close” when it closed.
threeAxis: 1067,-40,-80

So that value 80 (when it is closed but registering as open) is a long way from the threshold at which it should register closed (minimum 900).

Maybe it’s defective (but not all the time).

13

It definitely should not be failing like that. Get in touch with support@smartthings.com and they can replace it for you (feel free to link to this post).

1 Like
14

Will do, thanks.

1 Like
15

I just received a new one of these today and had similar results as a garage door tilt sensor, very unreliable and it’s going back.

16

The Monoprice or… ummm… I forget the other white label brand… Z-Wave tilt sensor has been working fine for me as an alternative.

It contains a cylinder with a physical ball bearing inside. Never fails, and I have it tilted so that if the door is open even a couple inches it will detect.

17

Thanks. I’m actually using the temperature sensor feature of this sensor (as well as tilt), so I’ll give the replacement some time to see if it behaves.

If the replacement misbehaves also, I’ll look at the Monoprice one.

1 Like
18

Update - the replacement behaves the same way - intermittently telling me it’s open. What’s odd is that I have a SHM rule that sends me a push notification when the door opens and when it closes. That notification does not trigger when the sensor decides it has gone from closed (correct value) to open (incorrect value).

So I think I’ll be sending the replacement back, and maybe look at Monoprice.

BTW, maybe this is a range issue. It’s only my second Zigbee device. But TBH if it was a range issue I would expect it to report “unknown” rather than “open”.

19

Did you have any further luck with this? I just installed a couple multipurpose sensors on my single panel/swing-tilt garage doors and they are intermittently reporting open as well in the open position. The doors, when open, are at a very slight downward angle so that might be throwing things off. I just wish they implemented offset variance in the device handler for this…ugh. I thought it might have been distance from the hub at first but I noticed it detects everything else fine like temps, and the accelerometer detects when the door is moving.

20

I have a similar issue as the OP; but the multipurpose sensor doesn’t report “open” about 50% of the time. (The “close” event is not reported during this bad sequence also, but I assume it’s getting filtered out because since it was never “opened”, why report the closure when it is already closed…)

Same configuration as OP:

  • “new” sensor (coin battery version)
  • one week old (100% battery life)
  • configured for garage door (mounted vertically, bar on right)
  • mounted on top garage door panel
    Temperature reporting ok, accelerometer is active during door movement and goes inactive when not.

I did:

And then clicked on the threeAxis link to get the “threeAxis states” log.
I correlated the threeAxis values with the missing “open” and “close” states.

On the missing open events, the lowest abs(z) values range from 108-115.
On the missing “close” events, the highest abs(z) values range from 1053-1070

I also looked at the code and concur with:

So z-axis values are, at time, above the 100 threshold to be considered an “open” event. Hence no “open” event.
The z-axis values are appropriate for the “close” event and should cause a posting of a “close” event. But as stated earlier, I think it might be that since the door was originally "close"d, and it never got the missing “open” event, it would toss the “close” event to prevent redundant “close” events.

Any idea on why the accelerometer is reading too high (above 100) on “opens”? And ideas on fixing it?