Piston design & implementation

#1

Just curious what everyone’s thoughts are on how to implement pistons. Reason I ask is because for example I have multiple lighting pistons and curious how everyone else does it. So lets use motion based lighting in your favorite room as an example;

  • A) Do you have 1x piston per light that has many conditions for different times/scenes of the day?
  • B) Do you have multiple pistons per light with conditions based on time of day that run congruently all day?
  • C) Do you have multiple pistons per light with even less conditions and have a mechanism that pauses and restarts the relevant pistons based on time of day?

When I first started making pistons it seemed like I was taxing the system harshly if I had scenario A and B going. Something about walking by the motion sensor and it possibly triggering 4x different pistons with only one actually end up running seemed like a lot. So the way that I went about is to associate the modes of the house with the time of day. Upon mode changes it pauses certain pistons and resumes others. So that the particular motion sensor only triggers one lighting based piston ideally.

Not sure if there are more advantages or disadvantages to any approach one way or the other but curious what everyone else does.

#2

I actually have just one for all my lights, its driven by storing the sensors, lights, on time and dim level in variables. It uses separate values for day & night mode.

If I add a new light/sensor, I just have to update the variables. It does have a few restrictions, one sensor to one light, and the light and matching sensors have to be named in the same alphabetical order. It also isn’t 100% accurate as it runs a timer, and decrements a counter per light by 1 every minute. The count down timer does not run if no lights are on.

I’m not sure if the design breaks a few of the webcore coding recommendations!

#3

I take a totally different approach:

  • Each event (trigger) only executes a single piston.
  • Each piston can easily have a half dozen conditions, or more
  • Commands sent to the same light can be in multiple pistons
  • Commands sent to multiple lights can be in the same piston, but
  • Each event (trigger) only executes a single piston. (repeated for emphasis)

So, for example, walking into my entrance hall may turn on 6 lights… As I make my way to the living room, I pass a new motion sensor, so 2 more lights come on. As time passes, 3 of my initial lights turn off. (since I am no longer near that sensor), but the remaining 5 stay on, if I stay in the living room.

Notice how some “overlapping” lights are controlled by two pistons, but they each have a different trigger.

The conditions in that piston will determine the level of brightness, and the delay for shutting off. (as well as, certain times of days, maybe only a single light comes on during that motion event)

In a nutshell, one event equals one piston executing… but that single piston can be as complex as I want.

#4

I am fairly new to ST and WC, so I am still experimenting a great deal and look forward to other perspectives. As I add devices and as the daylight gets shorter, I am pushed to rethink what best practices really look like for my use case.

Currently, I have separate AM and PM pistons to control multiple interior lights. Our routine is sufficiently predictable that motion sensors are used sparsely for triggering (closet and hallway to garage). Triggers and conditions are based on a mix of time-of-day, sunrise/set, and lux sensor. This will almost certainly evolve a bit over the next few months.

#5

So you would be closer to my example A where there is one piston and probably based off the conditions your lighting changes throughout the day?

I had thought about building mine like this but it seemed like mine would get very large with all the different things I want my lighting to do. That being said over the time I have spent here I might be able to refine that a bit.

#6

No, not really. Most of my pistons controls more than one device.

With regards to throughout the day, I have other pistons that run at specific times (or events) that may change brightness or color etc.

Alternatively, if I leave a room for awhile, and then re-enter, it will reevaluate the conditions, and might come on brighter or dimmer this time.

#7

Your explanation makes mine feel clunky and rudimentary :rofl:

Happy there is still plenty to learn or streamline!

#8

Some people design pistons around actions.

I try to look at programming from the perspective of “events” or triggers…

So, for example, if I want to create a complex “scene” in webCoRE, I typically do not use any triggers. This means the piston will never run on it’s own, but can be called by any other program, when the time is right.

This helps to keep my trigger pistons streamlined, with the complexities handled elsewhere.

The real tricky part though is making sure the “scenes” do not trigger another piston.
(IE: note taking is your friend, LOL)

#9

This has been dwelling in the back of my brain for the past week. I am curious how many pistons others are running.

A month or two into this, I am at 9 pistons. As I adapt my thinking to match how webCoRE actually operates, I am inclined to break the functionality into double or triple as many pistons. Now, I need to come up with better Categories. Who knew that automation was so much work :thinking:

#10

I have over 200 active pistons in my main house…
(Some are tiny, and some are quite complex)

I split mine into three instances, with each broken up into about 10 categories…

#11

I have a tick over 110 pistons. In my scheme some of them pause and resume so anywhere near 80 or so active at once. Spread over 3x instances that serve as categories and then into some other on the spot categorization :slight_smile:

Still feel there is much more work to be done which includes reducing the number of pistons.