Local data caching

I was led to believe by Samsung’s marketing that the v2 hub would cache schedules and event calls locally. It was on the basis of that claim that I decided to build around the hub. However, as today’s system belch made clear, when untethered to the cloud, the v2 hub is a brick. A brick attractively styled to complement any décor, but a brick.

Some clarity on this subject (hopefully from from Samsung) would be welcome. For instance, is anything at all cached locally? Is there anyone who can answer this with certainty? There must be some economic incentive behind this hoarding of data and refusal to write it to our local bricks, but I can’t discern it.

1 Like

Local processing is discussed at length in the developer section of the forum. (This is a clickable link.)

To see exactly what on your own account is eligible to run locally you need to check two places, one for device types and one for smart apps. The community-created wiki has the links posted:


1 Like

The data certainly has “value” and a cynic might say that it might be so valuable to SmartThings that it is sufficient incentive for them to not permit fully cloudless operation.

The reality is that the cloud provides value to the Customers in various ways – it is ironically resilient (has backups, load distribution, failover from downed servers to another, etc.); accessible anywhere there is internet, easier and less risky to deploy updates, and so on. All relative, of course.

And the power of the Cloud reduces the cost and complexity requirements of the Hub. By partnering with the Cloud, the Hub doesn’t need as much RAM, non-volatile storage, CPU power, manual port-forwarding configuration, etc…

The problem at the moment is SmartThings has not reached the optimal (or even close to optimal) balance due to premature release of the hub, and/or the decision to cut costs by underpowering the hardware (insufficient memory and/or less than ideal operating system). The plan was for the hub to act as a dynamic local cache for any set of Device Handlers or SmartApps used in the Customer’s site. If there was a bit of a memory shortage, perhaps paging to secondary memory or USB disk could be used, and/or priority flags set to decide which modules to toss out and grab from the cloud again on an as needed basis.

The reality: Whether due to complexity, development time constraints, or cost cutting, the plan I described has not come to fruition … yet. Currently all Device Handlers and SmartApps must be pre-compiled into the firmware image and statically deployed to all hubs, with no customization on a per household basis. This means that huge compromises have to be made to decide what can fit into the limited memory available. It means that “unpublished” personal or Community developed Device Handlers and SmartApps cannot be loaded onto your own hub for testing and/or personal choice of alternative local running apps.

Event data and State also needs to be shipped frequently to the Cloud in order to sync with all the non-local SmartApps and be accessible to the native mobile Apps (connect to cloud only), since the the local Hub does not have a client API.

Some of the above limitations will fade over time. Others may require new hardware or major architecture overhauls, and some stuff will always be cloud-focused unless SmartThings radically changes their platform and business strategy.