A few questions about webcore as a whole

#1

I want to take a minute to say how much webcore has really changed how I use Smartthings and has greatly improved my user experience. Like many here I was using CORE before it. I’ve always had a few questions, but they seemed like questions that I should already know and over time just was afraid to ask. I’ve read/skimmed the wiki, ready countlesss posts and have never seen the answers, or at least not enough of an answer. Figure I cannot be the only one using this who has these questions, so I figure I’d throw them out there. :slight_smile:

  1. I think i generally understand cloud vs local. What is the flow for a piston? By that I mean a door opens at my house, the open close sensor contacts my smartthings hubs, then… That communicates over the interenet to Smartthings servers. This is where I’m not sure. Is WebCore contacted as well? Or does the piston code all get loaded/configured on the Smartthings servers?
  2. What if webcore servers got turned off tomorrow? Would my existing pistons stop working? This is in the same arena as the 1st question.
  3. OK, so what gets stored on my hub? Mostly just curious on this. When I have a large piston, does that impact the overall performance of the hub? Same kind of question. What about a large amount of local or global variables? Do these impact other pistons, or even non web core automations?
  4. Is there a limit or at least a recommendation on how many pistons are ok? Is it better to have multiple small pistons, or less total, but larger pistons?

Again, I just want to say thanks for this community and WebCore. Aprreciate all the help and information here

#2

The webCoRE servers are only used to show your piston tiles and edit the pistons. Everything runs on the ST servers (you can see the piston definition in the ST IDE if you want)

No, they would continue to work. It would just be extremely difficult (albeit not impossible) for you to make changes and you couldn’t look at the piston states/tiles as easily.

Nothing. webCoRE runs 100% in the cloud. If you have multiple pistons subscribing to the same device(s) things might slow down a tad.

The recommendation is to not use multiple pistons to subscribe to the same device events (though, if you can keep all your pistons organized in your head you might get away with a little bit of that).

#3

Thanks, great info. So… What about global variables? Are they then stored in every piston? Or is there an area within SmartThings IDE where global variables are stored?

#4

They are stored in the “vars” variable of the applications state for webCoRE (if you look in the IDE under “Locations → Your Location → Installed SmartApps → webCoRE” and look for the entries in “Application State” you will find them there). They are global since they don’t belong to any piston but rather to the parent app for all the pistons.

#5

Quick question about best practices and multiple pistons on the same device events. I have a couple pistons that in my mind are seperate functions, but do use the same device.

So garage lights - Turn on with motion, stay on if there is motion, and then turn off with no motion for X seconds. It also relies on a local variable I use for manual override of the piston. So turn off lights with no motion and variable = true

I also have a garage door open piston, that uses the garage door for its device, but… I also close the garage door if there is no motion for X minutes, but also relies on a local variable. So no motion, and varaiable = true.

These both work, but both rely on events from the same motion sensor to do different actions.

I could just come up with a master piston for the garage as whole that dealt with the door and the lights, etc. Or I could use global variable, and then just have a piston for motion events in the garage.

What would you do for these kind of pistons? I know there are a million ways to accomplish the same thing. Thanks

#6

Hi

I have a question, which is a better more efficient way of writing my piston

A) I could have one main piston that does the decision making to change the mode and i could have child pistons that are triggered based on mode changes

OR

B) i could have one main piston that does all the mode changes AND the automation for the mode in one piston

OR

C) (like i have it now) I have one piston per mode type that is in charge of deciding when that mode should be changed and it also automates the rest of the stuff.

Lastly i want to create a piston or designate a section of a main piston per the options above that will create a CANned response in my push notification that tells me watched changed per mode change dynamically. Sort of like “Per your request i have change mode to $mode (example), and set smart home monitor to $SmartHomeMonitor… etc.”

Any advice? I’m sure it doesn’t matter, but i want to know if there are risks with each option and what those are i.e. memory or long delay to execute etc.

Thanks

Miguel

#7

Personally, I am a big fan of:

D) Individual pistons for each ‘mode’ (movie time, go to bed, sunrise, arrive home, etc). These pistons will do everything from set lights, colors, levels, fans, variables, read weather out loud etc.

And then, depending on a few factors, that piston can be triggered by

  • a self-inflicted timer… (regular events)
  • another piston… (complex situations)
  • Alexa / Google Home… (spontaneous calls)
  • walking in the front door… (routine events)
  • a weather event… (interactive triggers)
  • Etc.

When it comes to ‘modes’, the general concept is (for the most part) I keep the ‘action’ piston separate from the triggers. This way, any (or all) of the bulleted list above can trigger that ‘mode’. This keeps devices and commands from stepping on each others toes, since it would be highly unlikely that a timer would go off at the exact moment that a rain cloud hit. (using one example)

I have dozens of pistons that look like this:

temp
temp.jpg701×51 5.63 KB

and only run when something else calls it.

#8

I was curious when I read this, but I cannot seem to find them.

What do I do after I’ve logged in to the SmartThings IDE > Locations > My Location > My SmartApps > webCore?

I don’t see anything called “Application State”.

#9

Click the webCore link, then scroll down about halfway down the list … where you’ll find the section labeled “Application State” … the “vars” is near the end of that section.

#10

Man, I feel like a total idiot. When I click the webCore link in smart apps in the IDE, I see the code with a clickable link that says Logs at the bottom. I do not see a “list”.

Temp%20Smart%20Apps
Temp Smart Apps.jpg743×393 66.5 KB

Clearly, I am doing something wrong, but I can’t figure it out.

#11

LOL … well, I didn’t help in this matter … I was suppose to copy what @ahndee posted:

“Locations → Your Location → Installed SmartApps → webCoRE”

Sorry about that :blush:

#12

I got it! Thank you so much!

Where “Your Location” is the name of your hub (in my case “Home”) not going back to the top menu!!!

In case anyone else is as dense as I am…

Temp%20Smart%20Apps%202

Temp%20Smart%20Apps%203
Temp Smart Apps 3.jpg643×666 52.6 KB

Temp%20Smart%20Apps%204
Temp Smart Apps 4.jpg836×745 116 KB

#13

Beautifully illustrated… I suspect your last post @HAL2000 will be linked to more than once.

#14

Hey,

Brand new user to webcore, and I’m hooked already. However, I didn’t see a good answer to the ops question.

I have exactly the same one!

#15

Not sure if this directly answers your question, but I try to keep each device’s trigger in only one piston. So, for example, if I am subscribed to a motion sensor, I try to put all the code reacting to that sensor in one piston. (morning, daytime, evening etc) . (In other words, when something happens, I only want ONE piston taking action) If you are not careful, you can have multiple pistons all doing things each time that motion sensor is active.

Another thing to keep in mind with large pistons… Each time any of the subscribed devices trigger, the entire code runs top to bottom.

In all fairness, I have MANY pistons that are ginormous, but I still try to keep the above advice in mind when programming. (also keep in mind there is a maximum piston size, so if you get too large, you won’t be able to add new code)

I guess if I had to summarize, the size of the piston matters little. It is the actual coding & logic that has the most impact on performance and reliability.

#16

That is great info, thanks! My use case is that I have a button I want to cycle a single bulb through off - 75% - 25% - off. Currently, I have a single piston for that logic as well as the other buttons on the device. There is a delay between when each press will be registered (actually change the bulb). I’m wondering if this is just cycle time of the bulb state,… I was also considering breaking into three pistons:

  • Piston 1: If button pressed and light is off
  • Piston 2: If button pressed and light is >50%
  • Piston 3: If button pressed and light is <50%
  • Piston 4: other button logic
    Thoughts?
#17

My previous post was focusing on segregating actual triggers, but I just want to clarify. I do not reserve commands to a single piston. (in other words, I have 20+ pistons that send commands to a particular bulb. (which I use as a notification bulb)

OK, back on topic:

You could check your logs to see the time between the initial trigger until the final log. A second or so for a round trip would be normal, but I try to stay in the habit of waiting 2 seconds between button presses. (if you are using a 3rd party app to push the button, or the piston is complex, sometimes I wait 5-10 seconds between button presses)

Your logic is good, but since they all have the same trigger (ButtonA being pressed), I would put them in one piston.

If 
    ButtonA is pressed
Then
    IF
        Light is off
    Then
        Set level to 75%
        Exit
    END IF
    IF
        Light level is greater than 50
    Then
        Set level to 25%
        Exit
    END IF
    IF
        Light level is less than 50
    Then
        Turn off Light
        Exit
    END IF
#18

Thanks so much for validating my thinking. That is exactly how I have it written currently. I guess I’ll just pay the button a bit slower. :smile:

#19

That’s just the normal system delay for anything ST/webCoRE since commands need to be sent to the cloud before actions are taken with the target device. It’s not any indication your piston is inefficient.