Piston to control all automated house lights

#1

I wanted to create a piston for automating all of the lights in my house. But I wanted something that could be run at any time of day and it will set the lights to their proper settings. I also wanted something easy to modify and understand. Many of my smart bulbs are OSRAM Lightify bulbs, when they lose power, they default back on to 100% brightness and 2700k white temp. And at least a couple times a week…a light switch gets flipped and messes up those bulbs. So I wanted something that could not only automate the bulbs, but also restore them to where they should be based on time of day.

The “wait” functions are there to ensure that Webcore has plenty of time to set the value of the variables and doesn’t run into any race conditions. Some have pointed out to me that setting the same variable multiple times in quick succession could cause issues. Since I don’t care how long this piston takes to run, the wait times seemed like a good solution.

Here’s what I came up with.

download
download.png1178×3146 389 KB

#2

Please use the green photo button instead of the red DO NOT SHARE button.

#3

What is the security risk in sharing the red screenshot? There is nothing personally identifiable in this piston? And how would it have improved the security of this particular piston?

#4

It’s not the security risk alone. The green gives a code in it, so that anyone can import it and try your piston for their own use. Just need to update on their end accordingly.

#5

Okay, I get that part with the code. But what is the security risk?

#6

Some pistons, not yours in this insnstance will include websites and login information and api keys. If you use the red it won’t block that info. The green will change the website to webcore.co. I believe. Also will include device names and phone numbers if entered.

#7

I’m aware of all of that. That’s why I was asking why it is such a big deal to share the red screenshot for this particular piston. If I were using webhooks, API calls, or any personal items, I wouldn’t use the red screenshot. But for this particular piston, I felt the red screenshot was more readable. And it made no difference since it doesn’t change variable names.

#8

For one it says in a big red banner across the top and bottom “DO NOT SHARE”

At one point there was a way to go in and mess with your pistons when a red image was shared. Because people could not stop sharing this Adrian took care of this problem and added backend measures to not allow someone to overwrite your backups.

As already mentioned by @Gopack2 the green one is meant for sharing and has an import code. So if you intent is to show off and share your piston, stick to the green one so others can import it.

#9

Thanks for sharing this. I am new to webcore and trying to learn from these examples. I used core before but my usage was very basic. Instead of combining all of the different times and triggers like have been done here, I would make a separate piston for each mostly because I didn’t bother to try to learn variables. What are benefits in making one glorious piston to control all of the lights besides having less pistons and not having to retype some of the same information over and over?

#10

Benefit.
Less pistons to sort through to find what you need tobmodify. Naming conventions can be a challenge with a lot of pistons

Drawback.
Sifting through a mega piston can be maddening looking for one small thing you need to change. Make sure you comment the chunks as you write them. You’ll thank me later

#11

@Mr_Terrycrews any relation to the bad ass actor? :sunglasses:

#12

No relation lol although I have had delivery drivers show up with hopes to see him and were greatly disappointed. Also when Instagram was released to android I made an account with my name. I quit using it because no one I knew was on it seeing it was so new. About a year later someone asked me if I still used it and how did I get so many followers… I had to change my name on there :grin:

One question, I am studying now how to combine all of my lights into one piston like it is here but my wife teaches school and I want to be able to pause the lights turning on in the morning when she is out for the summer or on break. I guess I should leave the bedroom lights out or is there a way to do this other than remembering to go in and change the dates every time to exclude those breaks?

#13

Why can’t you just base it off of a presence sensor? if she’s home, don’t turn on the lights? I’m guessing you thought of this possibly, and I’m just lacking some details.

#14

I have the lights come on in the morning as part of her morning alarm during the school year and I would not want them to come on in the morning when she on a break so she will be present both ways.

#15

Agreed, but I haven’t found it to be much of a drawback yet. For the most part, the only part that needs to be modified is where you put the variables in the different sections, which is fairly easy. I picked up a couple more ST plug in outlets, and I added one to the bathroom. It was pretty quick and easy to add a variable for the switch, add a trigger for her presence sensor, and add an action to set it’s value based on the variable. That’s all you need to do to add a new device.

As for moving a device…you can either drag and drop the devices variable to another group, or create a new group. Then done.

#16

I see. Do you just have it synced up by time for her alarm? Or is it actually linked to her alarm? Like when the alarm goes off it triggers the lights?

I guess if it’s just by time and not actually linked, you would just have to put a date condition on those lights. Like “If date is between X and Y then turn the lights on”

Maybe just pick up an Alexa and use IFTTT to link up the Alexa alarm to SmartThings hahaha.

#17

So maybe you could add a condition based on a virtual switch that you could turn on or off manually based on her schedule?

#18

That’s brilliant! I have not thought of that thank you. And yes it is just set to a timer.

#19

Just thought i would note…the reason why I chose to shove this all into a single piston is because it gives better visibility of my entire schedule. This piston consists only of presence or time based triggers…no device based triggers (motion, contact, etc). Those all go into their own pistons.

If this one were broken into separate pistons, there would be a TON of duplicated items…
For example, I could break this piston up by the triggers, or by the devices…

By Device:
Each device would have it’s own piston, with each of the triggers it’s associated with. But the draw backs are, if I want to change one of the trigger times…say I want to change Sunset+30min to Sunset+15min for whatever reason…I would have to go into every piston that has a Sunset+30min trigger and make that adjustment.

By Trigger:
Each trigger would have it’s own piston, with each of the devices it’s associated with. But the draw backs are, if I want to change the times that a device is controlled…I would have to go to every piston that device exists in, and move it to other pistons with the triggers I want. If the piston with that trigger doesn’t exist, I’d have to create it.

My Solution:
If you want to change the time a device is to be controlled…drag and drop it into the correct section. If it doesn’t exist, add a new condition statement and matching trigger. If you want to change the time of one of the triggers, then you only have to change it in two places.

Using the variables throughout the piston solves the issue of a bunch of commands for on and off being sent while it’s running, and it eliminates having to use the “between” time condition. This way the piston can be run any time of day and it just works great.

#21

Just adding a comment as I’ve made some changes to the piston and thought I would bump it. This piston has been running for over 2 years and I have had literally zero issues with it. It works every time I need it. I call it all the time to repair lights when they get out of sync due to physically turning off the light switch.

The only thing I may add is to detect when there’s been a power outage and to restore the lights to their original state prior to the power outage. However, I think this could be done in a separate piston as I don’t think there is anything that needs to be inherited from this one. Perhaps the new piston will wait a while for the bulbs to reconnect and then run this piston? Not sure yet.