Hey, just diving into Smartthings. First post here. I purchased a kit that includes 2 multipurpose sensors. Given the price and how many doors I have, I opted for something cheaper on my doors. I have the 2 multipurpose sensors working as tilt sensors on my garage doors. Something I’m not terribly pleased with is the angle of detection. They have to be almost completely horizontal to detect the door as “open”. I mounted them as high as I reasonably could, but the door is open far enough for a small bear to walk through. (I don’t have a bear issue thank goodness). My question is, are there any sensors out there that are more sensitive to the mounting angle. Ecolink? I started to mount the switch on a negative angle, but was afraid it would pick back up as closed once the door reaches a horizontal position.
FWIW - that’s the reason I used a door/window sensor. May take some ingenuity and fabbing of parts - but many have done this. Door moves an inch and it’s “open”.
I’ve since replaced my opener, but the old one occasionally would stop an inch or 2 short.
your multisensor, when defined as open/close device, will just detect a magnet and reed switch that does not depend on sensor orientation/angle. There is a cheaper version of similar looking sensor that senses magnetic open/closed and temperature.
As you know, your multisensor, when defined as a garage door sensor, works by sensing orientation. If you wanted to bias/offset the detected angle, then you could build up the base angle with additional mounting tape - might be annoying but you could offset the angle to any amount until until it worked.
That angle is hard-coded into the Device Type Handler and should have been made a preference variable.
-
You can make a personal copy of the DTH and set it to be as sensitive as you desire.
-
or You can mount the sensor on a sloped block of wood or other jury rigged bracket such that it is “almost tilted open” when the door is still closed.
Thats odd. Mine detects almost immediately upon the angle changing - which it does immediately, because the sensor is on the highest pane of the door. What happens is I get a series of alerts, first saying the door is in motion then saying its open/closed state.
Yeah, i’ve thought about using a cheap door/window sensor and finding another use for the multipurpose sensors. Just thought I would ask before fabricating a bracket. Thanks for the input!
I thought of that, but by biasing the angle physically to gain my desired outcome, I would have to offset it so much that when the door is completely open, it would be almost back to horizontal. I haven’t test this but it might pick back up as being closed again.
I like the DTH idea. I may have to give that a whirl.
I was trying to mimic if for some reason the door didn’t completely shut, or if it started to open and I stopped it for some reason. I tested this by opening the door and stopping it. Even with the sensor as high as I can mount it, it still takes several feet of travel for the sensor to lay flat and change state to open.
It is definitely the most powerful / flexible option, and educational…
See the angle sensitivity video:
I do have one question about copying a DTH from a template. I assume I need to change the definition before I hit the create button??? Name/namespace/Author… Or just point me to a quick tutorial so I can follow some basic best practices. Oh, and check out this crazy hard to decipher logic:
if (absValue > 900) {
contactValue = 'closed'
garageValue = 'garage-closed'
} else if (absValue < 100) {
contactValue = 'open'
garageValue = 'garage-open'
}
One can probably guess the scale is 1 to 1000. This also confirms my fear that if you bias the angle too much it could return to an open state.
You can change this anytime; the saved item in My SmartApps is referenced an ID, not by the name.
But it sure helps avoid confusion if you use a unique name for your version.
The scale is actually -1024 to +1024 (well… it could be -/+ 1000), but “absValue” is assigned earlier in the DTH to take the absolute value (since you’re not likely to flip your door entirely over 180 degrees!).
To allow some leeway for not perfectly perpendicular to the ground (0), or perfectly parallel (1000), it allows leway of “10%” (100 units).
To give it more leeway for open or closed … adjust either or both numbers appropriately.
For example, to consider even a “tiny bit open” as “open”, then instead of < 100, try < 700.
Yeah, I suppose I should have been more clear. I was referring to the result after taking the absolute value not the raw value. It also allow you to mount it with either end up…I wish I would have asked this question sooner and I could have changed the axis while I was at it and mounted it even higher on my door.
I did just have an idea of bringing back the raw value as the state temporarily to determine the actual value when completely closed and my desired level of open. Then just make sure I have enough tolerance to determine the difference. Thanks for the help @tgauchat.
Did you ever do this? I was disappointed by the default behavior too.
My solution for now involved modifying the DTH to be more sensitive. I opened up the live logging and opened and closed the door several times and watched the raw value. One door is slightly more perpendicular than the other so I used the one that was closer to zero and made that my reference. I gave myself a little buffer and decided to make >900 my “closed” state and <800 my open state. I think the default was something crazy like 100 or 200 for open. This resulted in my door showing open at around 1ft.
My next step was to try and calibrate the sensor so that you told each individual sensor what was open and what was closed. I think one of my doors was showing over 1000 when closed, so I could reasonably say that anything < 900 would be open, but my it caused problems for the other door. I never had time to sit down and get that part working, but for now the simple solution of changing the raw values manually works. I can gladly share my DTH or show you what I changed. It was literally just changing 2 numbers.
I’m dabbling with the 3-axis readings as I try to determine how to handle a skylight. Ultimately I’d love to come up with a warning system. If rain is in the forecast on a work day, have it notify me if the skylight is open enough to let rain in. And if the skylight is open when outdoor temperatures drop below T temperature, again warn me.
But the 3-axis reporting is imprecise at best. On an iPad cover flap, starting on a flat table and returning to a flat table, the X axis starts at -1009… when the flap returns to the flat table, it’s at -1022.
A 1.5% variance seems pretty reasonable to me. This isn’t a scientific instrument.
I agree. I think this is normal. If you dig into the DTH code, I think you may also see that the raw values only report back during “acceleration” too. I saw similar results when trying to optimize my multi as a garage door sensor. I found that the variation between closing the door was somewhere around 1%.
The sensor works well for determining the difference between 0 and 90 degrees. I haven’t measured the angle on the top panel of my garage door, but i’d say anything less than 25 degrees is going to be tough. Especially if you have multiple devices. There was an even larger discrepancy between my 2 doors. Of course you could always copy the DTH and use a different one for each sensor. I considered that.
Good luck with your project!
I’m thinking of doing a custom DTH for this… or perhaps webcore.
The skylight follows the pitch of the roof, which is @ 15 degrees down toward the north when closed.
So the closed position would have a 3-axis location beyond which any appropriate values would indicate ‘closed’.
Anything short of that would indicate ‘open’.
The skylight opens to approximately 15 degrees above horizontal.
Within the ‘open’ range, there would be “vent open” or similar where the rain cannot come in, and “rain open” where there is a risk of rain getting in.
“Rain open” would be @ horizontal up to full open.
So I guess I’ll do some testing with the iPad flap and webcore, and create a piston that can report to the system and call forth various alerts. If that works well, then perhaps I’ll see about making a DTH.