Repetitive Activity Piston Length/Size Inquiry

#1

1) Give a description of the problem
Currently not a problem.
Seeking advice, recommendations.

2) What is the expected behaviour?
Everything is working just fine.

3) What is happening/not happening?
Everything is working just fine.

4) Post a Green Snapshot of the pistonimage

20191209a_PistonLengthInquiry
20191209a_PistonLengthInquiry.jpg1028×2033 272 KB

5) Attach logs after turning logging level to Full
Not necessary.

REMOVE BELOW AFTER READING

I recently learned that some of my pistons may be ‘too big’, and in at least one such case, it was causing an actual problem (i.e. causing a problem in my use of webCoRE simply by being ‘too big’).

After that, I went through, and split a number of them into multiple smaller pistons, and that seemed to take care of the problem.

I also divided up my assortment of pistons into multiple instances of webCoRE to further help; which it did.

Now, I’m taking another pass through my pistons and considering whether I should split others into multiple smaller pistons.

In the case of the one I’ve posted here in this thread, it’s a piston that monitors the on/off status of a bunch of simulated switches. When one of them turns on, this piston turns all of the others in the set off.

QUESTION:
Is this piston ‘too big’ in its current configuration, and should I split it into multiple smaller ones?

If yes to both, then how many should I split it into?
Like, should I have maybe four or five of the Actions per piston, or should I split it all the way down to only have one Action per piston (meaning that this single piston would become like 11 or 12 pistons)?

Also, what is the recommended size of a piston?
Is there a number of lines or a number of actions that I should be sort of shooting for, at which point I should probably split them?

Can this Piston be Simplified? (PART 2: syncs Location Mode to a set of switches)
#2

I can’t answer your questions but I can suggest you simplify your piston something like this:

device switchList=...
device switchesOff

if any of switchList turns on
then
  set variable switchesOff = switchList-$currentEventDevice
  with
    switchesOff
  do
    turn off
  end with
end if
#3

If there is no plans to build up on this piston, I would leave it as is…
(Bonus points for not sending any commands that triggers the piston again)

I usually aim for 16 ‘chunks’ or less… You only see this number during the save process. The largest ‘chunk’ I have been able to successfully save was 24 back in the day, but as my pistons expand, about 18 ‘chunks’ is my current maximum before I have issues. (which is why I aim for 16 or less)

#4

That’s a lot of simulated switches! Off topic, but can you give some insight into what you are doing with all of these and the idea behind this piston?

#5

Indeed. :slight_smile:

Sure.

I use simulated switches for all kinds of things all over my SmartThings systems.

e.g. They come in handy when creating things like a ‘night light’. In such a case, the smart lighting fixture itself (perhaps a smart plug-in power outlet, or a smart wall switch, or a smart bulb, or other) may be involved in lots of other automations beside the ‘night light’ automation.

So I can’t just name the actual smart lighting fixture itself ‘night light’. Instead, I leave it named according to what kind of device it is, which room it is in, which numbered smart lighting fixture it is for that room, and where it is in the room. That way, any automation that needs to have that fixture involved can be named according to whatever it is for, and just point to this smart fixture to do what it needs done.

In the ‘night light’ example, the simulated switch named ‘night light’ (along with whatever other designations make sense for the room it’s in, etc) would be the switch that gets called by automations when I need the night light to do things, instead of them calling the actual smart lighting fixture.

As for this specific piston which I’ve posted here in this thread, it’s a series of simulated switches that correspond to my system’s ‘Modes’.

Whereas most people probably only have a few Modes like Home, Away, etc, I developed a large group of Modes to represent not only Presence, but also time of day, and overall condition of things (more on that in PM if anyone’s interested).

Well, at one point, I discovered that I needed to have an automation of some kind interact with my Modes, but I wasn’t able to do it the way I wanted directly. I discovered that it would work better/properly if it could interact with switches instead of directly with the Modes themselves.

Therefore, I had to create a set of simulated switches that corresponds to my large set of Modes; one simulated switch for each Mode, including one for the Mode named ‘Sync’, which I added to the mix to assist with keeping the Mode Switches synced with the actual Modes of the system.

With how I have the automations configured, if any Mode Switch turns on, all of the other Mode Switches is turned off. Without doing this, all every Mode switch would effectively always be On, and the relevant automations would never be able to know which Mode the system was in by looking at the switches.

There’s more to it than that (e.g. a series of 7 distinct pistons - each having a specific task as it relates to the Mode Switches - manages the states and syncing of status between the real Modes and the Mode Switches), but that’s the basics as it relates to this particular group of simulated switches. :slight_smile:

#6

Very cool! I love how everyone can come up with their own way of implementing this technology into their home! Mine is nowhere near the approach of yours but in the end I think it works the same for the most part :slight_smile: Thank you for the very detailed explanation!

#7

@guxdude
Thanks. I really like the idea of simplifying wherever i can.

On this one though, im not sure if thats possible.
Before i implement this idea, i just want to check…did you notice that the list is different in every set, and does that matter?

#8

@sgnihttrams I saw that and no, it doesn’t matter. The math does the work for you. The main list has all the switches and then you subtract out the one that was turned on so the math makes the list different depending on which switch was triggered. This is convenient because, if you add more switches, you just add them to the main list and it is good to go.

#9

I’m actually getting around to this now, and I just realized how cool (and, as you said, simplified) this is. lol

So, once I put the switches into the variable, this is all the code needed, and I don’t need to have a separate section for each switch, right?

Also, in the case of one of the switches, I want it to also get turned off when it is turned on.

So, is there a way of doing the following?..

set variable switchesOff = switchList-$currentEventDevice+SomeSpecificSwitch

…or should I just create a separate piston for that action?

#10

Yes, this is all the code you need. And the modification is simple if you add any more switches in the future. For the always off switch, perhaps modify like this:

device switchList=...
device alwaysOff=Switch_X
device switchesOff

if any of switchList turns on
then
  if $currentEventDevice equals alwaysOff
  then
    set variable switchesOff = switchList
  else
    set variable switchesOff = switchList-$currentEventDevice
  endif
  with
    switchesOff
  do
    turn off
  end with
end if
#11

@guxdude
Oh my. That’s great.
Thanks much!

Someday, I will dig more into this thing (webCoRE) and go around simplifying all kinds of pistions.

#12

@guxdude

Here is what I created, following your advice…

SetOtherModeSwitchesToOff
SetOtherModeSwitchesToOff.jpg1065×461 48.6 KB

It seems to be working.
So, thanks a lot for your advice, and assistance with bringing it to fruition. :slight_smile:

EDIT: I was having a problem, but I think I fixed it.

#13

You’re welcome. Let us know if you have any more issues with it.