I know this is something simple but I could use some help with understanding webcore logic and the actions it takes. Something simple I wanted to try was if it’s between 10 mins before sunset and sunrise everyday, turn on a lamp to 10%. This statement alone would appear to only turn the light on to 10% and never turn it off, so is it necessary to code turning the light off or does the hub interpret a simple statement like above to mean otherwise off?
every IF statement has an ELSE statement. adding the off action here would turn it off, too
1 Like
Personally, I don’t like using Else statements, especially when there are only “conditions”, because it limits the possibilities.
Meaning if you turn on the light outside of these time periods it would turn back off.
I prefer “triggers” such as:
If time happens at 10 minutes before sunset
Then turn on
If time happens at 10 minutes after sunrise
Then turn off
This way, I have control of my light at all times. If I so chose to turn on/off outside of the specified time periods, it wouldn’t revert back the rule set in the “Else” strick condition.
Tis is where my error was as I just tested it and you are 100% correct…as usual! 
Doesn’t force the light back off when leaving the light out of the argument. I am now wondering if this is true for everything “else” no pun intended.
1 Like
How would an else get them to turn off at 10 minutes to sunset and off at 10 minutes before sunrise? You would need to have two statements in your pistons, one for on and one for off. This is what I’m doing with my Living Room Light. Now, I’m using custom variables but you can just as easily use the presets in the Time device with the offsets for sunrise and sunset.
My non-math brain has a hard time understanding this principle.
My understanding of this statement is that webCoRE will start to turn on the light at 10 minutes to sunset and continue to send turn-on commands to the light until it stops doing that at 10 minutes before sunrise.
I’ve had bad experiences with webCore “overloading” the hub with statements like IF AT ANY TIME the alarm sensors becomes active, DO … The piston brought my system to a standstill for all practical purposes. Ever since then, I’m always concerned about pistons putting the hub under to much strain because they don’t “go to sleep” until the next trigger arrives. It feels to me as if I should trigger the statement when the time arrives (10 minutes to sunset), let the piston “go to sleep” and use a second command to execute 10 minutes before sunset.
Please, don’t get me wrong, I don’t question your advice. I’m just trying to understand why I should not be concerned to use statements which (in my small mind) “don’t go to sleep but stay awake all the time”.
I’m sure I don’t understand the concept, but would like to know where I go wrong.
Okay, now I’m confused. Would this architecture turn the light off if it was turned on during the day? Also, what would it turn it back on if it was turned off manually at night? The trigger here is not clear to me because “is” isn’t a trigger action like “changes to” or “happens daily at”.
It would not bbe cause the light is not part of the condition, only time. The only times the condition would be evaluated are the start and need times and midnight. At those there times the true or else action would take place.
When you first create a piston with “time is between”, the time end-point events will be scheduled, in @anon36505037’s example, Sunset-10min and and Sunrise-10min. At Sunset-10min, the piston turns on (barring ST problems) the device — ONCE. If the time period spans midnight (as Robin mentioned), the piston, by default, will not try turn on the device again at midnight if it thinks it’s already in the correct state (this can be over-ridden in the piston’s optimization settings.) The piston sends “turn off” to the device ONCE, pass the Sunrise-10min event.
Remember, coRE/webCoRE is event-driven; those events are defined in your conditions for times, devices, etc. Hub “overloading” is probably caused by your devices sending too many events within a given time period that you’re monitoring in the conditions. This was the case for some of my energy monitoring devices … I had to increase the time reporting period for those events.
2 Likes
“is” acts as the trigger if not mixed with … triggers. If your test conditions consists of only “conditions”, they’re the triggers … just make sure you see the lightning bolt to the left of the condition statement.
1 Like
If I may add another twist with this one, is nesting acceptable in webcore? While this light is dimmed I’d like to have a motion sensor crank it up to 100 while activated with maybe a 5 minute buffer before resuming prior state. I haven’t read through the entire command set available but would this run nested in the original if then or would it have to run separately and is there a “prior state” command?
Straight from the Boss’s fingers 
:
“… you can add as many statements (be them IF, FOR, WHILE, TIMER, ACTION, etc) in as many depth levels as you want. Open world. You can have IF after IF, IF inside IF, any combination you can think of.”
1 Like
I would like to know if you are on ST or on Hubitat ? Because I just change from ST to Hubitat and the if stament in ST was only if condition, not trigger and now in hubitat, it seems to act like trigger. So some piston that was ok with ST (event with if statment inside) now have double trigger so I must redesign it… the question is how to simply do condition like if light is on (check if is on now only when piston run) ? Now each time the light changes the piston get to run… it changes a lot of things!
You’ll probably get the most accurate answer if you ask in the hubitat forum, since the two implementations are a little different.
You’ll probably get better help over on community.webcore.co but I don’t think there is anything that fundamentally different between ST and Hubitat implementations in that respect. However as I am here …
What you do see in the Hubitat version is warnings being displayed in your code when you are doing something that might be inadvisable.
Let’s get triggers and conditions out of the way first though. WebCoRE pistons are event handlers so the piston has to subscribe to events (or schedule executions). It chooses which events to subscribe to by looking to see if you have used any trigger conditions in your piston (so things like changes to). If it finds any it will interpret that as meaning you are only interested in running the piston when something happens that might affect those conditions and so it subscribes to device events (or makes schedules) accordingly. If it doesn’t find any triggers it still needs to find something to subscribe to so it considers all the conditions that aren’t classed as triggers (e.g. is) and subscribes to those events instead. This default behaviour can be overridden in the condition settings, but that is basically it, and that is the only fundamental difference between a trigger and a condition.
When an event occurs the piston is run from the top like executing a script. There is no fundamental difference between a trigger and any other condition at this point, they are just conditions to evaluate when they are reached.
Let’s consider Switch1 switch is on. In order to evaluate that the piston first looks to see what the event is that caused the piston to execute. If the event device was Switch1 and the attribute was switch then it will use the value found in the event. If the event says that switch is on then that is the end of the story. It doesn’t matter if the switch isn’t actually on by this time, what the event says goes. If however the piston is running for some other reason the piston will request the current state of the switch attribute from Hubitat. So no real surprises there, though some users don’t realise it checks the event first.
Now let’s consider Switch1 switch changes to on. For this the piston will again check the event that caused the piston to execute. If the event involves the Switch1 device’s switch attribute, then this value will be cached. If it doesn’t then the piston isn’t executing because of a change to the Switch1 switch, and that is what changes concerns itself with. If the event value is on then the value might have changed but it depends on what the previous value was. The previous value used is the one that was cached the last time the condition was executed. It doesn’t matter if the switch has indeed just changed from off to on, if the previous value the piston has for that condition is on that is what counts.
What the above means is that whenever a Switch1 switch event occurs, it is important that the piston reaches the trigger conditions that use it so they can record the value.
Consider:
if time is between sunset and sunrise
and
Switch1 switch changes to on
If the switch is turned off overnight the piston will run but because the time condition is false the result of the and is also false and so (by default) the piston won’t waste its time checking the second condition. That means that the off is not seen and so if the switch turns on in the daytime it doesn’t know it has changed. Similarly if an or condition was used, if the first condition evaluates as true the result is true regardless. So it is generally better to put the changes condition first in any condition group, and don’t have more than one changes condition in an and group.
Similarly if you had:
if Switch2 switch is on
then
if Switch1 switch changes to on
If Switch2 isn’t turned on then when a switch event comes in from Switch1 the trigger condition isn’t evaluated so it can’t cache the on or off value, and then when it is evaluated it can’t calculate whether it has changed or not. So nesting of changes might not be a good idea.
Note that I have used changes in my examples as there is a specific problem. However you should apply the same thought process to any trigger condition as they nearly all work with the current event.
These examples occur so frequently that webCoRE in Hubitat now flags up warnings when it encounters them.
They are only warnings though. In the earlier example it might be that Switch1 simply never gets turned on or off overnight, or is never turned on or off when Switch2 is on. In which case it is your piston and you do what you think is best for you.
3 Likes
Thanks for reply! I know exactly what is trigger and action… The only thing is that inside the piston, when I set a condition, it have ‘condition’ and another section where it have ‘triggers’. I know that if I tell a piston : if the switch is on then do that, it does not matter if the switch itself trigger the event or if the piston run by another way… But why it does not respect that point? So what is the difference between both? They are both trigger and it could cause problem…
But, lets say I want to trigger an event on a presence change and then check if a switch is on then do something. With this, my piston is not working because I have event trigger and inside I have now If as trigger… I want it to just check if the switch is on, I dont want to trigger anything if this switch is changing… So, event are useless for most of the case!
Same thing with this: I set variable from triggering a piston from url with arguments… So the piston get fired and then check if the args match the value, if yes it update the variable to the value… But now, that mean that each time the args changes the piston would trigger? I dont want it to run at that time…
Why automatically trying to force a trigger? If it haves no trigger, it would be my problem to add one and if not it would ever run… I just think about all my pistons that are built in the logic of trigger vs condition and it ll be a mess! If I want my piston to trigger each day at 10 pm… and inside this event I check for some conditions… I only want it to run at 10pm… Now I must remove all conditions and replace it by restrictions and sometimes its complex to do because it have a lot of things…
I just dont understand the logic behind it…why to create 2 section and not respect the meaning…In any coding program, if you add an if statment, it wont trigger anything…you must specify that its a trigger and set it up…If statment at the begining just check a state or condition by reading the code…not triggering anything!
well! A headache is waiting for me! Thanks again! And I never had any problem on ST with this…my piston works so its only in hubitat I think…
Yes that is correct. That is why they have the conditions they call ‘triggers’ that work with the current event instead of the current state of the device. So ‘switch changes to on’ only returns true if the piston is handling the event generated by the switch changing to on. Similarly you will see different events for ‘temperature is greater than’ to ‘temperature rises above’. The latter can only be true if the piston is handling the temperature event.
So you would write something like:
if Phone presence changes to present
and
Switch switch is on
The ‘changes to’ is classed as a trigger so the piston will subscribe to the presence events. It will not subscribe to the switch events as ‘is’ is not classed as a trigger. So only changes to presence will make the piston execute.
Calling a piston from a URL causes webCoRE to generate an internal event that makes the piston execute. There is no reason why it should run at another time unless perhaps you use a global variable as pistons will run when global variables are in conditions.
If you use a condition classed as a trigger like ‘if time happens at 10pm’ the piston will schedule an execution for 10pm. It will run at any other times unless there are any other trigger conditions.
Triggers are webCoRE’s way of having you explicitly choose when the piston is executed. A piston that doesn’t subscribe to events or schedule times isn’t going to do anything unless it is executed by URLs or something, so webCoRE takes the sensible decision to create some default subscriptions and times if you haven’t explicitly created any. If you don’t want them just turn them off. You just go into the condition settings and choose whether it should subscribe automatically, always or never. The default is automatic but if automatic doesn’t give you the right results you can override it.
I still don’t understand how ST and Hubitat can be behaving differently in these respects. Most of the code is the same.
OK, I will ask the obvious question: brand and model of the lights? Because one thing the two platforms do handle differently is polling of devices that don’t report their state. And in particular older GE zwave switches can act differently on the two platforms when used in automations.
Ok, I just see by making test that its the same from both sides or almost… Its a question of subscription and it could be set at any statment so it would be ok! The things that make me panicate is that in hubitat, with my event and if condition embeded, it gave me an error directly in the pistons (or a warning)… but in ST I had nothing and was running ok…so I tought that the rules were different but after testing a lot it sounds good… I ll finish transfering my pistons and fine tune and if any issue I ll check from there!
Thanks a lot for support and sorry for this false alert! 
1 Like