Maximum Piston Size & What is a Chunk?

#1

This is a general question (or a few) regarding piston size. I see this was occasionally discussed herein, but not in any definitive guidance.

What is generally the maximum piston size? What is the most number of triggers? Program Statements? Chunks? And what the heck is a chunk?

For example, lets say I have a group of lights (three devices) that have eight triggers (garage door open, door open (1 of 2), motion (1 of 2), switch on (1 of 2) and double tap on (1 of 2) and then I have motion inactive off (2 of 2), switch off (1 of 2) and double tap off (1 of 2). There is some commonality amongst, but also some differences. For example, night mode triggers will dim to one level and have a shorter inactivity period than home mode triggers. Double tap on will go on full brightness and not turn off due to inactivity. Double tap off turns off AND closes the garage door. My point, is this application does not have a clean split. I could split this in two, but then I need global variables, which I don’t want to use specific to one room.

Any guidance on piston limits would help me plan these better.

Thanks

#2

Also, to add on, I will see under each Piston a “Memory Used” and all of these are usually 45% or less. What is this a percent of? If we are allowed a set resource per piston, why do they time out before they reach this size?

#3

ST (dictated by the Groovy standard) imposes a 100000 character limit on what can be saved in each piston. This was one of the key motivators for creating webCoRE as it had reached the limits.

A big chunk of webCoRE UI is in the cloud, giving us more room to play with. And pistons are saved as child instances, each with their own 100000 limit.

When you save a piston, it is sent to ST and saved in a piston instance on the ST cloud… due to time-out restrictions, the file has to be split into chunks before being sent, and then reassembled at the ST end by the webCoRE smartapp.

It’s highly unlikely a piston on its own will reach the character limit… I’ve saved 35 chunk pistons and still only reached 40%.

Sometimes an error in an expression can bloat the file and cause a ‘100000 character limit reached’ error in the IDE live logging.

You will however see the piston memory size increase after saving, as the logs are also saved in the piston instance, not the webCoRE cloud. WebCoRE automatically deletes older logs though, to keep within limits.

I’ve found that for exceptionally large pistons, like my 35 chunk one, logs don’t work at all.

Cannot save piston editing session, State Character Limit Exceeded Exception
#4

Ok, this makes some sense. I have been heavy handed in my logging statements, not aware that was penalizing me. Also makes sense as to why some of my piston sizes have gotten so large in file size even though my typical chunk sizes are in the 20-22 range. I find my response time on the pistons reasonable and latency to be minimal so I have to have gotten something right. I have also gone through them to make sure I don’t have any busted variables or dead end logic.

My piston layout is, to be honest, not the most efficient in file size. But I write them so the logic is easy to follow so that I can come back at any point and quickly re-understand what I did and edit it later. For example, I have triggers update an “Action” variable and then use a Case Switch to perform the action statements. This came to be because I was having to much repetition where multiple triggers resulted in the same action, and sometimes the action was not consistent with intent as the code was too cumbersome to follow. But I do use a lot of False Trigger logging to help debug and finalize the piston.

Now, do comments also count towards this 100k limit?

Here is one of my sample pistons. I use this logic outline is just about all my pistons. My plan was to develop a piston for all my major lighting groups and have all triggers within a single piston…as opposed to having multiple pistons each with a few triggers controlling a single light group in competition. For the most part it will result in one piston per room. Larger rooms will have multiple pistons though. I find this approach leads to a cleaner dashboard.

3kq46
3kq46.png1178×3856 529 KB

#5

Comments count towards limits yes… everything is saved in a piston instance on the ST cloud, nothing is held in the WC servers. When you load a piston on the dashboard, webCoRE has to download it from ST.

The only thing WC saves is a heavily encrypted backup copy (codes behind the scratch panels) and unencrypted anonymous copies (green snapshot codes).

I wouldn’t worry too much about piston size / extra logging… WC self regulates and it won’t slow things down by anything noticeable.

#6

Thanks Robin. The only reason I worry about it is if I start expanding on the piston above, I can no longer save it. I get the spinning squares. For example, I wanted to capture double tapping on my switches, but it just won’t take.

#7

Are you seeing the character Limit error in the IDE live logging?

Try clearing the logs before editing and saving.

Normally the spinning squares on save is related to a dodgey expression though… webCoRE is trying to translate it to groovy for saving in the piston file and gets stumped by the eronious expression. Bit like translating Chinese to English but original text is in Japanese.

#8

And I thought I used some off-the-wall analogies at times… :slight_smile:

#9

No, just hanging. I assumed it was a size limit issue. I’m pretty thorough on my logic and I plan carefully before changing existing pistons so I do not introduce error.

Also, now that I know the pistons are measured in character ‘bytes’ and everything counts (I assumed comments were disregarded), I can streamline the piston sizes a little better. I may pair down the content in my debugging statements as well. The info in there is a bit redundant.

#10

Is there a need to manage memory at the Instance level? I get it with pistons… But, see mention of creating instances just to do tiles. I have a few tiles tied to some pistons, not getting near the memory limit per piston. Trying to understand what’s driving the recommendation for a new instance. Thanks for your help!

#11

No limit on number of pistons etc. per instance and no need to separate tiles from pistons.

In the very old days, before the creation of the storage app, there was a limit, but not anymore.

#12

Thanks Robin! How about for logging? My understanding is that when the total memory size gets to 100K, logs start to overwrite themselves. Which I’m ok with… But, I’m also reading posts that make it seem as if piston performance suffers above 75K, so logging may want to be limited. What’s the best strategy here?

#13

Try to keep piston size down where possible… split into segments if you can and reducing logging, but it won’t have much of an impact on speed.

Biggest problem is overwhelming the webCoRE app when re-saving older large pistons down the line.

#14

Thanks again. I keep logs off. But, log to console when someone opens the front door to have a record of comings/goings. Is there a better way, other than logging, to track these activities? Other than that, I’m really not logging anything after debugging is done. Thanks!

#15

Logging to console is great for keeping track of the last handful of executions… If you only want the last event to be displayed, you can "set piston state", and then the results will be displayed on your dashboard.

temp

You can also Send Notification or SMS for important things that you do not want to miss.

#16

You can also log to fuel streams, which will display a nice graph for you.