Location mode else if returns false?

#2

I’d remove the else if - Location mode changes to Home
co-2017-12-20-21-56-47

You already have an second IF block setting up the Location changes to Home
co-2017-12-20-21-59-30

and I’d suggest changing {addMinutes{$sunset, -30}} to 30 minutes before preset sunset

#3

I’d prefer to put the actions in the else-if. I created the second If block because the else-if was returning false as a workaround for the time being to try and figure this out.

If having a second if block is the only way to do this, then i can stick with that, but it doesn’t seem like that should be the case. It seems like the else-if should be evaluating to true based on the log entries.

#4

then put it in the else not else if section. if you have more than Home and Away modes, you are out of luck.

#5

I want to add additional modes other than just away and “not away”. Maybe a switch would be better suited?

Also, you mentioned changing the addMinutes to “minutes before” - i couldn’t find an offset option when using the presets, can you point me to the correct way to implement that?

image
image.png1522×1496 177 KB

#6

use Time instead of Date and Time

#7

“Changes to” are instantaneous and only evaluate true for a short period of time. If I’m constructing a multiple layer IF statement like that, I’ll either use one trigger at the top (changes to) and conditions for the rest (location is)… or all conditions.

#8

Your expression and the offset @jkp mentioned are both viable solutions… that get you to the same place. But if you want to use them, you have to use the Virtual Device ‘Time’… then choose a preset (Sunrise, Sunset, etc.) and there will be an option for an offset there.

#9

@michicago
Ok - perhaps that’s what’s causing the failure, but it still seems like it should eval true based on the log snippet:
Comparison (string) :5dd4122925624ac923a872714e8c881a: changes_to (string) :5dd4122925624ac923a872714e8c881a: = false (1ms)

I’m not trying to be argumentative, i’m just very confused and wondering if perhaps there’s a bug here, or if i’m going to start running into a lot of issues when i start adding in the other 4 modes i want to check for and need to rethink my approach.

@jkp
Thank you - found it in Time

#10

Trust me, I’m not taking it as argumentative at all. I’ve posted in here where times (in epoch) that clearly should have evaluated true, gave a false outcome. Never figured out why - just rewrote my piston to something that was more predictable.

I think you’ll find the same with “changes to”. :slight_smile:

#11

LOL I never took it as argumentative. I took it as you are learning :slight_smile:

#12

Ok - well i’ll just accept this as an oddity. I’ll try a switch maybe, and if that doesn’t work i guess it’s just going to have to be a bunch of separate if blocks.

Thank you both for your replies!

#13

at some point, you will also get into using presence detection and perhaps setting SHM. this post might help…

#14

dont use else if use else then if or switch case as you probably already have.

#15

changes to as processed by a piston does not process the change itself but an event generated by the change so its true for that run of the piston irrespective of the duration.

#16

That’s what I thought until recently when my garage door sensor started returning a false in my piston. It was a “changes to” trigger, but it’s many lines down in the piston… and even though the triggering event was GarageDoorSensor.contact, it would evaluate false.

Sorry, not trying to pass out bad info. The more I think I’m starting to understand this stuff, the less clear it becomes…

#17

you are right after about 10 seconds of runtime it seems to revert to false instead of true in the same piston run. thats unfortunate.

thanks for correcting me. :slight_smile:

image
image.png1178×805 89.4 KB 

Logs
12/20/2017, 10:09:27 PM +923ms
+203ms	║yes 1
+3223ms	║yes 2
+6243ms	║yes 3
+9263ms	║yes 4
12/20/2017, 10:09:27 PM +921ms
+196ms	║yes 1
+3218ms	║yes 2
+6237ms	║yes 3
+9257ms	║yes 4
#18

Yikes, I hope my pistons aren’t running for 10 seconds to operate a garage door! (the only ones that do are waiting at a semaphore for 9000+ms, and for the life of me I can’t figure out why).

I think mine was only 250-270ms in, but evaluating false. It’s working now so I haven’t bothered to switch it back again.

Interesting litmus test - I never would have thought of that. I’ll have to remember that!

#19

if i remember correctly from checking the code lsat time, semaphore wait is used to synchronize across multiples instances of the piston run. but there may be more to it.

#20

Someone else is seeing a similar “changes to” evaluate false about 2/10ths of a second after the event registers. Any idea why this might be occurring? I’ve had it to… just seems to get pushed out of my logging before I can grab it.

#21

that snapshot does not have trace information. best if we can confirm with a trace on green snapshot and full logs.