Someone on the Smartthings community did this exact thing a year ago. Short version, you rMileage may vary.
Zigbee and ZWave devices DO NOT like to be moved around. The specs can technically handle it… (A Zigbee device is supposed to start hunting for its parent if it’s been unavailable for more than 20 minutes) so TECHNICALLY it should be hunting, in panic mode when you arrive home and the minute it sees its routing parent - reconnect. IN ACTUALITY… (see below)
Your device will be marked ‘unavailable’ or ‘unknown’ when it’s absent. It won’t work like a tracker. You will need to write a template sensor to handle that.
Now actual operation. Some ZigBee devices don’t handle the network reconnects well at all (cough, Aquara cough) fortunately ST branded devices typically DON’T have that problem and generally behave themselves. But it also maters how your network responds to the device being gone then back. The op in the post on the ST site originally came back reporting - hey this is great - see it DOES work.
And then over time it started dropping and they’d have delayed reconnects or disconnects making it ‘work’ unreliably enough to abandon it. I do not know if the trouble was specific to the platform (SmartThings) or not. But given that the spec wasn’t really engineered for the scenario and there’s a BUNCH of other ways to get presence, I personally wouldnt try it. But hey - who knows.
You may still be able to get them but I think that Samsung discontinued it as a product when they licensed SmartThings hub to others and I do not think that anyone has made any new Zigbee based “Works with SmartThings” compatible presence fobs?
I believe that the “Lowes Iris V1 Key Fob” (first-generation) fobs may have worked similarly?
I just want to clarify that I typically share my sensor electronically assembled. When I order a batch of prototype boards, it comes in a set of 10 boards. I will buy 10 set of component to assemble them. What this mean is that there is no soldering on your parts. This is still a DIY project. One still need to purchase an antenna and battery at minimum. There is an expectation to be able to plug the antenna and battery to the sensor.
I am ordering another 10 for the arrival sensor. In the coming batch, I have a manufacture assembled the sensor. I would like to make sure that the contract manufacture can source the components and assemble it properly. If everything goes well, I may make it at larger quantity and offer for sale for the community.
The new board is designed to fit in off the shelf box like below. I used mine box and unboxed depending on the available space in the car.
If you can’t find a reliable Zigbee solution - you might think about a simple USB powered device that connects to the network, something like a Chromecast maybe? Connect it to the network - and then use something like
to detect when it comes back online when you return home.
I am an IOT maker. I just happen to just finish making Zigbee arrival sensor. Based on my experience making them, I just want to share some internal information from the perspective of developer regarding the use of Zigbee sensor as presence detection. It is a bit long info. But, I hope it helps. Here we go…
A Zigbee end device (with most main stream Zigbee stack provider like TI, nordic, and sislab), has the capability to detect “lost of parent” (just simply lost connection). Once connection to the parent is lost, the device with attempt to establish reconnection. This behavior in the latest spec is not standardized. By default, I have stack provider that will try to reconnect up to 120 minutes. Other stack providers will continue to reconnect. This is why some devices are capable to be used as presence and some cannot. Those that stop the reconnection attempt is not a candidate for presence sensor.
One may ask why a device maker stop the reconnection. Reconnection is expensive in term of power consumption. A small battery devices in general will have issue with the power consumption.
With a device that will attempt to reconnect continuously, the small battery that come with the sensor is not adequate. If you search the ST arrival sensor, you will find a lot of people modify it to use 2 AA battery. The famous term about this issue is “battery draining”.
In my device, I attempted to address the “battery draining” issue above. I narrow the scope and ask myself what I can do if I use the sensor in my car. Obviously, I can not eliminate the reconnection issue. Therefore, I am trying to use recharge-able battery. I hope to get continuous power as long as the car is driven daily.
Knowing the car is off or on power, now, I can have separate strategy for reconnecting. While on power, I can attempt to reconnect much more aggressively. While on battery, the sensor will be much more calm. This is unique based on my experience. I do not think any main stream sensor in the market does this kind of optimization.
@iharyadi - thanks for sharing. I love hearing about practical experiences. It drives home the point that just labeling a device by communication protocol alone is insufficient to guarantee behaviour or failure mode.
@iharyadi The use of battery-pack for several rechargeable AA batteries (or better yet a coupe of 18650 batteries) with USB connector for use with USB to 12-volt battery changer sounds like a great idea if specifically making a Zigbee arrival sensor that is meant to act as device tracker for cars where the lager size of a battery pack might not matter as much as battery time and radio range matter more.
Will you be using a Zigbee module based on CC2652P that has a powerful radio for better range?
Follow-up question is whether or not you could extend the popular ZHA integration component support and make use of the “Device Tracker” or “Proximity” integrations for presence-detection for a more standard approach instead of having to build custom components or scripts and make complex automations?
It definitely sounds like a very interest project to me, however I think that the success will depend a lot on easy you can make the whole * Presence Detection solution to work with already well supported Zigbee implementations like ZHA integration (and Zigbee2MQTT).