webCoRE mobile app - iOS Source Code


#48

My pleasure. And wasn’t that easier than monkeying with source code? :smiley:


#49

I appreciate the help, but this I a band aid for me.

I’ve proven through logs and testing that the geo fences are being updates way before they should. I’d like to see these tests that show smaller geo fences are an issue. If I can get 10M accuracy from my phones, why can’t the geo fences be tailored for specific use cases? I am positive there are issues that could be resolved here. Root cause issues.


#50

We both just got home and now the piston doesn’t update statues.

Both sensors stuck on “arrivingAt” house


#51

It’s hard for me to test your piston as I only have one mobile… but at first glance you need to reconsider using ‘changes’ inside ‘on event’… it’s basically a trigger inside a trigger which is a recipe for disaster.

Don’t be scared of copying blocks of actions multiple times… sometimes piston efficiency can complicate things too much.

If you hold shift during drag-n-drop it makes a copy of your actions.

Also, previousPlace is a handy tool to prevent currentPlace triggers from other locations.

Maybe do something along the lines of:

define
Boolean pistonActive

On events from sensor 1

IF
pistonActive IS False
THEN

set variable Piston Active = True

IF
ALL of sensor 1 and sensor 2 currentPlace ARE Home
Do stuff for 1 arriving home when 2 is already home
set variable Piston Active = False
end if

IF
sensor 1 currentPlace IS Home
AND
sensor 2 currentPlace IS NOT Home
Do stuff for 1 arriving home when 2 is away
set variable Piston Active = True
End If

IF
sensor 1 previousPlace IS Home
AND
sensor 2 currentPlace IS Home
Do stuff for 1 leaving home when 2 is home
set variable Piston Active = True
End If

IF
Sensor 1 previousPlace IS Home
AND
sensor 2 currentPlace IS NOT Home
Do stuff for 1 leaving home when 2 is away
set variable Piston Active = True
End IF

End if
End on event

On event from sensor 2

IF
pistonActive IS False
THEN

set variable Piston Active = True

(Repeat above 4 IF’s but based around sensor 2)


Arrival/departure if/then or case statement?
#52

Sorry for the delay, I have been traveling nonstop for a few weeks. I started the piston you suggested. Do I have the right start?

I don’t know how you want me to end the events from the first sensor (End on event) or go into the next events from the second sensor (Adding another On Event section).


#53

The ‘end on’ is automatic… it’s on line 70.

So now you can duplicate your whole ‘on event’ block (hold Ctrl during drag and drop), change 1 for 2 / 2 for 1, and should be good to go.


#54

Ok. I think I have what you are suggesting. I did add one more IF statement for when we both are gone. Not sure if the order is important. How does this look?

So I want to use this in place of my old piston where I use it to close the garage door only if the tilt sensor is open. In my messages on departure, I had a 15 second delay built once a condition was met to allow time for the garage door to close. Then inside the message I read the actual tilt sensor state and put that in the message so that I know for sure the door is closed.

Where would I build in the delay?

Also, I am worried that if we both leave, and one sensor triggers the piston say, 5 seconds after the other sensor, my garage door won’t close.


#55

For the delay, take this block as an example:

Change this to:

then
with garage door (never cancel)
close
wait 15 seconds
send notification - blah blah blah
set variable {pistonActive} = False

That is what the {pistonActive} variable is for… piston will only fire when it is false, + use never cancel when ‘waits’ are involved as per my addition above.

You have some of your true / false values around the wrong way btw… Should be:

Only trigger when false
When triggered, change to true
When finished executing, change to false


#56

Ok, I think I have this polished up.

Fixed the pistonActive I believe. IF it is false, then you can execute. Set it true, then set it back to false once the action is completed.

So what happens if there is this delay in the presence sensor triggers? Say my phone triggers, and 10 seconds later, her phone would have a valid trigger. Wouldn’t it be still processing the pistonActive, in the 15 second wait when I left and her phone was still currentPlace = ‘House’?

This is really the only time any of this becomes relevant. If we leave/arrive individually, I never have any issues.


#57

If the piston is still active, {pistonActive} will be ‘true’ and therefore her leaving will not have any effect.


#58

I understand, but in that case, I would never meet the, ‘Everyone left the house,’ unless they happen at exactly the same time.

What I haven’t added is the location modes. I was setting a location mode to, ‘Everyone Away,’ when both sensors currentPlace was not = ‘House’.

If that never triggers because the piston is active, waiting that 15 seconds for the garage door, I am not sure how that will work.

Here is my location modes added:


#59

I wasn’t really thinking that ‘every one left’ was intended for leaving together… it was more for when the last person leaves (say you go out at 8am and she goes out at 9pm).

The logic you want is doable but will need some form of delay and recheck after an individual person leaves, which will delay you leaving actions.

Another method might be to populate the message itself with who is home, with the message calculated after the 15 second wait.

example message with ternary operator:

IF any of presence sensors location are 'home’
x2 save matching devices to {peopleHome}
then
(leave blank)
end if
send notification (count(peopleHome)=“0”?“Everyone is out” : peopleHome " is still at home")


#60

I kinda lost you where to put this :pensive:

Also, there is one more thing I forgot I had built in. I only turn on the garage switch (Close the door) if the tilt sensor it in the Open position.

Should I just add a restriction to my Then?

I feel I should have the garage door closing separate from setting the location statuses. Meaning, if we manually closed the door, the tilt sensor would be Closed, and that would prevent the location status to be updated…


#61

It was just an example… would need a whole new piston built around such a message…

You don’t need a restriction on the garage door, if it’s already closed then WC wont tell it to close again (unless you are using some kinda mash up motor and sensor as separate devices?)… WC has built in command optimisations.


#62

Ok, sorry. That is the whole point of this piston and wanting to fix the piston being executed when either we both leave, or when one of us leaves and we get another, ‘false,’ trigger because the geo-fences are too big.


#63

You started this thread to solve the issue of crossin the outsider de geo Fence… getting prescriptive messages for when you both leave together v leaving alone was not your original problem… though this thread has certainly gone on for a long time so I may have missed it somewhere.

I have given you the rough logic needed… I’m sure you can figure it out now.


#64

True. I appreciate your help, but I have tried to figure out this issue for over 4 months and have not.

There’s clearly an issue with presence being updated when it shouldn’t (updated even though I have the horizontalAccuracy changed to filter it out) and the sizes of the geo-fences are way too big to be practical. I have provided numerous logs and maps showing that the current way the app works is not feasible as is.

I’ll just have to look for another solution.

I do appreciate you trying to help though :slight_smile: