Hmmmm… so which is it?
So much I want to comment on, but remember over-promising and under-delivering is how we’ve gotten ourselves into terrible situations before. We’re keeping quiet to avoid conflicting information when the release happens.
What I can talk about is things that exist, and I can tell you that Hub v2 absolutely sips processor and RAM with the latest local execution releases. The largest of large setups don’t take more than 20% CPU and 10’s of MB of RAM. Local execution can fit into much lower specs than what the Hub v2 has.
So, any plans to allow user created content to run locally? While I agree with your current CPU/MEM usage stats (primarily for Smart Lighting), one has to remember that the vast majority of code runs only in the cloud. Neutering the hub’s specs means that this code will never run on the hub…IMHO.
I guess I was using mixed metaphors, but might as well continue to do so…
SmartThings can "bet their entire kitty on the cloud " and still not kill local processing - 'cuz cats have 9 lives!
In the FCC’s defense, that’s not true. Several portions of the application are requested confidential, such as “Operational Description”, “Part List” and “PCB Payout Schematics”, and those aren’t listed.
I mean, this is a lose lose situation for Nick or I to reply to in any meaningful way. We get yelled at for promising things that aren’t delivered yet, we get yelled at for not sharing enough information. Nick and I are embedded software engineers, we aren’t C level executives. We can’t guarantee anything. For the first time in a long time we are actually releasing new locally running functionality and instead of people saying “hey maybe they are working towards expanded local execution support” the response is “local execution is dead”. I think our release notes speak for themselves, but you can draw your own conclusions.
Also with regards to “most code runs only in the cloud” be careful not to fall into the trap of thinking that your setup == everyone’s set up. Yes, some people extensively use cloud only automation options, but a lot of people have a significant portion of their devices and automations running locally.
Yes, understand that Samsung is abiding by the 80/20 rule (or 95/5 rule as the case may be…) Gotta follow the $ for sure.
I do appreciate the work that you and Nick have been doing to improve the limited local processing of the v2 hub. It has been very encouraging to see these firmware releases. As one of the early adopters of ST v1, and then v2, I still am left wanting for more. ST is a great platform, and this is a fantastic community. Please don’t take any of my comments personally, as they are directed more at Samsung’s direction versus any individuals.
The issue isn’t whether or not there’s more local processing, or whether everything ever promised is delivered (within a decade). Frankly, the issue is that we never know wtf we’re going to get at all, such as Bluetooth. Samsung has managed both a lack of vision and customer service, and it seems to trickle down from the top. SmartThings should be the core of everything Samsung does, and leveraged to challenge Amazon and Google in automation. Instead of pushing their brand, Samsung “updates” tv’s to STOP working with ST, aren’t fixed in years, despite literally begging for a class-action lawsuit, never mind customer support on par with Comcast. Then releases a $300 electronic lock that’s not even “smart”. Hell, Samsung pushes an email telling us to get ready for an update that’s so incomplete, no one can say when we’re going to be left without which features (aside from cloud services for 3rd party apps… we know WebCore is going away or become a private subscription model… to rival Samsung’s products). If Samsung had their crap together, we’d not need to speculate about whether Samsung staff have any clue about what will happen tomorrow. We’d could at least be certain of incremental improvement.
Sigh… and these are perfectly valid complaints to have. It can just be really frustrating when we come to the forums to try to help, or shed some light on things, to get jumped on immediately about things we have no control over. As I said above, I do think we are making progress in the right direction and that that is carried out in our release notes, but I can’t speak for the company as a whole so that’s about the best I can do.
I agree with what you’re saying to an extent. Us ‘power users’ that utilise cloud processing are the vocal minority, and the ‘normal’ users out there that only use ST branded products and devices found in the market place (the silent majority).
The ‘vocal’ minority are just that - vocal. They are much more likely to review products for websites, recommend the product (or rivals!) and drive innovative capability (webcore being an on point example). Neglecting the minorities needs by choosing to go down the hardware downgrade route will alienate them further.
The trouble is, ST senior execs have chosen to downgrade these devices will will shorten their shelf life and future capability. Who knows what future use cases that require more resource are? The 500mhz proc and tiny amount of RAM leave little wiggle room for expansion or innovation.
(Unscientific googling ahoy) :
This site: http://www.bom2buy.com/search/vk05 indicates the price of the chipset in the new hub is $6.89.
The v2 chipset pricing https://www.digikey.com/product-detail/en/nxp-usa-inc/MCIMX6L2DVN10AB/MCIMX6L2DVN10AB-ND/4234789 (at very low quantity levels) comes in at $14, a hefty order will probably bring it below $10.
RAM-wise, one site indicates the V2 1GB chip is around $5.90 per unit, the new V3 will probably be around half that.
If no other corners are cut, that is a unscientific $6-9 saving per unit… Could be an expensive saving if this restricts future capability!
If SmartThings had never publicly stated that Hub V2 would contain a Bluetooth chip and plans for functionality, then 90% of the complaints about missing Bluetooth would go away.
SmartThings is wise to have stopped officially promising stuff. I highly respect that decision - though, unfortunately, there are still plenty of promises being made or implied.
It is ethical and fair to consumers to not make promises. If local execution is important, then we all know (as of just a few months after Hub V2 release) that the original pre-release expectations were inaccurate, and we have been rewarded with unpromised, but factual, steadily increasing local execution.
For consumers who consider local execution to be a “show-stopper”, they are now, with minimal pre-purchase research, fully aware of the alternative platforms they can purchase.
Thanks for your comments here, @Zach_Varberg! Having been here for over 5 years, I know that Community members are understandably thirsty for information and explanation of broken promises etc… By dropping by and chiming in, your face the Community “shooting the messenger”. It is definitely not personal.
The situation would be vastly improved if SmartThings provided official communications to the Community (as was done from time to time in the past); especially if such communications contained consistent disclaimers and identifiers as to what are promises and what are just possible futures.
Not running on the hub doesn’t have to mean not running locally.
Don’t we already know from descriptions of the new platform that custom code will generally be hosted by the code author, not on the hub?
As long as you can make an LAN connection, it could run locally with very minimal processing over on the SmartThings side. But it would be on your own server device.
I could be totally confused on all this, because it’s hard for me to follow the documentation on the new platform just using text reader software. Same reason I don’t read code anymore. But I thought the idea was offloading the custom stuff. That could be ready in a cloud accessible via Internet or it could be running on a server accessible via LAN.
But maybe I’m just wrong on this.
I’m hoping you are correct regarding the possibility of LAN based SmartApps, though there is no indication at all that these can interact directly with the Hub, so SmartThings Cloud dependency is unavoidable. There is not much incremental benefit to avoiding a second cloud if part of a reliable product. ActionTiles’s Cloud has had a handful of very short outages in over 1 year.
But SmartThings already has Philips Hue Bridge as an example of a a local server (it’s a REST-API) communicating with the Hub.
There are some indications that local servers are not intended to be used as SmartApp hosts; because the SmartApp “hook” in the SmartThings Cloud must be able to continuously ping the SmartApp.
Without any official word from Samsung, everyone will just have to wait and see.
Though, I tend to agree with @tgauchat’s assessment… User code may be able to run locally, but will need to hit the cloud to interact with devices attached to the hub. Not exactly local processing.
on my smartthings:
80 devices run locally
45 cloud, that is mostly cloud to cloud like harmony, ecobee, Alexa, vacuums …etc
and about 50% smartapp automation are local = working without internet
I also have Hubitat but they are also not 100% local
for example, cellphone presence is done by 360integration
or hubitat had on direct LAN Other Hub integration local before, but now it is cloud to cloud.
In my case, actually same devices with same rules connected in the same setup are on smartthings instant
while on hubitat with 1-2 seconds delay.
Also, device handlers on hubitat are very generic or nonexistent.
For example, my iris contact sensor will open when door open but when a door is closed I have to click manually on enroll response to get a closed report.
Or my ZigBee light switches don’t report back physical events I have to run refresh 10second poll if I wanna report back so it can take 10 seconds to actually turn on lights if it is not connected to some sensor.
**Hubitat stuff also responds directly most of the questions. **
Reported errors are fixed usually in next firmware update.
And they tell in general what is current feature roadmap and what has higher or lower priority.
they are only not promising issue dates
If I may, what’s the largest? If there’s so much power available why not allow for custom apps/dth for local processing. I remember an old conversation from Ben’s days about the power required for compiling and executing local apps.
Just for my understanding, local execution = faster execution right? It’s not “independent” of the cloud. As I understand some DTH’s are split between cloud and local execution. So the “local” parts will execute “faster” but without the internet it won’t execute since the cloud parts won’t be available.
I’ll speak up for the idea of a power user here…having mostly local setup. While I am not using WebCoRE or anything outside of SmartLighting and SHM really… I am fairly happy with my automatons. I have 90 devices according to the device list. Of that, 9 devices report as cloud. Arlo cameras (Which honestly I wish did execute locally). My iPhone which I find weird that it is a cloud thing but whatever. And the Cree bulbs (which SHOULDN’T be cloud…come on guys almost every other bulb is local…also update their firmware please).
Honestly I haven’t felt a cloud outage since the Hue went local. But I also dont do voice control, I dont try to get too crazy with automations or modes. Every room in the house minus the bathroom is automated for motion or door open/close. Once I did finally upgrade to v2 (which I lamented for weeks for various reasons), and got things setup finally. Local has been great.
Will I upgrade to v3…yea probably. But not the day it comes out. Prob will buy for whatever early bird discounts they better give. Then set it on the shelf and wait for a few months to half year before jumping. Is there anything that make me want it so far…no. I dont have anything thread so outside that I dont see a hardware need on my end. I’m primarily zigbee here with only handful of zwave devices.
as it was said above, this is very much v3 type thinking…reduce cost. But given any tech product you learn on 1 and 2, thus able to reduce cost by v3. So I dont really see a reduction in processor and ram as a huge deal as long as involved code is optimized to fit it.
I run my dimmable Cree bulb as a local GE Link Bulb. Found that suggestion on a forum thread. It works for me, YMMV.