SmartThings MultiSensor Garage Open Axis issue

Devices & Integrations
1

Hey all,

I have a couple previous generation multisensors that I’m having trouble calibrating for my single panel (swinging not sectional) garage doors:

I had contacted ST support at some point previously where they ended up hardcoding changes on their end to tweak the axis settings. I’ve found these sensors to be very sensitive to the horizontal plane that triggers the “open” position, and I’m a bit puzzled as to why the range seems to be so limited. My garage panel doors swing outward and acceleration is definitely detected. But when they are horizontal, even though it looks pretty “flat” it’s not horizontal enough to trigger that open position. If I remove the devices and lay them flat in my hand, it works fine. It’s pretty frustrating as I’ve moved the sensor vertically up and down the garage door panel and nothing works - I think it’s the overall angle that it’s at.

I see the axis numbers being reported in the logs as well but they don’t seem to be different every time. Perhaps this is just the nature of the swinging doors where they’re never on a consistent position and could be off by inches or less, and every 1/4 of an inch makes a difference as far as the sensor itself is concerned.

That all said, is there an ‘easy’ way to understand and tweak the axis orientation? I was looking at the device handler but am not a developer, so it’s a bit difficult identifying where and what I need to tweak as far as expanding the range. I don’t even know which axis or axes I’d need to modify either.

I reached out to ST Support but it’s been days without a response. So I’m getting a bit antsy. I recently connected a relay to a smart plug and am using that to control opening/closing the garage door but I still need the sensor to work reliably well. Just trying to figure out how to resolve this.

Also, not sure if this would still be an issue with the newer generation multi-sensor or even other brand sensors.

2

Easy is certainly relative and it does take knowledge of how to read code and interpret Live Logging, etc.

But it’s easy in the sense that only 1 to 3 lines of code in the DH need to be changed.

3

I see where the axes are logged (though don’t quite understand the numbers relative to the position at first glance).

Also, in the device handler, I found the following:

  // kinda hacky because it depends on how it is installed
  status "x,y,z: 0,0,0": "x: 0, y: 0, z: 0, rssi: 100, lqi: 255"
  status "x,y,z: 1000,0,0": "x: 1000, y: 0, z: 0, rssi: 100, lqi: 255"
  status "x,y,z: 0,1000,0": "x: 0, y: 1000, z: 0, rssi: 100, lqi: 255"
  status "x,y,z: 0,0,1000": "x: 0, y: 0, z: 1000, rssi: 100, lqi: 255"
  • Are those what I want to be messing around with?
4

Also, once I add/publish the device handler, do I need to remove and re-add the devices if they were already present?

5

It helps if you actually link to GitHub source for the DH, select the lines first, and the URL will automatically contain a link to those lines in context. Yah - not coding, but still not an obvious technique for sharing code.

Without the context, I can’t be sure those are the right lines, though those are what I would start around.

No. You can give your modified DH a unique name and just use Edit in Devices list to manually change the Device “Type”.

6

The “kinda hacky” lines are in the simulator section. Those are for testing the code - not what you’re looking for.

Below is what you need to play with (around line 354). Assuming you’ve mounted the sensor so that the door changes the z axis, you should just be able to adjust the 900 and/or 100 values. If you need the x or y axis instead (or a combination of two/three axes) then you’ll have a little more work to do. You can see the current values of the x/y/z axes by going to the device screen in the IDE.

List<Map> garageEvent(zValue) {
	List<Map> results = []
	def absValue = zValue.abs()
	def contactValue = null
	def garageValue = null
	if (absValue > 900) {
		contactValue = 'closed'
		garageValue = 'garage-closed'
	} else if (absValue < 100) {
		contactValue = 'open'
		garageValue = 'garage-open'
	}
	if (contactValue != null) {
		def descriptionText = contactValue == 'open' ? '{{ device.displayName }} was opened' : '{{ device.displayName }} was closed'
		results << [name: 'contact', value: contactValue, descriptionText: descriptionText, displayed: false, translatable: true]
		results << [name: 'status', value: garageValue, descriptionText: descriptionText, translatable: true]
	}
	results
}
7

Thanks. I used the handler that was a preset from “Examples” but it looks like the one philh30 is referring to (from GitHub) is more recent.

8

So I checked the axes when the door is open (but not reporting open) and I get:

1010,33,-128

In its closed state it’s:
32,-5,-1046

I’m about to publish the code from GitHub and refresh the devices to use it. Will report back shortly

9

I’m surprised (but haven’t tested my own) to find that both X and Z values are changing, but that may not be unusual.

These are the lines that check for the magnitude of the value and uses that to determine if opened/closed.

Change the values to be more lenient:

  • instead of 900, try 500
  • instead of 10, try 50, or even 100

Always best to just check one at a time, and only fix the part that’s broken (i.e., don’t change the “Closed” values, if “Closed” state is accurate).

10

Cool, I think I may have gotten it working by extending the “open” range from “(absValue < 100)” to “(absValue < 200)” - I think the negative symbol was throwing me off but I think it’s the general range that matters anyway. After increasing it to 200 (since this door was always over 100), it looks like now the door reports open as expected. I don’t think there should be any concerns upping that number to 200 at least…

1 Like
11

That is the value that is probably the problem, because your sensor is reporting “32”.

In its closed state it’s:
32,-5,-1046

12

You’re going from seeing acceleration due to gravity on the X axis, to seeing it on the Z axis; the effect drops out on X (value approaches a similar “0” range to that seen on Y) and spikes on Z.

2 Likes
13

Interesting, so after applying the changes to my other panel door, it reports the door as “Garage Door Open” but I think it thinks it’s in the “actively” opened state (meaning the garage door is in the process of opening but hasn’t finished) and remains in that state indefinitely without actually fully reporting “open” at least in the main status (if you look under “Recently” you’ll see this behavior with the two different icons next to “Garage 2 was opened”:

image
image.png360×721 50 KB

The “Garage 2 was opened” even at 1:16pm correctly was reported. However the ones following that with the arrows in opposing directions did not reflect “Open” in the “Right Now” main status window. Sounds like this may have to do with the acceleration you’re referring to. Weird that the other Garage door (which I had more issues with even getting to report open) actually reports “Open” as expected.

14

Check in the settings for garage 2 if it’s set as a garage door. The open/closed garage door icons before 1:16 are what I’d expect with it set as a garage door. After that, the arrows indicate that it’s using the contact sensor.

15

I realized on Garage Door 1 I moved the sensor from the middle of the door to the bottom. It has consistently been reporting as open after raising the Z-axis limit. I forgot that with Garage Door 2 the sensor was still located in the middle of the panel door so I just moved that down to the bottom as well and now it seems like it’s behaving as it should. fingers crossed!

16

Yea, it’s setup as a Garage Door sensor. Ugh I just tried opening Garage Door 2 and it did the “Garage 2 was opened” even with the arrows pointing out. Interestingly, after closing it, for a split second it changed the status to “Garage 2 was opened” with the ‘open garage door’ icon. Not sure what’s going on with these things…

17

Bingo. Thanks!