SmartThings Community

[RELEASE] Enhanced Arrival Sensor - need to temporarily disable an arrival sensor? Now you can


( I hate Mondays) #1

I’ve recently purchased a SmartThings Arrival Sensor and immediately found the need to be able to disable it once in a while. Sure, give it to someone who will come water your plants, but when you’re back home, you need it to stop working until next time. I’m normally using it to disarm alarm, etc. so I modified the stock DTH to allow for one more attribute enabled and three more commands enable, disable, toggle. The commands are there so that I can programmatically enable/disable it from CoRE.

In the ST UI, tap on the ON/OFF button to turn it on or off. When you turn it off, the sensor will immediately show as “not present” and will stay that way regardless of the physical location changes of the arrival sensor.

Presence sensors: how do you avoid smartthings from thinking you're home when you're not?
Samsung presence sensor
Arrival routines running after Internet drops and is restored
3rd Presences sensor
Sheilded box for presence sensor
Presence Activate/Decativate
Outdoor Sirens for UK? (2018)
(Brian Smith) #2

This is great! Something I’ve noted that ST has needed for a very long time. Fobs are not expensive and easily given to guests or pet/plant sitters. It is too difficult to untangle them from all the SmartApps all the time when they are not in use and re-add them later. This is the PERFECT solution. Great job!

(Bobby) #3

As I was looking at this, the tone capability caught my attention. CoRE can use it, right? It would make it a nice way for Ask Alexa to find the keys. Sorry ‘shiny objects’ derailing the conversation…

( I hate Mondays) #4

You can do it. CoRE supports all capabilities listed in the Docs. Regardless of what capabilities it supports, these are only used to group devices by type. If you are able to select the device you need (regardless of which capability you used to find it) you get access to all standard and custom commands provided by the device, plus all the virtual commands provided by CoRE. If ST adds a new standard command, you would still be able to use it by manually providing the parameters, assuming CoRE is not updated to “know” that new command. But I digress… :wink:

( I hate Mondays) #5

That was exactly my reasoning. I don’t want to go to SmartApps to remove the fob from the rules - even worse, if the fob is the only device in that SmartApp you may have to completely delete that instance. By modifying the DTH I can control which fobs work, without the need for virtual switches to control behavior. And by providing the enable() and disable() functions, I can have CoRE design a time schedule during which the fobs work. So the real load pistons don’t get so complicated, involving time along with the fob…


Ambitious, but seems like overkill. A lot of community members just add capability.switch so it can be turned on and off. That way it can be used by any routine or smart app.

See, for example, the popular:

( I hate Mondays) #7

I like my approach better because:

  1. It is self contained - does not introduce new virtual devices
  2. It allows me to control each fob individually

Haven’t looked at the Virtual Presence Plus, but will take a look. I searched for ways to disable a key fob and found nothing, so I built it quick :wink:


Try using the quick browse lists for presence. Some creative stuff there. :sunglasses:

(Robin) #9

@ady624 I love this DH… Just what I need for disabling fobs without having to remove them from every smartapp… Thank you!

I also use it to test my automations, saving me having to use virtual switches during testing or having to go for a walk.

One question, when disabled the presence instantly changes to away but when I turn back on it can take 4-5 minutes to come back to ‘present’. My understanding is that these fobs ping every 20 seconds so do you know why it takes so long to come back. Not a problem in the real world but would help speed up testing if it responded faster.

Is it possible for you to apply your magic and change the on/off button to an auto/manual button, and then allow manual toggle of presence when in manual mode? (Like to virtual sensor can)?

(Robin) #10

Is there any way to decrease the reporting interval of ST presence sensor?

I read somewhere that these devices report every 20 seconds, I would like to reduce this to 5 seconds.

Sometimes when I arrive home my alarm does not deactivate quickly enough (even with the 10 second alarm delay I programmed via CoRE).

I’m aware that making the report interval shorter may trigger more false departures (missed pings will count up faster) so second question:

Is there a way to adjust the number of missed pings prior to reporting away whilst only requiring one ping to report arrival?

I have found the following post by @tgauchat but I can’t find a matching configure section in the DH by @ady624

(Bojan) #11

Hi there, I was super excited when I saw this device handler that you created I just want to say big THANK YOU ! it saves me a lot of time in so many ways… I have one small question, it seems that ST changed arrival sensor, week ago I have bought new ST arrival sensor and in the device option stands “arrival sensor HA”, also when I try to change that with your enhanced arrival sensor device type it doesn’t work :frowning: no ring to find keyfob, not presence no arrivals only when you turn off it turns off and it doesn’t come back on at all. It works with my older sensor like a charmed :smiley:

(Orange Scuba) #12

I just bought two ST Arrival Sensors and I can confirm that this DTH doesn’t work with the new Arrival Sensors. I got the exact same results.

(Borristhecat) #13

Hi @ady624 Is there any updates for this? Just tried the DH and it also doesn’t work on my new device?

( I hate Mondays) #14

I’ll need to release an update, just found out.

(Borristhecat) #15

Think I managed to do all the testing in the end (for now at least), but shows how usfull your webcore presence device is and this would be; as I had to remove the battery and wait 2 mins on every test. The force present and not present is a massive time saver on the WebCoRE one!

(Travis Muszynski) #16

I’ve used this in the past on other arrival sensors. This time, I installed a new arrival sensor and then swapped out the device type with yours. It shows the sensor is at home. I turn it off, it shows the sensor is away. I turn it back on, and it wont register as being home.

Also, if I swap back to the ST handler, it picks the sensor back up.

( I hate Mondays) #17

I think you need to leave/return for the sensor to resync after being forcefully set into any mode. The sensor won’t send a new event when you disable that forced mode, so move a little with it, see if that helps.

(Warren) #18

@ady624 Just found this thread and was wondering if you had done those updates? Or were still planning to/

(Warren) #19

Turned out to be a pretty easy job for the newer ZigBee sensor (tagv4 - 2016 release). I just took the stock Arrival Sensor HA and made a few tweaks to it and loosely borrowed some logic from @ady624’s code. Basically, it just doesn’t create an event for presence if it is disabled and when reenabled it would assume it is in the same place. I may implement some other tracking of the state behind the scenes so that it could capture a change while disabled but I haven’t quite decided how to do that just yet.

Anyhow, the updated handler is on GitHub if anyone wants to try it out. Any issues or suggestions just let me know.

(Warren) #20

Just a quick update, I decided to track the presence along with the enable/disable. So, the status will now be one of either enabled-not present, enabled-present, disabled-not present, or disabled-present. Thus, the sensor’s presence is tracked in real time but just not reported via the presence state.

v1.0 is up on GitHub, feedback is encouraged.