Webcore Piston VS Smartapp (Just Curious)

#1

If I have a piston that does some simple task. Then suppose I have a simple smartapp that does the same task.

Which would be the most efficient? Or in theory respond faster?

Just for my own curiousity.

#2

Depends… But the short answer would be whichever one can run locally on your hub.

If neither of them can (based on a number of factors) then choose the one you like the best…but if one can run locally (since WC cannot) then use the smartapp.

A good example of this is the “Smart Lighting” app. I can actually run locally on the ST hub (you may have to have a v2 version for this to be true…I’m no expert on that) so if you’re doing a simple automation and you can use SmartLighting to do it then it should in theory respond faster (and also continue to work if your Internet connection is down).

But as I said at the opening…there are many other factors at play. Sometimes the devices you want to manipulate use a custom device type handler which runs in the cloud…so even if you have a smartapp which runs locally the device having to run in the cloud will push the processing out to the cloud.

Or you could use a feature of a smartapp which forces the processing to go out to the cloud. Such as if you put a timer on something (like turn off this light in 10 minutes). Many smartapps will then push that task out to the cloud…

As you can see, there are many things which can affect all this lovely stuff. So it’s good to have an understanding of how things work. So keep asking questions…and test stuff yourself. That’s part of the fun… Try out various things and see which works best in your environment. Sometimes that’s the only real way to get the answers.

#3

I understand that if something runs locally on the hub it would be faster. But in this example Webcore obviously doesn’t run on the hub locally and the smartapp doesn’t either.

I was thinking that Webcore would have an additional hop to make to get the job done, but maybe not. I realize in practice the time difference would be negligible.

#4

Given both items are running into the cloud, the Smart App should still run faster as it requires less processing. The WebCore pistons are generally more complicated and thus require more time time to process, of course we are talking milliseconds.

Now, I suppose you could build a bunch of really simple pistons that could respond as fast…but then you could likely accomplish these tasks within the Smart Light App, so WebCore provides no advantage here.

I will add to Mike’s statement that adding custom device handlers will also push the SmartLight applications to the cloud, which removes the local advantage. I found this to be the case with the new GE switch and dimmer DTH’s and of course is the case with my Ecobee thermostats and Hue lighting. In these cases, the Smart Light app provides no real advantage over WebCore.

#5

My understanding of this is that it does not have any extra hops … when you create the piston, it is uploaded to you ST Account, so its in the ST Cloud already (and NOT in the WC Cloud)… all the execution happens in the same cloud infrastructure as the rest of ST

#6

That’s my understanding as well. Once you create a piston, it’s in your part of the ST Cloud. The WebCoRE servers are only used to develop, etc. No extra hops at all.

#7

I have a slightly different approach. I tend to use pistons as much as possible and keep the smartapp to a minimum. I have gotten into a few situations where I have 4 or 5 smart apps which do some things and then I use a piston to cover the other parts. This works fine until it doesn’t and then I end up chasing my tail trying to figure out where the issue is (i.e. in the smart app or the piston).

For example, I have Simplisafe and I use the SimpliSafe Alarm State and the SimpliSafe Monitor. That would be just fine, but now I’m playing with leaving/arrival with SMH and multiple locations and it’s starting to get messy.

So I’ll gladly give up a few hundred milliseconds to have control and understanding of what I’m doing and I can with pistons more than a bunch of smart apps.

#8

This is the approach I am migrating to now. I tried to remain independent of Webcore and once I ended up with about 20 or so SmartApp rules, I found them fighting with each other and it was hard to track down “Why did this light turn on now?” Webcore has given me a better tool for total home management, which has to be part of an smart home control system. The SmartApp was great for the first dozen rules…but the lack of complexity leads to a lot of problems…or a whole bunch of required home modes.

#9

I’ve recently made a change from doing just about all my automations in webCore to choosing my automation engine based on performance and complexity.

I’ve drawn a line between “simple light, motion, & button control” and more complex tasks, based on the significant performance improvements and increased reliability of running lighting and button automations locally vs. via cloud/webCore.

Simple light control = on/off from switches and minimotes, and simple motion lighting rules. They really are much faster in Smartlighting or Button Control apps than using webCore. For example, using webCore for a motion lighting event in my living room, I would usually get about half way across the room before the light comes on. W/Smartlighting it’s on a few steps into the room. Same w/ motion lighting in other spaces like my utility room. W/webCore I am often half way across the room until lights go on, w/Smartlighting lights are on a couple steps into the room. That’s a significant improvement that adds to WAF and family happiness. :slight_smile: The Smartapp automations also aren’t affected if the hub can’t get to the cloud for some reason, so they are more reliable. Again, happy wife, happy life.

So given the speed improvements I see, and the increased reliability, the local processing has a signficant benefit. For more complex tasks, webCore is the best (and sometimes only) option. Examples are things like my garbage reminders, laundry reminders, complex motion and lighting tasks, etc.

I mix and match to get the best results - use the best tool for the job. For instance, I have 8 Minimotes which I use to manage lights and fans. All simple lighting and motion automations are set up via Smartlighting or Button Controller for local processing, are nearly as fast as a normal light switches, and wife likes that very much. Fan control from the minmote (which requires IFTT using Webhook commands to Bond Home device) is done via webCore. So the same minimote will have actions managed by smartapps and webCore. I also have some dimming actions based on light status that I run on the minimotes using webCore.

This isn’t confusing for me and works perfectly for my needs The clear delineations I’ve settled on makes it easy for me to remember where to go when I want to update things. E.g., I don’t have to “think” to know that milk is in the fridge and not the cupboard, and don’t have think to know that complex automations are in webCore, and simple ones are in Smartlighting. It sounds more complicated than it is, really, in practice it’s just a little more complicated than doing everything in webCore, and the performance/reliability gains of local processing are worth it.

Of course, as in all connected home stuff, YMMV, and the beauty of the system is we each can choose the setup that works best for us and our families. :slight_smile:

#10

I agree up to a point. I was using Webcore exclusively and things worked. But I was always having problems where I had one piston doing a couple things. Was having issues on having to play with the cancellation policy, subscribing policy, etc.

So I started messing with doing my own smartapps. I think in the smartapp things are clearer as to the flow of the program and the ifs, thens, elses, etc. Or at least for me. I have a programming background and that makes a big difference. I have broken down my smartapps into basic areas so there is no overlapping of control to figure out what is doing what. And when I migrate a piston to a smartapp I disable the piston. So far it’s worked out fine for me. One thing about using a smartapp that I like. If I need to change what light or switch, I just go the the app setup. Don’t have to edit a piston.

Webcore is great, especially for someone who doesn’t understand programming.

Just my thoughts.

#11

@JohnHoke is correct. Once you save the piston it is then in the ST cloud.

#12

I will need to screenshot this and give to my wife … those that are married will understand :slight_smile:

#13

Biased towards pistons because I’m not a coder… with smart apps, you’re at the mercy of the author for changes/customization. :slight_smile:

#14

Good luck, but if she’s like my wife she’ll assume you mocked it up. :wink: