Both actually. But in 2 different pistons.
I have another piston that doesn’t trigger when both conditions are true.
In this piston, the issue is that the 2nd condition never becomes true but the condition group becomes true anyway.
This is the crux of the problem right here:
+266ms ║║Condition group #20 evaluated true (state changed) (7ms)
Condition group #20 evaluates to true even though condition #21 never becomes true.
Condition #21 NEVER becomes true. Condition group #20 shouldn’t become true if condition #21 doesn’t become true but it (group #20) does. That’s the bug. It looks like expiration of the “followed by” time is causing the condition group to erroneously evaluate to true? That’s a guess but that seems to be how its behaving.
Condition #21
Contact Sensor 23’s contact changes to open
@Ryan780 do you have admin privs to delete the duplicate thread in bug reports, I don’t.
Can you list for me what condition 21 is? When I look through your log, I don’t see condition 21 at all.
Also, as a side note, what exactly are you trying to accomplish with this piston on the larger scale? There might be an easier way of doing this rather than the followed by. Followed by requires a very precise sequence. If there are any other events for any other subscribed device, the piston won’t fire correctly.
Condition #21 is in the piston snapshot at the top of the message, it’s the 2nd part of a followed by conditional group. I don’t see it in the logs either, which is odd. I don’t see how condition group (#20) can become true without it, which is why I think this is a bug.
I have a yard area with 2 entrances to it, and a beam sensor on each entrance. There are also several motions sensors, one basically on either “side” of each beam.
What I’m trying to do is infer direction of travel through the beam by the motion events on either side of it, and take action accordingly. So if motionA becomes active followed by beam trip I can infer the direction of travel is from “zone” A to B. But if motion B becomes active followed by beam trip, I can infer that direction of travel is from zone B to A.
Why don’t I just use the motion sensors to trigger the lights, you might ask? Again this is an outside area so while they’re ok for inferring occupancy, they’re too sensitive to actually control the lights due to too many false positives, which is why I’m using the beam sensors.
I still don’t understand. Why are you saying that condition 21 is false when there is no condition 21???
Also, your last statement is going to rarely work because of the timing. The last part is the motion sensor staying inactive for 45 seconds but that has to happen within 2 minutes. So, you really only have a 1:15 for it to go inactive. You do realize that with followed by if the sequence is different it won’t work, correct?
There is a condition #21. Look at the piston at the top of this thread. Condition #21 exists, it is part of the piston but it is not in the logs. That’s the bug.
That last piece was still in flux. The idea behind it is to shut the light off in the room that was just left. I can mess with the timing a bit with that. The idea is that to ensure the “room” is empty before shutting off the lights.
I thought I could move this topic for you, but turns out I can’t (or can’t figure out how). There is a specific area for tracking bugs, called Meta - and from in there you can select bug report:
https://community.webcore.co/c/Meta/BugsIt’s evaluated as true when the whole group, group 20 is evaluated as True. I don’t think there’s a bug here. How can the group be true if the individual components aren’t also true?
That’s exactly what @wgmcg is trying to sort out. Let’s stick to condition numbers rather than line numbers to avoid confusion. The way his piston is written is this:
Condition 20:
IF condition 22
Followed within 15 seconds by condition 21
What the logs show (assuming we have the entire log and not a snippet of them?):
Condition 22 is met, piston sets a wake-up timer for 15 seconds in the future
15 seconds later the piston wakes up and condition 20 is evaluated as true
At no point in the logs does condition 21 (the “followed within 15 seconds” bit) become true. So condition 20 should have evaluated false and the ELSE section of the code should run.
So there’s one of two possibilities:
Seeing if any of the @webCoRE_Minions can lend a hand here.
Regarding whether this is a snippet or not, It’s been about 2 weeks so I actually don’t remember. I spent about 2.5 hours debugging this and I’m fairly certain this is a bug.
I can recreate if we need some fresh logs. My point is that I don’t ever see conditon #21 become true so condition group #20 should never become true but it does. I noticed this because my yard lights kept coming on without the beam being tripped. I verified in the ST console that the beam never tripped. Absent a beam event the lights shouldn’t come one.
I think its the same bug as this one fwiw:
It’s also possible that it is logging the group, 20, as true knowing that everything within the group must also be true. If the piston is functioning correctly but just not being logged the way you like it, that’s not a bug. That’s a feature request. If the group is evaluating true, then what’s the issue here?
Sticking to the piston and the logs in this thread (not the linked one), because group 20 should not evaluate true. The 2nd condition isn’t shown as being met (there should be a trigger for the piston to execute before the ‘.time’ executes it).
That’s only true if the second thing didn’t actually happen, which isn’t clear. If this is a logging issue, like I said, the group being true means the components were true. If you don’t like that, that’s a feature request.
Now, if the second trigger didn’t actually happen, then this would be a bug. But the logs say that it is evaluated as true.
So, did the trigger happen? If it did, then your “bug” is the way its being logged?
There’s no event in the logs showing the 2nd condition was met. There should have been a [contact sensor].contact trigger somewhere between the motion sensor and the .time trigger.
The fact the OP took the time to post a thread, said his lights regularly turn on when they shouldn’t, and posted a log that doesn’t show the 2nd condition occurring is about as close to proving a negative as one can get.
It’s definitely not just mis-logging and behaving correctly. The second condition (#21) never becomes true. Again, that’s what the logs above show, that’s the behavior I experienced, and I verified in the ST console logs from the device. The last event from contact sensor 23 (the device in condition #21) that ST logged was at least an hour previous.
When the timeout executes 15 seconds after condition #22 becomes true, the entire condition group #20 becomes true regardless of condition #21.
I’ll try to find some time this evening to write a very simple test piston to demonstrate the incorrect behavior. I think one might also be included in the other thread I linked above… You guys should be able to reproduce this behavior.
If there’s a known bug then why is this even being posted?!? I fail to see why we are even discussing it.
@ryan780, you seem rather committed to just making this go away. You’re certainly free to drop out of the discussion if you so desire. You don’t seem to be adding much.
I think its a similar, or the same bug. It’s not 100% clear to me based on the other thread.
If it is the same bug, it hasn’t been addressed since reported in 02/18, so I was hoping my report would serve as confirmation and would raise the priority. I was also hoping someone else could confirm my experience with it.
Again, I will endeavor to write a simple test piston to definitively demonstrate the bug for anyone willing to set it up and run it.
My question of how a report is escalated to a confirmed bug remains. As does my question of whether this will be addressed at all at some point, or if I should find a different way to do what I need to do.