I keep having a piston not turn off a device, it is great with turning it on never missed a beat but the last four days it has never turned it off. When I notice it I just turn it off in the app. Is there something else I should do. Or is this still because of the recent flakiness of SmartThings.
Seems odd SmartThings is really good at turning things on, but lately it has been very forgetful to turn them off again. I believe this is what it is going to be like to have kids
I will need to look at it. You are the second person claiming this
If you need any datapoints message me. I’ll be happy to help where I can
In addition to my latching pistons not changing to false as expected (even though the actions are executed), I had a time based piston fail to run this morning.
The time event 1 hour ago was supposed to change the level of this light to 40% at 7:16am, and even though the piston shows there was a time event, the light itself didn’t change, and there’s no event history showing for the light.
Screenshot from the app showing time restrictions around the two actions, since they don’t show on the dashboard…
I think I previously saw someone request the ability to have sunrise/sunset offsets in the piston restriction settings. I would second that request.
and I would ‘third’ that the request!!!
also in the ‘action restrictions’
have added as an issue in github so doesn’t get lost in the thread
Where is that dislike button when I need it? LOL
While we’re on the subject… How about switch restrictions for the actions also?
Second that. That’s my favorite automation killer, quick and easy.
And yet, lo and behold, the features appear. Someone must be sneaking code into @ady624 's masterpiece without his knowledge.
Would also say I have seen a number of instances of Pistons turning stuff on fine but the off action not operating perfectly reliably. Occasional but noticed (Sonos staying on after time / light staying on when trigger should have turned it off). Will try to capture some logs
v0.1.139.20160810 - Beta M1 - Implemented “Wait for common time” - waits for sunrise, sunset, noon or midnight on specified days of the week and “Wait for custom time” - waits for custom defined time on specified days of the week
NOTE: There may be an issue when Wait for common/custom time is used after a Wait for state, because the Wait for common/custom time is calculated at the time of execution, with no knowledge of when the state will change in the future. I don’t recommend mixing the two.
Also, this week:
- Implemented Wake On Lan (Wake a LAN device) - if anyone can please confirm it works, I have no WOL devices in the house
- Some speed improvements for the UI
- Implemented offsets for piston and action time restrictions
- Implemented switch on/off action restrictions
Are there any missing features at this time? Would like to move on to Milestone 2 which is mostly about fixing bugs and improving performance and reliability.
Is it still possible to have a function to manually test (force) switch/condition states in order to monitor the operation of the logic?
Not yet. Simulation is not that smart yet.
Thanks for the reply. Keep up the good work man, we all appreciate the hard work and dedication you have put into this… You have brought to life something quite amazing
In a piston, if I have this…
(Trigger A AND condition A)
Do cool stuff
Currently this piston would never be true unless the condition was true first.
Can you make it so we can have, while using groups, triggers and conditions with with the OR?
I don’t understand, cool stuff should happen if trigger b happens, or if trigger A happens while condition A is true, or if any of the two triggers happen while condition B is true. Isn’t this happening?