Conditions and Triggers: The difference?

difference
faq
conditions
triggers
#5

This is really helpful. Thanks.

#6

What I have noticed is if you have a piston with, say 4 IFS and ELSES i.e.
IF
blah blah
THEN
blah blah
ELSE
Blah blah

IF
blah blah
THEN
blah blah
ELSE
Blah blah

4 times.
Let’s say the top 2 IFS are conditions and the bottom 2 are triggers, then only the bottom 2 subscribe.
I would have thought that they would all subscribe as they are in their own exclusive IF statement.
I fully understand that mixing the 2 types in an IF can be ‘iffy’ (pun intended) but not in exclusive ‘ifs’.
Any thoughts?

#7

this one might be better answered by @ady624 because it goes to the thought process behind how webcore is designed. i will take a crack at how i perceived this as i got started with webcore … I am sure @ady624 will jump in if he wants to add anything.

its about understanding user intent when they are coding a piston. say the default behavior was:

  1. if in a IF clause there are both conditions and triggers, only the triggers are subscribed to for that IF clause.
    AND
  2. if in a IF clause there are only conditions, all the conditions are subscribed.

now, on a per IF basis the user will need to evaluate as they code the piston, if this IF is subscribed to any events. if you consider that this evaluation by the user would not only be for IFs but anywhere conditions are allowed like WHILE or DO … WHILE etc, it can get it a little overwhelming for users who are just getting started and not yet familiar with webcore logic. i know it did for me. :slight_smile:

to get started its much simpler for user to get started with:

  1. if you have all conditions in a piston all conditions will be subscribed to
    or
  2. if you have any triggers in a piston only the triggers will be subscribed to and not the conditions

once users get started and are used to webcore … they also find out how to override this default behavior and force a condition to subscribe even when there are triggers in a piston or force a trigger to not subscribe even when there are one or more triggers in that piston.

#8

Thanks for the reply.
I fully understand the conditions and triggers subscription process and when I mix the two in an IF I always put my trigger first. These then seems to subscribe the conditions that follow. But to be safe I change them to 'always subscribe.
I just assumed that in the scenario I quoted above, there wouldn’t an issue.
I think this now leads me to another question/request which is to be able to change the ‘preset’ defaults. That’s for another thread though. :smile:

#9

sure. right, its more about users that are just getting started. :slight_smile:

#11

Nice job @bangali!

Checking if two conditions stayed the same for a period of time
#12

thank you.

#13

There is also this snippet of information from @ady624 that you may find useful for additional clarification.
_____________________________________
A piston is usually executed on events that trigger it. Therefore, triggers - by definition - will always run pistons. In the event no trigger is present, conditions then fulfill that role by acting as triggers themselves (all the conditions in the piston do that when no triggers are present). The moment a trigger exists, conditions step down and act as just that, conditions (or restrictions, if you want), therefore not triggering pistons themselves.

Only conditions >>> all conditions act as triggers and they all subscribe to events
Mixed conditions and triggers >>> only the triggers subscribe to events
Only triggers >>> only the triggers subscribe to events

There is, of course, the manual modification of this behaviour, by forcing a condition or trigger to either subscribe regardless, or never subscribe. Those settings take priority over the logic described above.

Piston reading stale door sensor value when triggered by a timer?
#14

Very nice write up and good info.

Idea for enhancements

  1. Use an icon or other visual to mark triggers and conditions.
  2. Warning if you have triggers in a piston but have a if statement contained therein that has only conditions or other dead end builds.

BRB going to review all of my pistons.

#15

thank you.

this is sort of there on the piston view page. the lightning bolt to the left of the condition will tell you if its subscribed to an event. but yes, does not show in edit mode.

well you could legitimately have if conditions where it does not involve any triggers, even though the piston got fired by receiving an event from another if condition which has triggers. :slight_smile:

#16

Brilliant thread.

#17

An important point … It’s worth noting that you can have more than one trigger in your IF though if you are using OR instead of AND. Of course the same holds true that you still will not have more than one trigger that is TRUE but you can put more than one trigger in the same IF.

#18

thank you. funny that even as you were quoting that para i was also slightly modifying it. still keep it simple for new users without infringing on technical correctness. :slight_smile:

let me know what you think of this new version of the para. keep it or revert back?

EDIT: edited the para slightly.

A piston for the morning is failing by going off at night
#19

I think that works :+1:.

#20

sorry, but would you please review one more time? edited slightly :slight_smile:

#21

No worries. I saw the update. All good in my opinion.

#22

thanks @Nezmo. it stays then :slight_smile:

#23

I’m still a bit confused about 2 things:

1)WHAT is a trigger?
2)WHAT is a condition?

#24

when editing a condition, the kind of comparison defines if it is a condition or trigger.

image
image.png1512×1978 215 KB

Piston reading stale door sensor value when triggered by a timer?
#25

OK so a condition is just the state of something, where a trigger is an action to something.