Implementing the Single Responsibility Principle and using ExecutePiston Correctly

[reach4thelasers]

1) Give a description of the problem
I’m seeking guidance on the best-practices for piston design. I’m a professional Software Developer and have naturally opted to use tried and tested methodologies SOLID methods like the “Single Responsibility Principle”. and “Do not repeat yourself”

In doing this the Majority of my pistons perform a single action, without a trigger.

e.g

These Pistons are then triggered from other pistons, e.g. This is my morning alarm clock / wake up piston… When my Withing Sleep Sensor says I’m in bed (via virtual switch set by IFTTT) and the alarm switch is triggered by Smartthings automation, then the other two pistons above get executed, one to fade the lights up by a Hue Routine, and then wait 15 mins and play my wake up playlist on my Sonos…

I’ve not seen many examples of pistons being used like this and I’m concerned about things like scheduling and concurrency and what settings I should enable on the sub-pistons to ensure they work correctly.

I’ve got some questions about how “Execute Piston” works:

• Does it block and wait the calling piston until the executed sub-piston completes, including any waits
• If Execute piston is called from two separate master pistons, will the second execute piston be cancelled by the scheduler?
• What settings should I enable, e.g. Concurrency/Scheduling to ensure this approach works properly.

[an39511]

I make a fair amount of use calling/executing pistons so I am not duplicating the same actions in multiple pistons. One example I make heavy use is for notifications. I have one piston that is the single point for all other pistons to call. If I want to make a change of how notifications are done, I have one place to make that change.

webCoRE is a nice app but it lacks terribly for debugging. There is no easy way to find piston that contain calls to other pistons so things can get out of control if you’re not careful, especially when the overall number of pistons increase.

Does it block and wait the calling piston until the executed sub-piston completes, including any waits

No

If Execute piston is called from two separate master pistons, will the second execute piston be cancelled by the scheduler?

No

What settings should I enable, e.g. Concurrency/Scheduling to ensure this approach works properly.

None that I know of.

[E_Sch]

What platform are you using? ST or HE?

On both platforms, each piston has its state and logs. Not usually much data/space, but logging is something to watch as that could use a lot of space when it is enabled, or if the settings is ‘deep’ for keep of records.

my first thought is if a piston is not shared, having it as a small separate piston might not be as efficient. That said, I don’t feel strongly about this.

[orangebucket]

• Does it block and wait the calling piston until the executed sub-piston completes, including any waits

There are two ways you can execute pistons.

You can choose whether to ‘wait’ for the executed sub-piston. If you do so then the sub-piston will actually get executed using the calling piston’s instance and return control to the calling piston when it finishes. So it is sort of like running a function. A slight ‘gotcha’ here is that any wait of over five seconds, or that will leave the instance with less than ten seconds of execute time available when it finishes, is implemented by setting a wake up timer and executing. If the sub-piston does that the exit will cause control to return to the calling piston and the sub-piston will now be indepedent.

If you choose not to wait for the executed sub-piston the calling piston just sends a location event to trigger it.

• If Execute piston is called from two separate master pistons, will the second execute piston be cancelled by the scheduler?

No. However if you are choosing not to wait for the sub-piston, which I suspect more often than not will be the case, it will be no different to the piston handling any other event. A new instance starts up and if there is already one running it will pause for up to ten seconds to allow it to finish.

• What settings should I enable, e.g. Concurrency/Scheduling to ensure this approach works properly.

The only two the leap out at me are:

1. As mentioned, consider whether you want the calling piston to wait for the called piston to finish.
2. If you are not waiting for sub-pistons, consider whether it actually matters if the sub-piston might sometimes wait several seconds before running, and if it does, would there be any conflicts caused by more than one instance running at the same time (bear in mind local variables are shared between instances)? If not then you can choose to enable parallelism in the settings of the sub-piston.