Thanks. However when I tried that, there was no count down timer (counting down from 3 minutes) and the lights never turned off no matter how long it when without any motion. I did solve this with what Darrell posted below.
Thank you Darell - this works perfectly! I wonder if webCoRE added some additional events/conditions/triggers compared to CoRE, because as far as I know, there’s no way to do this directly in CoRE like you did (instead it required a Wait event which was cancelled each time there was motion). In any event this works great and seems real efficient.
It would be cool if webCoRE provided “subroutine”-like functionality. For a global generic function like this that took a few parameters such as a list of motion devices and a time out and the name of a switch and then did this without the code. Not a big deal but it would make things even more powerful if people could do more with less coding required.
I had the same functionality in CoRE using a latching piston. As you said, it used a wait statement that got canceled on the piston toggling.
Right - that’s exactly how I did it using CoRE. It seems your new approach (particularly related to turning the lights off) is more intuitive and straight-forward (the CoRE approach feels a bit kludgy). So I was just wondering what’s new / more powerful in webCoRE that makes it possible to use a cleaner approach like what you have now.
Can someone please explain in some detail what the differences are between “conditions” and “triggers” in conditional statements? I’m finding it challenging to understand the difference between some of the options and how they are (perhaps subtly) different.
For instance, the difference between:
Door Sensor contact CHANGES TO Open
versus
Door Sensor contact IS Open
In a situation where you want to take an action each time the door is opened, is there any difference there?
Also what’s the difference between ARE and WERE? WERE means the previous state that it was in before it was in the new state? In the case of a switch where it is on/off it seems like this would not be needed. But perhaps there are devices with more than two states?
Thanks!
Think of triggers as events…instant moments in time. “Changes to” is an event, happens in an instant when something is, say, open, then changes to closed.
A trigger is not persistent…a door doesn’t change from open to closed over an extended period of time. It is open, then it changes to closed (at an instant moment in time), then it is closed.
Think of conditions as states…something is open or is closed. This is a persistent state, it can be that way for an extended period of time.
When applying this information to build pistons, you need to understand what causes a piston to execute. This is where subscriptions come into play. By default, a piston will subscribe to conditions as long as there are no triggers. If a trigger is added, the piston will then subscribe to the trigger and unsubscribe from the conditions.
Let’s take a simple example, where you want a light to come on when someone opens a door. In this simple case, you could use either a condition or trigger. A condition would look like this:
If
Your Door's contact is open
Then
Turn on a lightHere, the piston will subscribe to Your Door’s contact, which means that the piston will execute any time an event happens that involves the door contact. The exact same thing will happen if you use a trigger as follows:
If
Your Door's contact changes to open
Then
Turn on a lightNow let’s add in a time component. Say you want the light to come on only between sunset and sunrise. So the question becomes…how do you want it to work? There are options here:
If
Your Door's contact is open
and
Time is between sunset and sunrise
Then
Turn on a lightIn this case, both time and the door are conditions, so the piston will subscribe to both. Since both will cause the piston to execute, this means that the light will come on if the door is opened after sunset, but it will also come on if the door was already open and time passed the sunset mark. Compare that to:
If
Your Door's contact changes to open
and
Time is between sunset and sunrise
Then
Turn on a lightThis piston would behave a little bit differently. Here, the door contact is a trigger and time is a condition, so only the door contact would get a subscription. Time, in this case, becomes a restriction. If the door was opened after sunset, the light would come on same as the previous example, but if the door was already open when the sunset mark passed, the light would not come on, since time does not cause the piston to execute. Since time is a restriction, this could be re-written as follows, with the exact same behaviour:
If
Your Door's contact changes to open
Then
Only when time is between sunset and sunrise
Turn on a lightThere’s a lot more that could be added about this (like how conditions and triggers affect the If/Else relationship, waits, task execution/cancellation policy, etc), but hopefully that covers the very basics
13 Likes
So I’ve seen recently some people are creating SHM functionality in WebCoRE. I’m curious why people are doing that? What benefit does controlling SHM from WebCoRE compared to native SHM in ST?
What is SHM?
Great explanation, I have asked similar questions in the past and have been given “the” answer but without explanation. And I have read the CoRE wiki - many times. But I often see that a person who creates a thing often describes the thing differently than outsiders understand. The authors will say “it’s right there” and no doubt the words ARE there, but the layman can read the words and not gain the understanding. I really do appreciate folks who take the time to ensure the understanding is gained. 
3 Likes
Smart Home Monitoring - the built-in alarm system.
Interesting question and I’m curious to see what people have to say about it. I was going to use webCoRE for my water leak sensors I just got, but a friend pointed out that if I use SHM then I am not dependent on the cloud being up and available to get warnings. Not sure if that’s indeed the case. If so then I suppose that can be an advantage to using SHM for more critical functions. Tho certainly webCoRE is a lot more flexible so I’d probably use both.
I think webCoRE can add some built-in routines and functions to do some things better than ST natively does. For instance ST doesn’t proactively send you warning notifications on low battery conditions (only marks devices that way in the app). So with others help here I made this in webCoRE. But it would be cool if webCoRE had a bunch of built-in common monitoring functions that we can just enable - for instance a battery monitor so folks don’t have to roll their own or find community code. But rather they could just check off a predefined list of functionality and then put in the battery threshold and how they want to be notified. That is of course just one example.
1 Like
Seems like a lot of us are in MIS/IT/Data related fields, either by hobby or professionally, so these concepts are second nature. It’s challenging sometimes to step back and think about things from the perspective of someone who hasn’t had much experience with this type of logic. It can be overwhelming, especially when there’s no “best” way to do something. WebCoRE is so flexible that multiple people can use multiple ways to accomplish the same thing, and I think that becomes confusing to beginners at some point. There’s a pretty good chance of getting different answers to the same question, all of which may be correct.
1 Like
The bolded lines with the nulls look strange. Do you have any empty conditions or statements or anything when you go in to edit the piston? Not sure if that means anything, but something looks off to me. Any input on the nulls @ady624?
is there any downside to using exit task within a series of ifs / else ifs blocks of triggers and conditions when i know none of the subsequent ifs will evaluate to true if the current if evaluated to true?
Thanks!
is “set level” without first “turn on” working again? This went away in a WebCoRE version a few days ago such that you had to issue “turn on” before “set level x”, but it appears to be working again… perhaps.
Actually the test I just did sends Set level 0 to a switch that is on. This seems to also turn off the switch. Is that a return to the old behavior?
Certain commands have been tweaked to still be sent if certain conditions are met (ie set level > 0, but switch is off, regardless of current level). Others no longer support command optimizations (setHue, setColor, setSaturation, setColorTemperature)
1 Like
any way of seeing what events a piston is subscribed to?
Thanks!
Look for the orange bolts on the gutter?!
Thanks Chris for the great explanation. I often am concerned that a trigger or command would be missed due to a freak network glitch or ST outage, which is why I tend to prefer using conditions. I wonder if this even makes sense?
For instance, when a humidity sensor says the level is >= 45% I want to turn on the dehumidifier. I could do this with a Trigger by saying if that RISES ABOVE 44%, or I could do it with a condition by saying GREATER THAN OR EQUAL TO 45%. Seems that both would do the same thing in this case. However if I am thinking about it correctly, if I used RISES ABOVE and it crossed the threshold but somehow it failed to run or its command to flip the switch for the dehumidifier got missed by ST, then the humidity in the room would go up and up and it would not try to turn the dehumidifier switch on again. Whereas with GT OR EQUAL TO the next time the humidity went up another percentage point the statement would be true and it would again try to send the signal to turn the switch on. Sort of acting as a built-in backup. Is this a correct way of looking at it?
Hi guys - I have the following piston I just wrote that is designed to turn the dehumidifier on if the humidity is >= 45% and turn it off if it is <= 42%.
So the flow is like this:
Dehumidifier is off.
Humidity is 43% and rises 1% every few minutes.
Humidity rises to 45%, the command to turn on the dehumidifier switch will be run (in the spot where it just writes out the “turning on” message)
Humidifier runs and the humidity drops 1% every few minutes
Humidity drops to 42% and the command to turn off the dehumidifier switch will be run (in the spot where it just writes out the “turning off” message).
Rinse and repeat.
A few questions please:
-
Does this look like it is properly written? Any enhancements to consider?
-
Because of command optimization, am I correct to assume that I do not need to add a “AND dehumidifier switch is OFF” to the part that checks for turning on the switch and don’t need to add a “AND dehumidifier switch is ON” to the part that turns the switch off?
-
In my output I want to put how long the previous state was. For instance I want it to say “Turning dehumidifer ON. It had been off for x minutes/hours/days/weeks.” Where X is the time that’s elapsed since the last time the piston turned the switch off. Likewise I want it to say “Turning dehumidifier OFF. It had just been running for X minutes.” where X in this case is the elapsed time since this piston last turned the dehumidifier on. What’s the best way to do this? Part of me thinks it requires storing local or global variables, but part of me also thinks there may be built-in system / various variables I can tap into to determine these timings without tracking it myself?
Thanks!