I’m not even sure that my subject accurately reflects my question. A couple times I have seen someone recommend a webCoRE app and the response is that the user “wants to keep things native” or local within smartthings. I am just dipping my toes into smart home control. I have 1 lock and a few lights so far, and I am looking for more control (and notifications) of my lock. I already have webCoRE installed just so I could play around with pistons, but no apps really. I am considering either the smartthings smart locks app, which seems at best to have the most basic functionality, or using @ethayer’s Lock Manager to have full control of my lock, codes, notifications, etc.
My ultimate question is, what are the issues/risks/downsides to using a webCoRE app instead of something within the smartthings mobile app?
Big difference is webcore is cloud based. Meaning if internet goes down it won’t work right. Mobil apps generally are local to hub so you don’t need internet for them to trigger. However webcore is so much more flexible and can take things to the next level. If you can dream it. It probably can be done. Almost
The smart lighting smartapp is the only one that can actually run locally. Technically there are components of smart home monitor that run locally too, but smart home monitor is essentially useless if your internet is out or the ST cloud is down.
I’m not sure if the native locks smartapp runs locally, I haven’t heard any indication that it does.
Every other smartapp, including routines and other official features within the ST mobile app, does not run locally. All custom smartapps (i.e. those that are developed by a community member and available on github) do not run locally.
Even for smart lighting, every device that’s used in a particular automation also has to be eligible to run locally. There is no officially maintained list of device handlers that are eligible for local execution, but with recent hub firmware updates they have made a note of devices that are newly eligible for local execution.
So if it’s possible to achieve what you’re looking for with smart lighting and you use only device handlers that are eligible for local execution, then yes there’s an advantage to using smartlighting.
But smart lighting can’t do particularly complicated automations. I use webcore for the things that smartlighting can’t do.
Also we never really clarified whether we’re discussing the old ST app, now known as classic. Or the new ST app, which used to be known as Samsung connect.
I have to admit I really don’t know anything about the new ST app, since as a longtime user I don’t use the new app.
But I don’t think there’s anything notable about local execution in the new app vs. the classic app.
I was referring to the classic app. I tried using the new app, because that’s what I was instructed to do as a new smartthings user, but that was not a good experience. I had a very dim view of smartthings until I got the classic app and it all started to make sense.
Moving over is easy. You just exclude or remove the device from ST and add it to Hubitat. However, ST has a huge official and non official compatible list of devices. Hubitat is still new so it has no where near as many custom apps and DTHs as ST.
Although webCoRE has been “sorta” ported over, it is not as reliable like it is on the ST platform. (Buggy)
I like this idea just wondering if ALL the devices you have on Hubitate show up in ST and still correctly controllable “like normal”? Might have to look into doing this for some of the devices I want to run locally.
Yes, the senors and devices update in real-time and devices are totally controllable in ST. It is true two-way communication via the “Other-Hub” App. I can either use Hubitat’s rule engines or rule engines in ST.
Below are examples: Dimmer, Switch, Contact, Motion and a Virtual Switch. All of these devices are Hubitat devices but show up in ST as Virtual devices. Soooo Cool!