Presence sensor based on Wifi Connection

I used to have a presence sensor on ST based on Wifi connection that worked very good. using that:

I’m not using IOS.

When smartapp stopped working, this sensor stopped working as well.
I am wondering if it is possible to use create a presence sensor that will work the same with Sharptools ? The main request is to implement that without the aid of additional HW .

In theory that same type of concept could work with HTTP Triggers in SharpTools rules.

I’ll leave it open to the community to see what feedback they have. Some people have been using Tasker on Android to detect when they’re connected to their wifi and react to that. Others have combined wifi connectivity along with geo-presence for more reliable presence detection.

In the past, I had also seen projects where people had scripts running on their router or otherwise on their LAN that looked for the presence of certain devices on their network to flag someone as present or not – one of the challenges with this approach is devices are becoming much more aggressive with battery management, so they may enter a low-power state that can make them appear offline depending on how the router/script handles things.

1 Like

I can get status from the Presence Sensor App:

I know my id, it appears in the android app.
Any idea how to fetch the “true” and “false” present field to sharptools every 5 minutes and then update a virtual switch or virtual presence sensor ?

I know this is a polling request which is not the best approach, still can I do something with that ?

I’ll leave this open to the community for feedback, but wanted to share a few comments:

  • Polling is not ideal here.
    • The change in presence is already an event driven process and the ‘Presence Sensor’ Android app natively supports pushing events to Hubitat and formerly SmartThings
    • Perhaps the app developer would be open to allowing you to push events to the URL of your choice (see below though)
  • Some thoughts on the ‘Presence Sensor’ app architecture:
    • The SmartApp seems to register your location/device along with the SmartApp URl that the event should ultimately get delivered to with Callahtech’s server
    • Presence events are presumably pushed from the mobile app to Callahtech’s server and ultimately forwarded to the SmartApp
    • In theory, you could register an HTTP Trigger URL from a SharpTools as a forwarding endpoint with Callahtech (I won’t provide guidance on this per the next point)
    • All the above means you must trust the events going to an individual’s server (rather than directly to your desired destination) if you want to use their app

    While it’s likely there’s good intentions and the whole server-forwarding thing is meant as a simplification / ease-of-use approach, I don’t see any reason why the app wouldn’t just forward the events directly to the SmartApp or URL of your choice so it gives me some hesitation.

  • Tasker could be used for Wifi presence or monitoring notifications from presence apps
    • If your primary usage of the app is for using Wifi as a proxy for determining presence, you could do this directly with Tasker
    • Some people prefer to use Tasker to monitor notifications from their preferred location tracking app (eg. Life360) and use that to forward events to SharpTools or SmartThings

Tagging @just_jake and @RichB as I believe they each made some efforts around presence using Android devices and might have some good insights here.

@josh thanks for the tag.

I have several different types of presence sensing methods.

  • Tasker using a Geofences plugin called AutoLocation.
  • Stock ST location that sets a VR presence Sensor. This has a switch capability that allows you to toggle, on/off / present/not present
  • Tasker to intercept life360 notifications using a plugin called AutoNotification. This in turn sends a rest API command to toggle the a VR presence sensor.
  • Us GH home and away routines to toggle a master VR presence sensor (anyone home / everyone away)
  • I also have a ST routine that sets the presence based on who unlocks the front door.

As you can see Tasker has a lot to do with it but you can definitely do the last one in sharptools or ST. I will be happy to help with any questions you have.

1 Like

Hi Jake,
I’m not familiar with Takser, Is this free ?
I have bad experience with Presence Sensor based on Geofence. I live in a an apartment with poor GPS reception, this causing to showing me as “away” while I’m home.

As I wrote above I already have an app that trace my WiFi connection and send status to John server. This works perfectly, but I have no idea how to bring this to SH.T.

While using Tasker , can I also watch and trigger an event depending on Wifi connection to a network that I choose ? I need to it on several mobiles, is that possible ?

Tasker has a free 7 day trial, the full version costs $3.49 USD.

If you can imagine it you can pretty much do it with Tasker. I do have a profile that when I connect to my Wifi it will send a Http Request using the ST rest API to toggle a VR presence sensor. This particular method works well, the only draw back is the transition from wifi to mobile data it’s not a instantaneous setting of presence but it work fairly reliable.

I’m not so familiar with Tasker.
Can you please share your Wifi based connection Task, Profile and Sharptools Rule ?
I tried to implement , but was unable to make it work.

Hey Shai - were you able to get this figured out? During our Messenger chats, it sounded like you were playing around with using an HTTP action for sending the status to your rule, so I assume you also poked around on the profile side to monitor connecting and disconnecting from Wifi?

While I suspect that it’s a bit overkill for what you are wanting to do, I would note that there’s a neat discussion in the SmartThings community about using a combination of GPS and Wifi to accomplish nuanced presence detection.


Description of how it works (tap to expand)

The setup uses multiple geofences to help it limit battery use while still being able to get high accuracy when needed.

There are three geofence zones:

  1. Service zone - grey very broad zone (outer most radius)
  2. Arrival zone - green smallest zone (inner most radius)
  3. Departure zone - orange zone in between (middle sized radius)

The way it works is:

  1. It uses a large geofence (grey) to define a ‘service area’ at which Tasker should enable high-accuracy GPS resolution
  2. Then if you enter the smallest GPS zone (green), you become present
  3. Once you connect to Wifi, the high accuracy GPS is turned off since you’re home
  4. If you disconnect from Wifi, the high accuracy GPS is turned back on so it can monitor for departure
  5. If you leave the middle zone (orange), you are marked as not present
  6. If you leave the service zone (grey), it disables high accuracy again to conserve battery
    (and the cycle starts back over if you re-enter the service boundary again)

The profile setup is a bit intense as there’s a large number of steps, but if you end up wanting a more robust profile or are interested in alternative approaches (that you can even pick and choose concepts from), you might be interested:

The writeup is in the context of the old Groovy Tasker Plugins, but you can substitute an HTTP action to your rule trigger in each of those cases.

There’s also a neat approach to retrying the commands that set the presence in conditions. This is critical on some devices as they might trigger the profile while the phone is between Wifi and Cellular connections and thus won’t have a network connection when they try to update things.

I was able to make it work. with tasker and virtual Presence sensor that can be create with Vdevice Creator from Yakov Garlobin Channel.

Here are some screens shots:
Rule in Sharptools

Tasker Action which is HTTP Request in Tasker AtHome

Tasker Action which is HTTP Request in Tasker LeaveHome

Tasker Profile for Wifi Active

Tasker Profile when Wifi connected and disconnected


This works for me…


Sorry for being MIA been busy with the kiddos being sick.