[SOLVED] Erratic Android Presence Reporting (fix=Tasker/SharpTools integration)

After creating the simulated presence sensor, did you go back to SharpTools and authorize the new device before opening Tasker?

1 Like

The Simulated Presence Sensor does not show up in either Tasker or Sharp Tools, although it is pesent in the IDE and Smart Things App.

So, did you do as Joshua just suggested?

The problem is that, you need to ‘redo’ the device authorization process every time you add new devices that you want to have working with SharpTools.

So, after adding the new simulated presence sensor to your SmartThings, it will NOT show up in SharpTools until you go back through that process within the SharpTools app.

i.e. in SharpTools on the Android device,
-click the menu button in the top left,
-go to Settings,
-click ‘Authorize Things’,
-log in on the SmartThings webpage that opens,
-look through the list to locate your new simulated presence device,
-check the checkbox for your new simulated device,
-click the green ‘Authorize’ button at bottom left

That new simulated presence sensor should now show up in and be usable by SharpTools.

The last step is to make sure to go to the list of the devices that you have authorized in SharpTools app and ‘Subscribe’ to it.

1 Like

I’m loving this. The downside is that I am en route to being addicted to Tasker. I’ve got the retry logic working, too.

Still pondering Autolocation, but first I’m trying the accelerometer trigger. It makes sense to me to use a low power sensor to prevent Wi-Fi scanning until needed. My phone is much more often at rest than it is moving. Does anyone here have any observation/experience with how this works? Is it right that this option prevents Wi-Fi scanning until motion is detected? Then, does that introduce any lag that noticeably slows detection of arrival/departure?

1 Like

This is awesome! I haven’t tried it, but after your question, I LOVE the idea. Man, if it works like you’d like it to work, I’ll be trying it too.

[quote=“joshua_lyon, post:19, topic:43163”]Also note this portion from the Tasker guide linked above about improving battery life by adding a second, lower power context along side your Wifi Near context[/quote]I think I’m losing my mind. Please help. :slight_smile:

I’m sure I set my profile to use a low-power context, i.e. the accelerometer, to prevent Wi-Fi scanning unless motion is detected. But now, I can’t find where that is. (I’ve gone through the links above, but I’ve so immersed myself in Tasker and Tasker tutorials that I’m lost.) Could I get a pointer/link?

How is this working for you after a week?

Can you share exactly what you did? Did you use the sharptools and tasker setup?

Yes, I just followed the recipes here, using Tasker, Sharp Tools and SmartThings.

As a complete newbie, I ran into some challenges where the obvious was not so.

As I documented a few posts back, I misunderstood the entry/exit conditions for “Wi-Fi Near”. I thought disconnecting from the SSID would trigger departure, but -thankfully - it doesn’t work that way.

One stupidity was totally misreading the !~ operator. I thought the ! was appended to the variable name, as opposed to bring prepended to the ~ character. Dumb!

Another was not understanding that the NOTIFY CANCEL command needed to refer back to the prior notification. I used random labels until I found out that I had to cancel by title. Dumb!

I’ve used the FLASH command to debug. But I wonder if there is a way to view variables as I step through the command sequence? This seems like a pretty basic programming capability, but I don’t see it documented anywhere.

As documented above, I’ve shortened up my Wi-Fi scanning (in Tasker preferences for display on and for display off) to 90 seconds. No idea if that’s the right interval…

If anyone’s interested, I can post screen shots of the profile and tasks, but it’s pretty much what’s documented here. I could also provide my XML exports, but it only takes a couple of minutes to enter.

1 Like

A couple weeks in, and it’s working fine for me. Autoloction made the difference.

But I found out that the front door lock is fickle. It works so much better if a repeater is in close proximity. Consequently I’ll be ordering a smart plug/outlet of some sort, to replace the one I took from its location close to the lock to use elsewhere.

I’m curious about Autolocation. What are its advantages over “Wi-Fi Near”? Was it reliability or the ability to have a more flexible perimeter? I ask because I’m very happy with the reliability of “Wi-Fi Near” and my with-no-actual-experience opinion is that Autolocation is good for expanding the perimeter (and I like a tighter perimeter).

One thing I’m learning with ST: if something works, don’t mess with it! Lol

If your wifi near is working for you, there’s no need to change. Mine was not working that well. So I tried a few different things, including bluetooth near. Nothing worked consistently until I went with a virtual presence using AutoLocation. I set up three geofences: home, neighborhood, town. Since I did that, ST opens my front door and turns on the light consistently when I pull into my driveway. I don’t know what if any effect the outer geofences are having, but the thing is working.


[quote=“joshua_lyon, post:19, topic:43163”]
Also note this portion from the Tasker guide linked above about improving battery life by adding a second, lower power context along side your Wifi Near context.
[/quote]Josh, a couple of questions, please. I’ve had some issues with what I call “false negatives” on presence… The phone will drop the Wi-Fi connection for 1-2 minutes, then reconnect, usually while stationary.

I never got around to implementing the lower power context, mostly because I couldn’t figure it out. Might I ask you for a little hand-holding on some steps to perform?

Your opinion on autolocation. Looking back at this thread, I didn’t use it because I thought it would be best for setting wider geofences. But for my current issues of going “not present” for short periods, do you think autolocation would address that?

Despite the above observation, Tasker plus Sharp Tools is still the best Android presence solution.

I’ll leave it open for others to respond first as I don’t personally use the Wifi Context + Low Power Context. When I had location profiles, I primarily used AutoLocation and it worked well for me. I’ve seen some people complain about location providers using too much battery, so I try to use the minimal features and pare things back if I get a bit wild testing. Alternatively, you could use some sort of exit delay if it is the exit condition that is causing you trouble.

1 Like

When I saw your suggestion, I thought I had done that - by having my SmartApp delay in response to a presence departure and cancel its actions if presence returned in a defined period, e.g. 90 seconds. However, thinking it over, I think you might have been refering to implementing the delay in Tasker, which would be more elegant. Can you be more specific?

FYI… I’m using the resiliency loop, from Hellfire51, that you referenced, .

is there a way to post the whole setup? (code / profile and task for tasker)

For anyone following this thread, if you hadn’t seen this, take a look. It’s complicated but the instructions are precise, so pretty easy.