Order of IF Conditions when using "Matching Devices"

#1

1) Give a description of the problem
Does the order of the Conditions make any difference when using “Matching Devices”

2) What is the expected behaviour?
I only want the Matching Devices to be filled if Both of the conditions are True

3) What is happening/not happening?

**4) Post a Green Snapshot of the piston![image|45x37]

image
image.png841×246 14.8 KB

I had the order of these 2 conditions reversed but I just changed them “just in case”.

P.s. yes I know 60000 is not 3 minutes…I am playing with different tolerances.

Thanks.

#2

With your “and” in place, I am not sure at what stage that is written to…
(I thought “save matching devices” only referred to that single line)

If you really want insurance, then I would probably split & indent an IF inside that IF.

Maybe something like this:

...
IF X is greater than Y
Then
    IF any of @global's currentPlace is not 'Home'
      save matching devices ...
    Then
        Do cool stuff
    END IF
END IF

This will only save matching devices if both IFs are true.

#3

Thanks @WCmore …I will do some more playing. I had found someone else not getting expected results in Matching Devices so I thought to ask this question.

The only challenge is the other Condition is not a trigger so depending on how I use this (assuming it is the first IF statement, then there would be no trigger.

A related question if you don’t mind. When using a device type variable as I did above, and then setting the ANY or ALL flag at the beginning of the IF statement…I don’t see where the ANY or ALL choice is reflected in the Code after saving the IF condition. I have resorted to commenting the statement as I did on the above piston so I know which I chose. If I manually select multple devices and then choose ANY or ALL then the code reflects this choice.

Thanks again.

#4

My last post needs some work…

I just noticed that your trigger is buried… (I place triggers at top level)

Sorry but I cannot work on this at the moment. (previous engagement)

It might be as simple as changing that trigger to a condition.
(IF any of @global’s currentPlace is not ‘Home’)

This is known, and yes, it can be frustrating. Comments are a great workaround. :+1:

#5

Yes, because if the first condition of an AND evaluates to false, the second condition will not be evaluated. So you have the conditions the right way round for your purposes.

I believe the matching and non-matching device variables will be updated regardless of the result of the second condition. I’m not sure that is an issue though.

What would concern me is that your variable names ‘WhoIsAway’ and ‘WhoIsHome’ are suggestive of being lists of who is away and who is at home. I don’t think your piston will provide that.

The visible part of the piston will fire whenever there is a change to the ‘currentPlace’ of one of your Presence devices. I don’t know whether you really need an ‘on events from’ as the piston will fire anyway, and the ‘on events from’ block runs asynchronously which might not be what you want in more complex pistons.

I am not entirely confident of what the first condition is for. It seems to be testing if the ‘previousPlace’ was changed over 60 seconds ago. My confusion is caused by not being familiar with the device and so assuming that ‘currentPlace’ and ‘previousPlace’ would change at the same time, which wouldn’t make sense as the ‘currentPlace’ has only just changed for the piston to be running.

If the second condition is reached, it will only ever populate ‘WhoIsAway’ with a single device name, that of the one that just changed away from ‘Home’. All the other presence devices will be in ‘WhoIsHome’, whether they are at home or away or also just left.

#6

As far as evaluating the cascading IF Conditions yes I am aware of that. I was looking to discover exactly how this statement evaluated in terms of setting the Matching/not matching devices. I will have to build a test piston with test devices to simulate this. If not then I will be building cascading IF statements as @WCmore suggested…but not my favorite way as my brain gets easily lost in the IFs.

My requirement is that the Matching/Nonmatching devices update ONLY if both conditions are true…I originally had the order reversed but could not find any posts on the actual behavior and too many hours to test so I thought I would ask here. I also later realized that my logic in the “currentPlace changes away from home” will not give me what I need (to your last point) which is simply …after a new presence event, NOW who is home and who is not…but I know how to fix that.

This is to prevent false positives. The previousLocation must have been valid for at least 3 minutes (or whatever time works). So if for whatever reason my webCoRE PresSensor has a quick hiccup, the piston will not fire as if someone had actually left Home (or came Home). This also helps when I drive past my place on the way to somewhere else. Unless I am in the Home zone long enough, it will not trigger to being Home…or if I walked too far down the street chasing the cat for a minute I don’t want the house to think I am Away.

I only have Home and Away conditions at the moment but intend on building the piston to track a few typical places we hang out at…Hence the onEvents from at the beginning. I can build a more generic re-usable piston that works on a variable # of places instead of a bunch of IF’s to figure out who is where and a maintenance headache every time I add/remove/change a location.

Now I just have to get the damn webCoRE presence sensor working on my Huawei. Works pretty good on my wife’s Xiaomi. I can’t get ADB to recognize my phone to disable the powergenie that kills apps pretty much regardless of the battery conservation settings on my phone. Somehow google and phone manufacturers always seem to know better that their users. Apparently when I disabled the battery saving on webCore app on my phone, I did not really mean it :stuck_out_tongue_closed_eyes:

Thanks for the help. I am getting closer.

#7

The matching/non-matching devices variables are updated when the particular tirgger/condition they are set for is evaluated. It doesn’t matter what happens with any other condition in the ‘if’, and it doesn’t matter whether the trigger/condition evaluates to true or false.

My point is that the webCoRE Presence Sensor updates the previousPlace and the currentPlace at the same time (I was thinking it probably did, and I’ve just checked). First the event for previousPlace is sent, and then, in the very next line of code, the one for currentPlace. Your piston will be running because it has received the event saying currentPlace has changed, which means it was typically updated within the last fraction of a second. Therefore previousPlace should also have been updated within the last fraction of a second. So if the piston has been fired automatically, and not using the ‘Test’ button or something, the Age of previousPlace is likely to be of the order of one or two thousand milliseconds at most.

I appreciate the need to deal with false positives. However at the time the piston starts running you aren’t going to know for another ‘three minutes’ if it is a false positive.

However all this is a bit past tense, talking about a version of the piston that it sounds like you’ve moved on from.

#8

ok…this helps a lot with understanding when “Matching Devices” is set.

Also with the Prev/Current place. Now that I read your note, I see why the age of both previous and current place will always be the same…bummer. I was expecting the age of previous place to actually show how long I was at the previous place. So if I was at the gym for 1 hour, it would show 1 hour for prevplace as soon as I left the zone…and then 10 minutes of “null location” as soon as I arrived Home after a 10 minute drive. This would have been a lot simpler than most of the other schemes I have seen for dealing with false positives. I guess I could set my own time variables for each place transition…a bit of a pain.

Is there any way to consider having this changed? I don’t see a forum category for Suggestions and new Requirements. I have a couple other instances with regular switches where this same logic would make things a lot easier. e.g. My front patio camera turns on in HOME mode if the front door opens and also turns off when the door closes. But I still want to capture the motion and video of someone leaving so I force the camera to stay on for 3 minutes. Otherwise the camera shuts off a few seconds after the door is opened (camera is outside above the door. We run a small B&B and sometimes guests open the door to let others in so I want to be able to record this.

I also have 1 more idea to test. I’ll be back…

Thanks for all the help.

#9

Personally, I find that adding comments can be especially helpful with nested IFs…

For really complex layering, I might build the basic structure w/comments first…
(Keeping THEN blocks empty, except for more IFs)
This gives me much less clutter, and I find it easier to drag & drop my code during the early stages…

Afterwards, I’ll go back and add the commands…

#10

I almost forgot… Another key method to clean up the clutter is to only display the “necessary” code.

Here are the options seen while editing a piston. Any changes here affects all pistons seen in that browser.

The settings I recommend (most of the time) are only two:

pic

Checking anything else in this list can make your piston much more cluttered than necessary.

For example: ▼ is much easier to work with than ▼ (same code)

pic