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

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.


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!


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…

1 Like

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:

1 Like

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:

1 Like

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:


1 Like

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:

1 Like

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.

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

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

1 Like

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!

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 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.

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

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.

1 Like

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.

I tweaked a few things to make the flow better and added some options to support that. v1.1 is up on GitHub.

Basically, the issue with all of this is that I haven’t found any way to change presence without triggering an event. That’s not so bad in itself but that complicates other things like when you want to disable and enable and the device has moved. At any rate, after a fair amount of tinkering, I decided that the best way to do this is to give an option to force the mode and then it will stay in that mode.

For disable, it stops responding to event changes after it is disabled and for enable it generates events as normal (same as original design). The new options, available for both disable and enable, are:

  • auto: this is the normal mode where the hub tries to reach the sensor and marks it as present or not present based on that. The behavior is that it will start looking as normal and will react as normal.
  • present: Forces the sensor to appear as being present even though it may not be
  • not present: Forces the sensor to appear as being not present even though it may not be

Combining these makes it simpler to get the desired behavior. For reference, I personally use “not present” on disable and “auto” on enable. Taking that as an example, the sensor would be away when it is disabled so as to not interfere with SHM events and modes when it is not being used. When it is enabled, it returns to the normal state as it starts to look but does not force it be present

The flow now seems more smooth as long as you can tolerate the forced mode change and what effects it has on SHM or other things that might key off of its presence.


I’m sorry, which updates?