The ULTIMATE Piston

Continued and reposted from other thread…

The ULTIMATE Piston

Well, I didn’t several hours last night working on this thing and came to the conclusion this morning at 0230 that it was a mistake.

I discovered several flaws. Not problems with CoRE, but problems with reality.

First of all, I was designing it to be as streamlined as possible… That in itself caused a major problem.

I initiated 4 separate pistons into it. I started with my most complex pistons. Modes, routines, and two master bath pistons.

(My master bath requires three pistons due to the complex interactions and restrictions of the actions)

Problems:

Modes - have a single trigger at 0600 was fine. I then had a long list of actions that included wait times until the next mode time change. The problem was that if I paused the piston AFTER the trigger time and before the last wait time occurred, it would kill the timer. I pause the piston while working on them so I do not conflict with other ones.
Routines - no issues there
Master Bath pistons - I thought I had this figured out to get the two combined into one. But all that did was make the entire piston die for that section. Nothing worked at all. I’ll eventually figure this part out.
Piston size - as the piston grew the UI fit it became cumbersome and slow. The operations were fast, but access to the piston was horrible. It started timing out when the size reached 39% and around roughly 60 actions.
Overall, the experience was horrible. But that was only the A-one test run. More to come.

Should I make a separate thread for this adventure?

@ady624 @SBDOBRESCU

Ps, I forgot to take a screenshot before I deleted A-one

EDIT
I will update this section of this post as I progress through this.

LESSONS LEARNED

  • Size matters - the larger the piston the slower the UI. It begins to time out during initial access and while making/saving changes. Real trouble started at around 60 actions and approx 39% memory size.
4 Likes

This one was predictable, not the time outs, but using the ST UI to manipulate a monstrosity such as this was bound to be challenging if not untenable.

The other thing you mentioned should be enough alone to not try to make it one piston. The ability to pause a piston. That’s a valuable function and it diminishes when it’s everything or nothing.

2 Likes

I completely agree that a one for all is just completely undoable.

But, it is working out great as a tool to really think through all of my programming and improve it where I can.

2 Likes

Thank you for sending in your resume. You are no longer in consideration for the positions at SmartThings.

7 Likes

I give you credit for even trying this. I actually make my Pistons as simple as possible for troubleshooting purposes. Many times, I can combine them, but choose not to because it creates complex logic which makes it harder for me to troubleshoot. (and most likely causes bottlenecks on the platform).

3 Likes

After my experiences yesterday trying to create that dog door notification piston, i will definitely echo your sentiment that smaller is better. That piston is at 21% memory usage but is a bear to get into and edit. Tons of errors, have to try multiple times, random crashes while editing, etc. After spending so much time on it yesterday (75% of which was just sitting there waiting for the app to play catch-up), I’ll probably end up splitting it back into several simpler pistons. I definitely like the idea of using a piston to group stuff but it seems like the platform just isn’t there.

That’s of about the dog door piston… I’ve not had any trouble editing that one. My trouble starts at about 30%

How is your Wi-Fi and internet?

Both are good. Internet is 50 down / 5 up, wireless I’m using a 6 month old 5 ghz router that’s about 20 feet from where I sit in the kitchen, strong signal.

I had one at 39% before I started getting errors, revised it down and now I have probably 3-4 in the 28-30% range. No issues with those, response wise or editing wise.

1 Like

I’m slowly reducing everything to the very simplest form of piston programming.

I’ve reduced a high of 89 rule machine rules down to 17 pistons, and those 17 actually do more better than RM did.

And I’m about to reduce those 17 down to 14 by consolidation and simplification.

And the great thing is that I’ve not reduced functionality in any way. I’ve actually increased it while adding around 20 more devices.

I’m simplifying/standardizing as well…I set up a piston a couple days ago to set 4 different dimmer levels based on time of day. Editing through the ST app was getting sluggish…not as bad as the dog door one but not great. I just split it into 4 separate pistons, one for each light, and it’s amazing how much faster the UI moves. The huge piston was a great learning tool though, helped me learn and understand a lot about piston states, task cancellations, restrictions, etc that I didn’t understand well before. So at least it wasn’t all a waste.

1 Like

@destructure00

Yeah, the large piston was a great teacher to me too.

Here is a great streamlined way of setting different levels for different lights over different modes… Really fast…

These lights, in this one section, have different levels set for every mode.

1 Like

Another observation I’ve had is that the pistons I have that have individual actions set up for conditions/triggers seem to move slower and have more issues that ones that follow the normal If/Then structure. Not sure if that’s actually true but in my limited experience so far it seems to be the case.

I haven’t seen that.

When I got back into my dog door notification piston last night it was refreshing pretty fast. No idea what the issue was the other night but it wasn’t there yesterday.

On a side note, I split that big piston up into 5 smaller ones. Much easier to understand and tweak that way. I know everyone has been on the edge of their seats waiting for an update :sunglasses:

Dude, that thing has been bouncing around inside of my head since last night. I’m determined to simplify it!

Good luck!! Here’s what I ended up with. Split based on different functions.

The reminder to close… Isn’t that just basically, “hey don’t forget to close the door” at a certain on a certain day.

Can’t you just add that to one of the other positions as stand alone group with individual actions. It wouldnshouldn’t affect the other pistons and would still run.

That cuts out one.

I really want to see what you have built… All of the pistons… I’m seriously intrigued… And that other monstrosity you posted… Holy crap complex! ! I really want to tackle this thing lol.

Yes, the reminder one could be easily combined with another piston.I just kept it separate since I was splitting it up by function.

Here ya go, lol.

Here’s the “main” piston. When the dog door is closed, it immediately sends a notification “Dog door just closed”. Then it starts an hourly countdown, at the end of which it sends another notification “Dog door is closed since X time”. It loops hourly for as long as the dog door stays closed. If the notification trigger time falls during one of the Mute Periods (a time window when either the pool guy or landscapers could be in the yard), the notification is skipped but the hourly counter keeps going. Whenever the dog door finally changes to open, all scheduled tasks for the Closed portion of the piston are canceled and an immediate notification is sent “Dog door just opened”.

Note - the action for “Send Push notification 'Dog Door closed since {DoorCloseTime}” has a variable restriction of {@mutenotification} = false. Doesn’t show on the dashboard for whatever reason.

**edit - now that I’m looking at this, I think I can delete the FirstPass variable. I’m not using it for anything.

This piston sets the variable {@mutenotification} = true during the periods when the pool guy or landscapers could come, then back to false when those periods end. I have the time triggers backed up an hour to account for the hour-long counter in the main notification piston.

This one is just a simple reminder to close the dog door, if it’s not already closed.

This one counts the number of times the gate has opened or closed. It was never part of the big piston but I’m putting it up here since it’s part of the process.

Here’s the piston that waits for the landscapers to open and close the gate. I use gatecounter=2 because they typically prop the gate open when they arrive, and close it when they leave. So it waits until it sees 2 events, then a “cooling off” period of 15 minutes before it sends a notification to remind me that they are most likely finished.

Here’s the piston that waits for the pool guy to open/close/open/close the gate. He doesn’t prop the gate open, so I get an open/close when he arrives and another open/close when he leaves. I also give a “cooling off” period of 30 minutes because it’s possible that he may have gone back to his truck to get something rather than leave. If that’s the case, the gate counter condition would be met and I’d be relying on the lack of activity on the gate sensor to tell me he’s probably done.

@destructure00

Challenge accepted!

1 Like