All of a sudden piston if/then statement not working correctly

#1

I have had a piston that for over a year has been running fine but all of a sudden is hiccupping. It is a bathroom light triggered by motion with a cool feature that if you manually click the light switch on, it will stay on for up to 30 minutes.

It has a few variables that are used and if the light switch changes to off the variables all change back to false. What I am seeing, however, is that even when the light switch changes to off, the if/then statement that changes the variables evaluates as false. Like I mentioned before, it had been working fine for months and now all of a sudden something is wrong. Screen shot below of the if/then statement and the log that evaluates it false even though it should not .
I welcome any ideas on what could be going wrong!

image
image.png784×967 70.6 KB

#2

Anyone with ideas? I thought I fixed it by deleting the device from the Piston and re-entering it but that did not work.

#3

If this is HE, you might reboot the HE system and see if that resolves.

After that you can try pause and resume of the piston.

#4

I am on HE. Rebooting did not help

So far pausing and resuming has worked at least for the last few minutes and testing.

I have used this Piston and WebCore now in general for a few years and maybe 10-15 pistons running at once. Never had an issue like this before.

Was I just lucky and this sometimes does happen or did I potentially miss something when creating the Piston in the first place?

UPDATE: Now it is still not working properly again. The Hub shows the event that the switch was turned off but the if/then statement to set the variables back to false does not trigger

#5

So you likely need to show the entire piston.

so we can see all the logs.

The other choice is to use xxx is off, depending on the overall use case.

#6

Here is the piston. How do I increase the window on the browser where the log is? I can only get a limited amount of logging to view at a time and cant figure out how to increase it :slight_smile:

image
image.png1178×1423 76.7 KB

Here is the one part of the log which is most important. Everything in the Piston works and has worked for months. Now all of a sudden when the light is turned off it does not change the variables to false:

image
image.png607×654 44.8 KB

#7

So change the last ‘changes to’ to ‘is’ off

I expect there is a race in events. Note the called myself is true in the received event.

Also you have a nested ‘stays’ on the else side of a statement.

stays needs to be run over on every piston run to track state. So you don’t want to ever nest them.

#8

I’ve never had problem with that ‘Nested stay’ but I have separated it into a separate if/then statement. It seems every time I build a Piston with an ‘else’ I regret it. LOL

But if I do that it becomes a condition and not a trigger. What if someone manually turns the light off when exiting the bathroom? In that case it would not trigger the variables to change back to false like I need it to, right?

#9

other parts of the piston already use that device as a trigger, so it already is a trigger for the piston.

#10

When Bathroom Light & Motion's switch changes to off is evaluated, it only returns true if the current event being processed is the device switch being off, and the last time it evaluated a switch event from that device it was on. The log says that wasn’t the case and so there wasn’t a ‘change’. Bear in mind it doesn’t matter what has actually happened with the switch and in what order, only what events fire the piston and in which order, and whether the piston evaluates that statement when they do.

The cause of the problem doesn’t really leap out at me but there are stays statements around which might allow events to get out of sequence.

As @E_sch suggests, it doesn’t look like you actually need to test for a change in the switch, as it does no harm to set those variables whenever the switch is off. There are four other trigger conditions that will cause the piston to subscribe to the switch events, so the piston is still going to run when the switch changes to off. So you can just avoid the problem.

#11

@E_Sch @orangebucket thanks for the help on this and the explanations so I can hopefully avoid such issues in the future. The insights as to why this is happening are very helpfull.

Still unclear why the Piston thinks there is not a change when in actuality the light is switching off but I will take your advice(s) and change the line to just a condition and not a trigger. Why it worked for close to a year and all of a sudden did not is maddening but I will punt on that one. So far it is working fine.

Just when I think I have figured out WebCore I find out how little I really do know. LOL

#12

It does seem strange doesn’t it?

Imagine a switch is off. A considerable time later it is turned on and then immediately turned off again. Assume this happens so quickly that by the time the piston starts up to process the on event the switch is already off. What happens when the piston is processing the on event?

  1. If the piston includes the trigger condition if switch changes to on, what should it return? The switch did change to on but it has already changed back to off. Clearly the piston wanted to do something when the switch changed to on. Should it still do that thing?

  2. If the piston includes the condition if switch is on, what should it return? The event says the switch is now on, but if the state of the device is looked up in ST or HE it will say it is off, and indeed in this scenario it is actually off.

The actual behaviour is:

  1. The piston respects the event data. The event data says the switch is on so as far as the piston is concerned it is. If it believes the switch was previously off then the switch has changed state and so it returns true.

  2. The piston still has to respect the event data. The event data says the switch is on so the switch is on. It can’t have it both ways. So it returns true. It will keep doing that for the duration of the piston execution, even if it sleeps for two hours in a wait and the switch has changed state dozens of times since.

Note that I said 'If it believes the switch was previously off'. How does it know that? It has already been established that the piston is governed by the events it receives so it is no use asking ST / HE as they don’t know what order the events were in when the piston processed them. So whenever the piston evaluates a changes trigger condition it caches the event value. You could perhaps argue that the piston should cache that when it starts up, but it doesn’t, it caches it in each trigger condition when the condition is evaluated.

Now supposing the piston is actually a bit more complicated and says if time is between sunrise and sunset AND switch changes to on. If last time the switch changed to off was in the middle of the night the piston would have evaluated the time restriction as false and so not bothered to check the trigger condition as it wouldn’t change the result of the AND. So the off value would never have been cached.

That is basically the mechanism in play. Does it make sense? Could it be done differently? I don’t really know. It may be the price you have to play for being able to work with events rather than just the current conditions. The one thing I can say is that if you put an explicit trigger condition in your piston (like changes) you should make sure that it will always be evaluated if the trigger event happens.

Somehow I doubt that has made things any clearer.

#13

LOL. its been a while but just got back in the forum. I appreciate you trying to explain. It is confusing but makes sense at the same time.