I think that works .
Conditions and Triggers: The difference?
I’m still a bit confused about 2 things:
1)WHAT is a trigger?
2)WHAT is a condition?
OK so a condition is just the state of something, where a trigger is an action to something.
Heres goes my noob question.
I have 2 motion sensors and a single dimmer. My desired logic is for the light to turn On when any of the sensors is active… so that’s easy since its and OR the piston executes when either sensor activates as expected.
Problem comes when motion stops. I want the light to turn Off when there no movement on BOTH sensors. Instinct tells me to do the same as the On part but using AND instead of OR… but from what I’ve read here that won’t work.
How can I make the light turn off when both sensors are deactivated (no motion).
Instead of making two different conditions, select both motion sensors and then you can choose ALL or ANY. So for turning them on you would select ANY. For the part turning them off you would select ALL.
Ok ok… so no matter how many devices are selected it still counts as a single condition?
Just tried but it doesn’t work. Can I PM you or is it OK to paste my current code on this thread?
Great thread guys! I have a couple of questions to better understand the piston building process:
-
Does the order matter within a piston of the trigger and conditions to make a piston work correctly? It would seem as though triggers should always come first in a piston or does it matter, both in the piston actually working properly and for overall efficiency?
-
Very curious when folks keep talking about efficiency in pistons, what are they really speaking of? Is it efficiency that I, the user, will actually see in terms of lights turning on faster when events trigger, or just general stuff in my part of the WebCore world happening faster for me - or are we speaking in terms of server efficiency in the background, but not necessarily stuff I can ‘see’? (i.e. more efficient pistons from everyone x1000’s of users will help reduce the overall server requirements of the system) ?
thank you. having seen many questions around this, thought i would put this up right up front when the new forum was created.
while generally triggers should be listed first in a condition and that usually works more efficiently, its not always necessary to do so and sometimes it can actually be less efficient to do so. like when you have chatty triggers and you want to limit execution by another condition combined with the trigger. like in this example, over a 24 hour period its actually more efficient to have the time condition first followed by the motion changes to condition:
if motion changes to active
and
time is between sunset and 11pm
do something
end if
i keep talking about efficiency, dont i? its certainly one my pet topics. when i am talking about efficiency in these forums its usually about users seeing their pistons work more efficiently without semaphore waits which can cause piston actions to be delayed seemingly unpredictably.
I am so glad you brought up semaphores @bangali ! I am not a programmer but have a masters degree in Tinkering so love playing with WebCore and its awesome capabilities. I have the below piston which simply looks to see if my skylight blinds have been lowered ( works on a momentary switch within Smarthings). If they have been lowered earlier in the day it simply then activates the blinds up momentary switch (not the same switch as the blinds down switch) 2.5 hours before sunset.
The problem is that every three to four days it does not activate the blinds up. What I have found is that the days it does not activate are the days that the ‘piston waited for a semaphore…’ statement is in the logs (see above circled in red) .
What can I do to make this piston more efficient and avoid this semaphore issue which causes the piston not to run every 3-4 days?
sure … though in this case the 1/4 second semaphore wait should not be causing this issue.
if you still wanted to make it slightly more efficient, please change to a timer statement:
every day at 150 minutes before sunset but only in may, june, july, august, september
if lower kitchen blinds switch changed in the last 12 hours
with raise kitchen blinds toggle
end if
end every
@Levahj if you do try this, it will be interesting to hear if this solves the problem of piston not activating every 3 to 4 days. please update if possible. thanks!
I will give it a shot with the new piston and let you know within the next week if there have been any issues with it not activating. If you don’t think the semaphore wait is long enough to affect the piston, could there be a bug in WebCore? Just wondering why this sporadic semaphore is popping up every few days and sporadically with no correlation to anything I can see…
great, thank you. both of the if clauses are conditions so they are both acting as triggers. so, when the lower kitchen blinds switch changes the piston is getting evaluated. at around 1:27pm the switch may have changed quickly a couple of times so the second event from that change waited for a little bit before the piston could process it.
if you switch to the every format, this at least will not happen any more. after you build the new piston, if you still see the bolt against this line then edit the piston, click that line and change the subscription to never.
EDIT: i verified it, that you wont need to do that last part.
You are absolutely correct. Since the switch is a toggle it does change twice every morning. Once on and once off within .5 seconds so that is probably why the Semaphore takes place? Though it is strange it is not consistent.
Just so I understand this…
‘Changes’ is a Trigger
’Changed’ is a Condition
Would either ‘Changes’ or ‘Changed’ work in this case where a timer is used? Or is ‘Changed’, since it is a condition, the better solution since the timer defaults as the Trigger in this example?