Feature Request- Ability to "disable" a presence sensor


(Brian Smith) #1

It can take a while to add a presence sensor to al the SmartApps necessary for it to properly trigger various activities when it comes and goes. And, that is exactly why we need the ability to activate/deactivate a presence sensor.

Example - I have a ST Presence Sensor fob that I keep for Guests. When someone is staying at our house, I give them the fob so it knows when they come and go, just like us. The problem crops up when no one is using the fob and it is sitting in the drawer. The house is set to go into Away mode when “everyone leaves” which doesn’t happen because it is still sitting in the drawer. So, when a guest leaves and gives back the fob, I need to remove it from all the various apps…then re-add it back to them when I want to give it to someone else.

Ugh…


#2

Or you could just keep the fob in the car’s glove compartment when you don’t have guests, assuming you drive. Or in some other fashion have a permanent resident take it with them when they go in and out. So guest becomes “plus one,” as it were. Keep the fob in use rather than in a drawer. At least that way you don’t have to recode.


(Brian Smith) #3

I thought of that as well. The problem with that is we have a two car household…and don’t always drive both cars away from the house. So, the cars have different rules than the people presence sensors (fob, iPhone).


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #4

I think this is an excellent idea and very easily added to the SmartDevice Type for the sensor.

Add a Preference input with choices for reporting as: normal, always present, always absent.

We can POC (proof of concept) this and raise up to ST as a feature request.


(Brian Smith) #5

That’s an interesting idea. Probably always absent would work in my case. I would also recommend somehow changing the Tile color or some other indicator to show that it is in “MANUAL OVERRIDE” mode…which is what you are recommending.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #6

That part is harder… at least based upon my understanding of how Tile attributes are linked to Device attributes, but not impossible, I guess.

While I don’t disagree that it is good to have an indication of manual mode, there is a certain elegant simplicity in having “always present” or “always absent” being indistinguishable from the normal present or absent and uses the most minimal code changes.


#7

If “always away” would work for you, just put the fob in an RF blocking storage pouch.

You can buy a fancy one for high xAF score and high efficiency.

Or try just wrapping the fob in aluminum foil.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #8

Ummm… Just take out the Battery? :battery:


#9

That, too, although xAF might be higher with the pouch. Again, just depends on the use case. :blush:


(Scott G) #10

That is harder, and more involved.

I think you would have to create a new custom attribute with 3 possible values (“present”, “not present”, “not in use”) and use that for the main tile instead of device.presence, then make the two attributes mirror each other, except when “not in use” which would trigger ignoring of all parsing.


(Brian Smith) #11

Thanks for the thoughts! Although the bag and the battery are viable options, my original request was aimed at the regular, mainstream user. Telling them they age to place a fob in a big (which they will lose) or take the battery out isn’t the most elegant long-term solution. :smile: Although, for me, both will work and I’ll go dig a bag out of the server room as that is an excellent idea.

The ability to activate and deactivate a presence sensor is probably the most “mainstream” way to do it.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #12

Thanks for the confirmation, Scott.
I haven’t written much of a SmartDevice Type or played with device Tiles for too long, especially since one area that I couldn’t quite grasp was how the Tiles worked – whereas the rest of the code to generally handle parsing, status and events is less cryptic.

Hence my (likely correct) belief that just adding a User Preference that would “override” the Presence State attribute with just a couple if clauses would do the trick with minimal fuss.

Thanks.
…Terry.


#13

I wouldn’t think they’d be more likely to lose the bag than they would be to lose the fob without a bag–maybe less. People who have toll paying devices are pretty used to the idea of bagging the device to block the signal, and that’s a mainstream group.

I can see control advantages both ways. I tell the guest, including a paying guest at a rental cabin, to bag the fob when they leave for the last time. They don’t have to be granted access to my control app, and the home can go into Everbody’s Gone Mode until I come by later.

Or alternatively I can deactivate the fob from the control center so that an UNtrusted person can’t use it to get back in when I don’t want them to but without having to redo all the code immediately. Use Case: my car gets stolen with the fob in the glove compartment.

So in an ideal setup you’d have both options, bag it or turn it off from the app. :blush:


(Ben Edwards) #14

Could you use modes for this? For example: create a mode for the guests that has the house respond a certain way to the presence tag when in Guest Mode (unlocking doors) but then when out of Guest Mode it doesn’t?


(Scott G) #15

How would that work with the typical away, night, etc modes? Wouldn’t you need a Guest version for each of them otherwise when you have a guest, you would be perpetually in Guest mode with no home/away/night distinctions?


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #16

BINGO!

A major limitation in the use of “location.mode” (it is one of very few global variables accessible to SmartApp developers) is that is can hold only one value at a time. I’ve started a discussion somewhere in the Forums (sigh… being lazy, I’ll look it up later…), suggesting ways to have more such globals for specialized purposes – via the use of Virtual Devices with a “data” attribute, … etc.

In the meantime, the standard and customary method of passing information from one SmartApp to another (besides globals), is to use Attributes of the relevant authorized Devices. In other words, “capability.presence” either needs an additional Attribute indicating “disabled” (which all SmartApps would have to be modified in order to use), or, more powerfully, simply, and elegantly, the solution I originally proposed above … i.e., spoofing the value of the available attribute presence in desired Device Types that have capability.presence. This additional attribute would default to “not present” in Devices that have an “off” switch; otherwise it would be set based on user preferences{}.

…CP / Terry.


(Joshua Lyon (SharpTools.io Dashboard)) #17

The Vera had the capability to Arm/Disarm motion sensors and it was a nice feature. For example, I normally had the lights in the garage automatically turn on if motion was detected and turn off if no motion was detected for a period of time. If I was going to be working on a car (or somehow out of the range of the motion detector), I would just disarm the motion sensor while I was in there.

I could see it as a great feature addition for presence, motion, contact, etc.


(Brian Smith) #18

That kind of temporary manual control is very nice.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #19

Yup… SmartThings has the opportunity to replicate this feature, but make it even more powerful.

In the context of Presence Capability, for example, it is nice to be able to decide to lock the Thing into reporting “present” vs. “away”; rather than just disabling it. (i.e., a disabled device needs to have a default state to report, and I think it is valuable to make the value of the default state customer definable).

If SmartThings had Capability Inheritance, I could see a new base Attribute for all sensors.
Since we don’t have Inheritance, there are only three choices:

  1. Add the Attribute “disable” on a case by case basis to existing relevant sensor related Capabilities (or, heck, even disable switches and such?). Doesn’t do a lot of good, though, because the SmartDevice code still needs to provide a way to set this value (unless the UI always adds it automatically) and then react to it.

  2. Create a new Capability with it’s own attribute, but that doesn’t help with coding either.

  3. Add an internal preference variable (as I recommend in earlier posts).

I recommend #3, since adding global functionality changes to ST is “impossible” at the moment.


(Brian Smith) #20

@Ben - To expand what @Sticks18 noted while I was driving home from work… I would need two of each mode / hello home action for every set of actions I wanted to use while compensating for the guest sensor.

To take this one step further, how do parents handle a fob on their child’s backpack. Example - Lets say your child leaves after you leave and gets home before you do. They would be part of the Everyone Leaves and Someone Arrives option in different hello home modes. They might even have a special “kid home alone” mode. But, what happens when you come home (change to regular home mode) and you decide to all go out for a family dinner…obviously leaving the back pack at home. Everyone leaves wouldn’t work. You would have some potentially convoluted hello home actions that set different modes and use those modes to determine who is actually home and leaving.

As an extension of this discussion, how about taking it one step further and have presence sensors only activate Hello Home actions during certain times of the week - say 8-8:30am and 3-3:30pm M-F? I realize that this scenario might not seem common, but it might be more common than we think.

Basically, the thought in this entire thread is a fundamental question to ask regarding the ST system philosophy - should you control how a device controls the system from the device type itself or via a set of SmartApps. I could argue this either way.