Piston Chunk Triggers as if it's a Condition

#1

Hello,

I’ve been on Webcore for several years between ST and HE. On HE Webcore, I have a chunk in a piston that shouldn’t fire unless only the conditions in the chunk are met but it’s behaving like a condition and triggering when other chunks in the piston fire. This is the only chunk that I have that does this and I QUADRUPLE verified that the comparison operator I’m using is under triggers not conditions.

To resolve this, historically, I just put the chunk in it’s own isolated piston and that seems to work, but as soon as I combine it with any other piston (like I did here, I get the conditional behavior). I’m just trying to put all my notifications in one place and this chunk is making that difficult.

Can somebody please review this to see if I’m doing something wrong or if there’s a bug with the way this “trigger” is being used as a condition?

As you can imagine, because the preceding chunk of the piston runs at 12:00 PM daily, you guessed it, my washer cycle is miraculously complete every day at that same time. I have placed this chunk in a bunch of different pistons and I’ll get a washer alert whenever any other chunks trigger in the piston.

I know at the end of the day, the workaround is just to keep it in an isolated piston, but I’d still like to understand if I’m doing something wrong or maybe I don’t have a firm concept of triggers vs conditions but I don’t feel like I would’ve made it this far in webcore if I didn’t understand that.

2021-10-11%2013_10_38-webCoRE%20Dashboard
2021-10-11 13_10_38-webCoRE Dashboard.png1215×788 57.8 KB
Notification%20Piston
Notification Piston.png1178×1480 186 KB

#2

Line 68 down always triggers at 12PM? Maybe a log of that part of the piston would help people find the bug.

#3

I’m taking a stab in the dark here. This is the way I read this. When your piston fires at 12:00 PM, unless the washer (Switch 202) has been running within the last 2 minutes (ie, power is not and has not been zero(0)), then it has been zero(0) watts for an unknown time (probably greater than 2 minutes) and will execute because it IS and HAS BEEN zero(0) for at least 2 minutes. Time happens daily will run the piston top to bottom, and will execute anything that is not blocked by a condition.

#4

Well, its triggering at 12 pm simply because the preceding chunk is triggering at 12pm. It doesn’t matter what the preceding chunk is, whenenver it triggers, it causes this one to fire like its a condition even though they’re completely unrelated.

A long time ago i had it in a piston with a siren triggered notification. Every time the siren would trigger, it would say “yes the power of washing machine has been equal to or less than 0 for 2 mins” and then fire. Which to me appears to be behaving like a condition.

Do you think a log would still help given these observations?

#5

I think I see where you’re going with this and that makes sense. Let me try to define it a little more narrowly.

#6

Based on your feedback, I inserted a line that will actually achieve two things.

  1. Hopefully it will stop the washer false notifications. The exectution wasn’t my most elegant but I think it will help stop 99% of false notifications.
  2. It creates a solution to a tangential problem that I was going to try to automate: if washer closed (but hasn’t been running), send notification because there’s one member of my house that will close the washer door after every use (which makes it smell bad).

The solution was so simple, I just needed another set of eyes :grinning:. Thanks!

download
download.png1178×1529 317 KB

#7

I’m a bit worried you may not have the firm concept of conditions and triggers.

The only real significance of a trigger is that the piston will default to only subscribing to the device events, or scheduling the timer events, that are used in triggers. That’s it.

Once the piston starts executing, triggers and conditions are just comparisons. There aren’t any ‘chunks’ as such. With certain exceptions (e.g. every blocks), pistons start at the top and run like a script, evaluating conditions and triggers as they are encountered.

The comparisons in triggers are based on the event data. So e.g. Door contact changes ... can only ever be true if the event being processed by the piston is for the Door contact.

The comparisons in conditions are generally based on the device objects in ST/Hubitat though they will check the event data first. So e.g. Door contact is closed will first look to see if the current event is for the Door contact and use whatever value it finds there, even if the event has been delayed and the actual value has changed . Otherwise it looks up the current value that ST/Hubitat has.

Your particular issue is that you were using stays. That is a special case. It is classed as a trigger but it is a ‘timed trigger’. When the piston evaluates Door contact stays open for 1 minute it will actually evaluate like Door contact is open. If that is true it will set a timer for 1 minute’s time and then return false and continue with the piston. If the door stays open then in one minute the piston will wake up and act like it has returned true for the condition.

#8

You’re right, I thought a trigger further down was it’s own thing regardless of what was above it and would only fire when THAT triggers conditions were met. So much more makes sense now.

I guess I’ve never run into this problem in 4+ years of webcore because everything I had was so simple and was uniquely timeblocked (so I never noticed).

I really appreciate the clarity on the behavior of stays being a timed trigger and this also explains an issue I had with another piston.

#9

A great thing about webCoRE is that it somehow manages to do what people want it to most of the time, even when it doesn’t actually work how they think it does.