Efficient Piston design in webCoRE (to minimize resource utilization)


(Hendre) #1

I’m sorry for the long post, but I believe it deals with an important aspect in respect of which I’ve not seen much discussion:
As some of you know, I’ve been having lots of problems with my ST setup which eventually led to me migrating to a new hub. I did the migration over the weekend and by yesterday lunchtime, I had completed the hardware part of things and started with the software side of things (moving apps and pistons to the new hub). Up to that stage, I was extremely excited as all my Things were responding snappy and reliable.

At some stage late yesterday afternoon, I realised that the Z-wave switches have stopped responding - in general, I was experiencing the same behaviour as what had moved me to migrate to a new hub (apart from the “Not functional” state in respect of the Z-wave module). At the time when I realised all my problems were back, I had completed re-creating all the global variables I use in webCoRE (about 30 in total, containing about 60 - 70 physical devices) and had migrated 16 of my pistons to the new hub.

I would never have expected the new issue would have anything to do with webCoRE, but I started backtracking my steps. My last step was the migration of the pistons, and I started disabling them, without doing anything else to the hub (like a further z-wave repair, etc.) Within 10 minutes after I had Paused all the pistons, everything started working perfectly again. It is now more than 12 hours later, and all is still 100% with all my Smartthings.

My questions:
(a) Could it be that my pistons are overloading the hub to such an extent that it stops responding / can’t communicate with devices?
(b) I know some people are running much more pistons than what I do, so what could be wrong with the design of my pistons and in this regard:
(i) What type of triggers should one avoid/use more processing?
(ii) Currently, I try to stay away from using physical devices in the pistons - instead, I create Global Device Variables for the devices and use the variables in the pistons. Could that be the issue? (The reason is obvious I suppose - doing it that way, I only have to update the Variable in a case where a device fails/changes, instead of going into each piston individually to make the changes.)
(iii) If I do not use a global variable for a device, I define variables for devices in the piston and use the variables in the statements - is that a bad way of doing things?
(iv) Because I’ve had so many issues with devices not responding, many of my statements repeat a task until the device is turned on, instead of only turning it on - is it bad to do it like that?
(v) Which is better: use ten pistons at sunset each turning on one light; use one piston to turn on ten lights in one task which turns on all ten lights (mostly Hue bulbs); or use one piston containing ten tasks, each turning on one bulb.
(vi) Is it better (resource wise) to rather use 2 pistons (one turning on, the other turning off e.g.), than using one piston putting the second part (Off command) in the “else” part of the statement (Hope you understand what I’m trying to ask, but it comes down to which is better - keeping the piston alive until the “else” condition is true, or rather have another piston check when the condition for turning the device off, becomes true);
(vii) Does the “set piston state” function take up many resources?

In general, do we have a wiki or have I missed a discussion dealing with the most efficient way is to design pistons?
What general principles should we adhere to in this regard?


WTH happened to my great SmartThings system?
[DEPRECATED Thread: visit community.webcore.co for assistance] webCoRE - Piston Design Help (ask your fellow members for assistance)
(Jason "The Enabler" as deemed so by @Smart) #2

tagging @ady624 as he is the brains inside of WebCore.


(Ron Talley) #3

I’ll add my experience. Nothing scientific but I also came to the same conclusion as you. In CoRE, I loved using “Super” Pistons. Made me feel like I was doing something!

I have a piston called Flash Lights. What it does is Flash all of the lights in the house 3 times. It is tied to a physical and virtual button. I have this Piston tied to many “nag alerts”. In CoRE, this worked as it should…

However, in webCoRE whenever I execute this Piston, it bogs down the HUB. Sometimes it might take 10 seconds to flash all of the lights, other times maybe up to 1 minute. Sometimes the lights go back to their previous state, other times, they get all out of wack.

Conclusion, I observed that ST HUB v2 doesn’t like “webCoRE” sending a whole bunch of commands to it at one time. In webCoRE, I try and keep things as simple as possible and this has not only helped my response times but also helped my troubleshooting times. Things that used to work “sometimes” now seem to work all the time.

This could also be to the constant updates and @ady624 sheer determination to squash all bugs.


(Bill S.) #4

I’m going to also add my experiences here with webCoRE. I’ve had a few pistons that take upwards of 30 seconds to 2 minutes to execute. These are simple pistons like turning lights on with motion and off again after motion stops. In the main ST app, when I have these setup as routines or using the Smart Lighting app, it’s almost instantaneous. But, when using webCoRE, I notice large delays. I’ve gone so far as to completely remove webCoRE and reinstall it, but I see the same results every time. So, I’ve started designing my pistons to not rely on things that need near instant responses (door/window sensors and motion sensors) and keeping those types of things inside of the ST app. All in all, I love the power that CoRE/webCoRE brings to ST, but I cannot deal with the lag (especially when my wife walks into the bathroom and the lights in there take a minute to turn on lol).


( I hate Mondays) #5

What you are experiencing is not normal. Set the logs to full detail and share the piston and the logs please.


( I hate Mondays) #6

The most efficient way is probably to separate tasks into related groups for each piston. I, for example, have a piston that handles all outside lights (about 15 of them) - it will blink them red when there’s an alert, turn them all white at night and shut them off at dawn, do color schemes on certain special days (can’t wait for July 1st to come to test my 4th of July part). Whenever I have to do something with one of those 15 lights, I do it, then execute the outdoor light piston to reset it to where the light should be. I have another that handles the bedroom lights. Another that handles the kitchen lights. I try to keep each piston concise on its task and make sure no two pistons overlap on their scope. The least pistons subscribing to any device, the better. Scratch that, the least SmartApps subscribing to any device, the better. If you have issues with ST becoming unstable, turn minimum detail logs on for all pistons and get a sense on how often they run. How long do they take to run? Are you using a loop without a wait in it? Enable pistons one by one and see what happens. Also, keep in mind that sending too many commands to devices at the same time floods your radio networks. There are options in webCoRE to inject an inter-command delay - if that is causing an issue.


(Bill S.) #7

Will do. I can set it up when I get home tonight and have logs for you tomorrow.


(Hendre) #8

Thanks for taking the time @ady624. Would you (or someone with a better understanding) mind elaborating on these remarks? I have difficulty understanding the concept of “subscribing”. And how does one accomplish what you suggest in this regard?

What do you mean with two pistons not overlapping on their scope? Does that mean that I’m wrong to create pistons which I call “Scenes” in which I have the devices (in this instance, mostly light switches and Hue lights), which are not executed on their own. I have e.g. a piston called “Scene: Turn All Lights Off” which contains about 15 tasks which are executed one after the other to turn 2 or 3 lights off at a time with an 8-second wait between each task to give the Hub time to “breath”. Such a “scene” piston is then executed by other pistons e.g. One at bedtime, executing the piston “Scene: All Lights Off” to turn off all lights and another piston scheduled to run after sunrise which executes the same “Scene: All Lights Off” piston. (That is to make sure all lights are turned off which may have been turned on at wake-up time.)

The same lights, also, however, form part of other pistons (which I also call “Scenes” which do not execute by themselves) e.g. one containing the lights to be turned on at sunset; another containing the group of downstairs lights which are turned off an hour before bedtime etc. These “Scenes” (Which do not subscribe to any events) are then executed by other pistons like “Sunset”; “Downstairs Lights of an hour before bedtime”; “Upstairs Lights of at Bedtime” etc. I do it like this to make it easier to make changes and that prevents me from having to include lights over and over in “scheduled” (could I call it “Pistons which subscribe to things like time or movement”?) pistons.

(I have after I had turned off all pistons, only turned on basic pistons again (staying away from pistons which are always “alive” like those looking for motion etc) and so far, my system has been relatively stable, with very few devices dropping off.)


#9

@ady624 Any ideas on how to reduce the lag on motion triggering a light? I have a few of the GE/Jasco motion dimmers (model 26933). When set on “occupancy” mode, the time between entering the room & light bulb response is near instantaneous. In order to get the most out of webCoRE though, the switch needs to be set to “manual” so I can set different levels of brightness at different times (if left on occupancy, it turns on to the most recent brightness instantly, then adjusts approx. 2 seconds later to the level set by my piston - not fun being temporarily blinded late at night).

2 seconds isn’t a lot obviously, but when walking into a bathroom I find myself waiting for the light. I can get about 8 feet into a normal room (walking past the sensor) before the light kicks in. Each light is dedicated to its own piston, so I don’t think the issue is resource usage. Any ideas? Thanks!


(Glen King) #10

On the KISS concept, I’m only utilizing webcore to accomplish that which is difficult or impossible in existing smart apps. Why re-invent lots of existing wheels?

I mean, I get it from a hobby standpoint - and I’m playing with a couple interesting ideas. And maybe this winter, I’ll delve more deeply into it. But right now, a few simple pistons that add functionality to existing apps and routines have essentially made THE difference in using ST as a security system. So I’m sticking with that approach for the moment.


(Brian) #11

webcore allows us massive power. And you knew next comes great responsibility.

This is a very good thread. We have to do our best to not hurt our install and blame the wrong thing. It’s almost always the nut behind the wheel.

One very effective technique: pause all pistons and turn on one by one.


(Bobby) #12

Ideas are many. The power of one is not. The almighty cloud gets in the way. But that may change, sooner or later. Meanwhile moving the sensor to see you sooner or using a contact instead of a motion (or a cobo of both) would certainly give you a better experience.