Mode-Based Lighting

lights
variables
motion
#1

Here’s a set of Pistons that I use to control my house lighting by Mode. Each room has individual settings for the lights (color, temperature, and/or level) and for the non-motion off times. There are 4 Pistons:

#1: Variables - RGBW Light Settings
The first Piston is triggered by a change of the locationMode. It sets the light settings variables for the each of the Rooms and then checks to see if any lights are on. If a Room’s lights are on, then it calls that Room’s Action Piston (see Piston #4 below) to adjust the lights in that room.

Variables%20-%20RGBW%20Light%20Settings
Variables - RGBW Light Settings.jpg1178×2302 423 KB

#2: Variables - offTimes
The second Piston is also triggered by a change of the locationMode. It sets the offTime variable for each of the Rooms. This one also sends a notification to ST containing the offTimes for the mode and adjusts the Piston state to show those as well.

Variables%20-%20offTimes
Variables - offTimes.jpg1178×2048 421 KB

#3: Room Light Rules
The third Piston is an example of my Room Rules Piston. Each room has its own set of rules by which the lights come on/off (motion, door opening/closing, presence, etc.), so I use one for each room.

The 1st If block - Rules to turn lights on

  • There are 3 restrictions: 1) is @home true? - This checks whether anyone is home (via a global boolean variable that is toggled by another Piston for presence); 2) is Room_Override switch off? - I have an override switch that can be turned on or off manually via Alexa; and 3) has it been more than 5 seconds since last call to Piston? - This prevents duplicate calls.
  • It checks if a) the room’s lights are off and b) if the room’s motion sensor(s) detects motion or the room’s door(s) opens. If so, then it calls the Room’s Action Piston (#4 below), and it sends a notification/changes Piston state showing why it did so and when.

The 2nd If block - Rules to turn lights off

  • It has 1 restriction: is Room_Override switch off?
  • It checks if a) the room’s lights are on and b) the room’s motion sensor(s) detects no motion for the time set in the room’s offTime global variable (set above in Piston #2). If so, then it turns off the room’s lights, and it sends a notification/changes Piston state showing why it did so and when.

Room%20Light%20Rules
Room Light Rules.jpg1178×1470 279 KB

#4: Room Light Actions
The fourth and final Piston is an example of my Room Action Piston. I use one for each room - in this case, my kitchen. This Piston has no triggers, and will only be executed by calls from Pistons #1 or #3.

  • There are 2 restrictions: 1) is Room_Override switch off? and 2) is @home true?
  • It sets the lights either by color temperature or color (I use color for certain modes and temperature for other modes), and then sets the level. The light settings used come from the global variables set in Piston #1. It then sends a notification/changes Piston state showing the room’s current light settings.

Room%20Light%20Actions
Room Light Actions.jpg1178×887 187 KB

Enjoy!

ST modes, motion and manual switches
#2

Thanks for sharing dude. Looks like something I want to do, just not sure where to start. I have a number of rooms with manual switches and smart bulbs. Also some rooms have motion capability, also modes setup and presence for home/away.

Where is best to start? one room first

#3

Start with populating the variables in the first 2 Pistons. Then do a rules piston and and action piston for 1 room at a time. You will probably want to remove the @home restrictions - you can add those back if/when you set up another piston to toggle that variable based on your presence.

#4

Remember that you will want to add variables for each of the modes of your ST system.

#5

Ive tried dude. Think this is beyond my level of intelligence. Im sure someone else will have a great use for this. I will have to stick to very basic if rule! :slight_smile:

#6

Im currently failing with something more simple…

p1
p1.png1178×976 148 KB

#7

It may be failing because you are mixing lights and switches together. I don’t think that switches can do the tasks for a light - eg, turn on, set level to %. Try separating the actions for each type - so delete the switch and the switch on/off task and see if the piston works for the lights. Then you add separate actions within the same if block for the switches.

#8

This is great. I started developing a piston for each room that basically handled everything in a single piston but I am still battling gremlins and unexpected behavior. I am trying to add override detection for meet my wife’s expectations and I get into timeout errors when trying to save it. I will certainly review your approach and try something different with my home.

#9

@clsanchez77, the timeout errors are because there is a limit as to how much code can be saved… When you click ‘Save’ you should see a count of ‘Chunks’ at the top… For me, 21 always saves, 22 sometimes saves, and 23 rarely saves… Anything 24 and up has never saved successfully for me.

In general, I try to keep pistons at 21 ‘chunks’ or less.

(Also keep in mind that if you are near the maximum ‘chunk’ size, that your logs will always be VERY short, since they share the same memory limitations. (ie: shorter code will allow for longer logs))

Is there any reason why you want everything in one piston? I find I can create much more complex (and useful) pistons if I use multiple pistons. I realize this may be extreme, but I have over 80 pistons active currently, and my only issues are my new pistons still in the testing phase.

To go one step farther, I actually have quite a few pistons that do multiple things, but I am currently in the process of splitting them up into their own individual pistons, to allow me more freedom and flexibility.

#10

Honestly, just a limitation of my abilities. My limited background in writing codes was developing Visual Basic routines for database GUI’s (think Microsoft Access back in the Windows 9X days), so I am used to large scripts that handle everything.

#11

The way I look at it is, all 80+ of my pistons are, in fact, one giant script… Just broken down into segments, so very little code is run at time of execution.

There are sooo many benefits to this approach.

(1) Clean & lean code, so faster execution

(2) You can toggle (pause) certain pistons based on other pistons

(3) You can rename pistons to ‘re-arrange’ them in your dashboard

(4) Easier to share pistons with friends (us)

I am sure there are more reasons… The only challenge I have with this is sometimes, when I have a handful of pistons all working together, I have to edit more than one piston when tweaking my code. I deal with this because the testing phase doesn’t usually last for very long before I am happy with the piston’s reliability.