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
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.
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.
“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.
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.”