Rube Goldberg Lighting Control Piston


#1

I’ve only been here a month or so and I’m sure you all get a Lighting control piston to review all the time. This is my first complete piston that does more than just a single action. I wanted to throw this up for criticism before I go “live”.

My approach here was to develop a base lighting piston for each room. This piston was designed around the GE on/off switches and GE dimmers and will work with either or both as these are what I am using throughout my home.

This is a generic base piston I intend to use in just about all my rooms. The piston uses variable to device lighting devices and motion sensors. Dim levels for night mode, home (day) mode, and override (manual on) are established in the variables, as is the inactivity period (in minutes). The current assigned numbers might seem goody but its because I am still testing and debugging. This piston is triggered and organized in 6 parts:

  1. Motion of ANY selected sensor will turn on ALL selected lights.
  2. Turning on ANY selected light switch will turn on ALL selected lights.
  3. Motion inactivity of ALL sensors will turn off ALL selected lights.
  4. Turning of ANY selected light switch will turn off ALL selected lights.
  5. Changing the house to Away or Vacation mode will turn off ALL selected lights.
  6. Changing the house to Emergency mode will turn on ALL selected lights to 100%.

I use set piston statements to update the dashboard for action performed and under which home mode when appropriate.

I use a status variable to determine the last action, which then limits future actions that will not contradict. So for example, I tried to flag not having the Manual Off piston load when other lights switch off due to motion off. This part was difficult.

I also added a bunch of debugging statements and I tried to be consistent with the logging.

A few more things I have through about capturing but did not yet:

A) Having a different inactivity period for a motion activated light vs a switched activated light. I will capture this site specific if its something I desire.

B) Having some lights controlled and/or a different dim level for “Any” of the selected sensors vs “All” of the selected sensors. For example, my family room is large and currently has 5 sensors, some of which overlap the kitchen or entrance. I may use “any” of these to activate lamp lighting, but all of these to activate the overhead lighting. Another set of “all” would operate the kitchen lighting, which may share sensors with the family room. Etc. I decided to go site specific on this feature as its really on 4 rooms, or groups, if you will.

C) I may also add a minimum dim level option as in some places in my home, I may not want the lights to turn off, but rather dim to 10%. I could see this in my hallway and bathroom during party mode or on the stairs to the kids room at night mode. Again, better to capture this as needed as its really only 3 or 4 locations.

D) Finally I would like to capture the double tap on the switches. I did not pursue the double tap - I have the DTH’s for my GE switches and dimmers - but did not capture in this template as its purposes would vary greatly in each room. In utility rooms, this might set the override dim level and/or bypass the motion sensor. In my living rooms, this might toggle home scenes, similar to a Hue switch. In bedrooms, I may use double tap to set and unset alarm schedule lighting. All just ideas right now but nothing I through I needed to capture here.

But the intent here is to use this as my starting point for each room. As is, I think this will work great in hallways, laundry room, garage and bathrooms. For me, its a start. Please let me know what you think.

Thanks!


#2

…and I wanted to add what I like about this piston as this replaces 4 Smart Light rules for each room and allows me to specify not having motion triggers over write switch triggers.


#3

Yeah, I like it. I’m especially a fan of the Piston Status variable that you set and use throughout. Too bad it’s not possible to test against multiple Location modes in a Switch Case block, as this piston would be a great candidate for something like that. I suppose you could create your own, but that might be more cumbersome than it’s worth. Although, I’m sure there’s a cost (in time or memory or processing power) to continually evaluating all of those “only while Mode A or Mode B” type statements.

However, i do think the “only while” statements at the bottom are redundant. It’s perhaps tempting to keep them there for consistency sake, but they do have a cost to them (again, in time or memory or processing) so you might want to eliminate them.

Otherwise nice job. Looks like you learned quite a bit in only a month.


#4

Oh one other thing…

I don’t believe those GE switches actually report “physical” interaction. I don’t think that’s going to affect anything the way you’ve got stuff setup…but don’t count on “physical” working reliably.


#5

The GE switches do NOT report physical interaction…so I have learned the hard way. That was what lead to the development of the status flag variable.

Thanks through. The only while mode statements were done to minimize the number of blocks I needed. I saw it as a half dozen one way and six the other. I see your point though and will consider that if I do a major re-write.


#6

I just realized the case you highlighted was legacy and no longer needed. I originally had the 5th case inclusive of all mode changes and then filtered by mode. I then separated it into just Away/Vacation and then Emergency.

I will remove the double up on the filter, thanks for the catch :slight_smile: