Let me shed some light.
So, life span of a piston execution is as follows:
event > piston app starts > piston requests run time (devices, attributes, contacts, globals, etc) > parent app spins up > parent app returns data > piston starts execution > piston handles first event, checks for other pending time events, runs them too > piston updates logs > piston updates parent app’s globals > piston finalizes execution > end
The problem with many devices is that during spin up of any smart app, devices found within the Settings part of the app are read (along with their attribute values, etc.). When having too many (I guess ST never planned for so many in one app?), that read time starts to increase to where the automation process is hurt. So, with the help of ST, we identified a few things to tweak:
when a piston is saved, it retains only the devices it needs and stores them into its own Settings (undocumented method to the rescue). Next time the piston starts, it will only fetch its own devices, will no longer require the parent app for assistance with device list. This also fixes the problem where the device’s Activity/Recently tab shows the parent’s name instead of the piston’s name - that should now be corrected. In order for this to work, a method of reading, or rather, not reading the device list at parent start up is required, so until that’s found, this won’t really improve efficiency at event execution start up. But it’s a necessary step in that direction. This will affect ALL running pistons in all installed instances, since the new smart app will expect devices in its own Settings. Pause and resume all running pistons to get this fixed.
Backup bins - they’ve been stored by myjson.com and it appears many of you have issues with that because you’re at work jerfing off instead of working. So I’m moving them to webcore.co instead - created an interface similar to myjson.com’s but the advantage is that public pistons cannot be modified once saved and private pistons can only be modified by the same account that created them. So double-whammy there. This should be seamless to you, if anyone requests a backup bin that I don’t have, I fetch it from myjson.com on the server side and then store it locally.
Piston compilation clean up - I’ve implemented some code that will remove all empty properties from classes that are saved into the piston code. This is to minimize the piston size, as it directly affects the memory usage of a piston and what’s available for logging and other stuff. This will only affect your piston if you edit AND SAVE it. Try with one piston, see if it still works fine, then work your way. If you find any problem, stop and report it. Bugs may not be visible in the script… If a problem occurs, it does not necessarily mean that the piston is fluked. It most probably means that the piston smart app is not correctly handling a missing parameter and that can be easily fixed, so don’t panic.
when saving pistons, their code (in MIME format) is saved into some chunks into the piston’s Settings - this will become the primary line of defense in case of a state corruption (happened before). I will incorporate code (at a later time) that will rebuild the piston code on-the-fly if the piston code is found to be, well, missing. So that your piston can keep pumping. Automatic recovery. Recovery from backup bins is not possible from the smart app, because ST’s environment does not allow encryption/decryption. Those are encrypted, so… if both the state and the settings are effed up, you’ll have to back it up from the HTML UI. Coming soon, along with backup all, restore some/all.