Multifactor Presence


First off here is what I have so far:

I feel like there is a better organization/execution of this and I wanted to see what the community thinks. I feel like the piston will skip certain portions given my still fuzzy understanding of subscriptions between triggers and conditions. I’ve read the sticky on it but I still dont truly get it. Too hard headed :stuck_out_tongue:

Ecobee Thermostat Control

Honest noob question here. What are you trying to achieve? I mean, what is the need behind it?

I’ve been using iOS presence and it’s been rock solid. What more does it bring you?


from your post seems like you may have read the sticky i posted on the topic but something about triggers and conditions is still fuzzy. what about, you ask me questions to clarify anything thats fuzzy and I try my best to help clarify it?

i get a chance to learn something about what else i could add to that sticky post to help clarify it for other users as well. :slight_smile:


Sadly on the android side of things our really cool power saving feature called Doze will shut down processes to conserve power,data, and resources. When that happens that presence sensor virtual device for our phone isnt exactly the most reliable. From that reasoning I’ve attempted to adopt other methods to properly show presence. I found that IFTTT works, but not 100% of the time (that would be here and my previous residence on the other side of the states. I’m hoping with this I can set things up where multiple factors will yield better verification. As a backup I even bought a arrival sensor for testing.


Of course, and I want to say thank you for our PMs beforehand on the subject.

  1. When you add triggers conditions lose their lightning bolt and its a toss up to understand whether things will be skipped or kept. An example would be my two variable checkers at the bottom of my piston. Had it been without logs I would have suspected I needed to force subscription. I understand the execution if the trigger is in the condition, but external and in line as I have it is confusing given my usual mix of both within one piston.
    -at what point do you need to force subscription to ensure your conditions work


and you are welcome in advance. :slight_smile:

let me start with this. you want to force subscription when you want to detect change soon as the change happens. like in your piston for lines 120 - 133, if you wanted that if to be checked soon as @MikePresence variable changed you would want to force subscription to that variable.

otherwise it will only be checked when the piston is next executed due to some other event subscription. which in this case would be one of the subscriptions from the IFTTT executes triggers or any of the changes to triggers.

so, if @MikePresence was a global variable that is also modified in another piston, it would not get checked in this piston till one of this other triggers, triggered the piston.

does that sort of kind of make any sense? :slight_smile:

please dont hesitate to keep asking if that raises more questions than it cleared up.


Actually that does help a lot. It does raise another scenario I want to understand more.

Current version :

does line 57 need to be forced or would the triggers at 78,83, etc. do the work for me? I want to make sure that if 2/5 presence methods are active that it will always turn on switch 18 but I also don’t want things to bog down badly. I remember talking to ady624 about semaphore waits and how situations like this can cause huge weights on the system (something I’m finding could be happening given my multitude of pistons and combined tasks like this).



well line 57 will be checked whenever one of the previous IFTTT executes happens or any of the changes to becomes true. so, in that sense it will work. however, the value of @MikePresence is incremented only after the line 57 check so the check of 2/5 will only be true after the next IFTTT execute trigger happens.

if you are interested, there may be some room to streamline the piston. cant say for sure, till you tell me a little bit more about the use case.


No problem. The use case might be a bit hap hazard as it seems like IFTTT never seems to work every time for me. My main goal is to find a way to verify that I or my wife are out of the house. If so those variables will adjust accordingly and facilitate other pistons that do things such as control the AC, turn off fans that we aren’t using, turn off lighting, and arm the house. For the return of the sensors it sets an automatic adjustment for the garage doors timer so it’s a much early close than the usual.

Given how things are acting now it really seems like I should just scrap a good portion of this piston as I’m barely getting sms responses except for offs and my variable MikesPresence is staying at 0 a majority of the time.


got you.

need any help with it or you are good? :slight_smile:


Any ideas for a solid presence sensor app/method that accurately present presence would be great. I find that the default android ST device just stays present the whole time. IFTTT works, but roughly 20-40% of the time (could be latency but I really dont know and have become frustrated with it). I’ve contemplated tasker but most of the functionality I want seems to require rooting my phone. I’ve done this multiple times, but I am trying to enjoy the stock rom on my pixel for the sake of android pay and such.


yeah, IFTTT when i used it was always high latency for me. i stopped going down the rooting path also.

do you by any chance, happen to use asus routers? there is a really solid method for presence with those.


or just wait till @ady624 realeases this: :slight_smile:


I am chomping at the bit for that app of his. As for a router I don’t have an asus router sadly. I have a TPLink OnHub.


not too far off here, maybe just tough it out and switch stuff off and on the old fashoined way till then :slight_smile:


May be. I’m seeing how far I can get with tasker right now. I have an arrival sensor in either car, though it was peculiar when the arrival sensor just shows as unavailable first, then not present. That was a weird way to switch.


That’s actually very easy to fix with Android. In settings/battery, use the menu icon to select battery optimization. Turn it off for the ST app.


I wish it were that easy, I’ve done that :frowning:


I use Wifi + Bluetooth (Wifi is a script that runs on the router and Bluetooth runs on rpi)

So I have a a RPI zero at the closest point to my parking spot ( adapted to send a webrequest to WebCore) as my cellphone (which i set to hotspot mode in my car) takes too long to shut off the hotspot + connect to wifi to have a good entry routine.

The wifi at home is pretty good but the bluetooth detection range is not (15 to 30 feet depending in which room i’m in) so the router also sends webrequest to WebCore using this: (

Both webrequests activate the same variable, which requires being false 2 minutes to put the presence sensor at AWAY and instantly put it at present if it becomes true. Its been 100% reliable for me once I trained my wife to not put her phone in airplane mode at night