Good eye! I usually use TWO variables to circumvent this, because I hate to have a vague trigger.
For example:
IF {@darkinside} changes to true
IF Time is after 3
Then Turn on Hallway
Else Set variable delayTrigger = true
END IF
END IF
IF {@darkinside} changes to false
Then Set variable delayTrigger = false
END IF
Every day at 3pm
IF delayTrigger = true
Then Turn on Hallway
End Everyā¦and one more for you
I only want the piston to fire successfully once
Or else every time I turn off my lights, they will trigger back on and that makes an angry wife
The piston in my last post does this. It only fires once when @darkinside first changes to true, and potentially one other time in the entire day. (currently set as 3pm)
In other words, if you manually turn off the hallway, it will remain off until either 3pm (if @darkinside = true) or the next time it goes false and then back to true again.
Actually, here is an improvement on my last piston using only the one variable:
IF {@darkinside} changes to true (Ļ trigger)
IF Time is after 3 (condition)
Then Turn on Hallway
END IF
END IF
Every day at 3pm (Ļ trigger)
IF {@darkinside} is true (condition)
Then Turn on Hallway
END IF
End Every
This resolves the āchanges to true before 3pmā issue you mentioned earlier
I will add those tonight to my piston and post the next version
Thank you again for your help
Learned a lot about Webcore today
OK,
Here is my next iteration. I need to move things around so they make sense when looking at it
but I have taken your suggestion, two ifās (for the trigger) two whiles to catch the trigger later
One extra IF to turn off the hallway lights if the weather clears and made an attempt at my motion trigger again
How does it look ?
Your last image was cut off at line 149, but from what I can see, it looks real good!
If you are looking to streamline a bit, you could combine your first 2 major blocks into one, since the trigger and conditions are identical.
Further down, you also have two identical blocks that can be combined:
Those two changes are likely not mandatory, it just keeps the flow a bit better code wise.
Perhaps the only other changes I would make are towards the bottom:
This section might run as it is, but I try to avoid triple nested IF when possible.
I would probably add a condition directly below "{@dark_inside} is true" to account for the time. Such as:
IF
Motion changes to active (Ļ trigger)
Then
IF
{@dark_inside} is true (condition)
and
Time is between X and Y (condition)
Then
Turn on Hallway
END IF
END IFOK
Optimized version with your feedback attached and adjusted for the evening when it isnāt dark inside
Thank you and thank you and everyone else who posted for your help
Now to take what Iāve learned and clean up all my other Pistons !
Hi!
Iām working on something similar to this. If i understand correctly from what Iāve read so far, you use inputs from weather, like cloudy, partly cloudy, fog etc. to simulate the light conditions.
I was thinking the same, but I donāt know how to code this to make the two booleans change.
Thanks in advance.
I gave up on using weather conditions to trigger the changes. I found it a bit too complex.
I ended up with the Lux value as recommended and it is just easier to deal with (IMO)
I see. Is it possible to collect/simulate the lux level without a weather station or illuminance sensor?
I use the built in query to WUnderground, along with Accu-Weatherās plugin for webCoRE, like this:
Both return a number from 0-100. Neither is perfect, but together, they are fairly reliable for determining when there are a bunch of clouds in your zip code, and the sky is likely darker than normal.
The AccuWeather plugin actually acts like a local device.
You can test this by loading the ST app on your phone, and going to:
Market Place > Smart Apps > Climate Control > AccuWeather Connect
Found this postāand my own comment aboveāafter searching for a way to tell if itās dark outside. It turns out that Weather Underground may not be available after 12/31/2018. Theyāre eliminating free access to their API, and Iām guessing that will break any $weather calls from webCoRE. 
This is going to break my āIs It Dark?ā piston I posted above (post #18). I created it because the sunset offset would either turn the lights on too early when itās lighter out or too late when itās cloudy. Using illuminance really is the right thing to useā¦ and itās been great for me. It turns stuff on when it gets dark, no matter what time that is.
The good news is that I used @dark_outside and @dark_inside global variables, so if we can figure out another way to measure illuminance (or simulate it), we can replace the āIs it dark?ā piston with something else that sets those variables and everything can continue to run just fine.
I wanted to revive this thread as like @Equis had mentioned.
With the API going in 15 days, I was thinking of parsing non standard weather to influence dark_outside and dark_inside
There were some earlier suggestions in this thread but it is a bit of a mish-mash.
Even if we have to use IFTTT to get variables, that are basically not sunny and not daytime, that would work
Does anyone have any suggestions that could replicate the Lux values we are losing?
The last I heard is:
SmartThings has a deal (contract) with WUndergroundā¦
but I donāt know the financial details, nor the renewal date.
(I sure wish more info was made public)
That would be nice to keep it.
I would look at using AccuWeather and if cloudy = dark inside, etc but they donāt support Canadian postal codes in the Smartthings app.
