Questions about SmartThings Platform internals



I have some questions regarding how the SmartThings platform works.

Is the system the SmartThings cloud platform is based on Cassandra? If yes, are there any core parts of Cassandra that have been modified? In particular, is it still eventual consistency or something else?

How are incoming events/requests received at the cloud infrastructure? Is there a queue created for each SmartApp? Is there a queue that receives all events? How does the infrastructure deal with concurrency; does execution of each request need to happen strictly in the order that it was received? Is there some ordering guarantee?

If there is no strict ordering guarantee (i.e. this means SmartApps can overlap their executions and are not serial), SmartApp instances executed concurrently could compete against each other and finish in a different order (race conditions). Is there a mechanism (e.g. scheduling) that guarantees that this doesn’t happen?

In general, at which level does scheduling happen? How are different events scheduled for SmartApps and devices from the same user? What is the policy and how does it affect i) execution of requests that belong to separate SmartApps? Example: Event A happens first and triggers SmartApp 1 to execute and Event B triggers SmartApp 2 to execute. Is there any way SmartApp will be scheduled to execute first?

How does the policy affect ii) execution of requests that belong to the same SmartApp? Example: Event A happens first and triggers SmartApp X to execute and Event B triggers SmartApp X to execute as well. Is there any way SmartApp X will handle event B first due to scheduling?

In the documentation, two mechanisms are provided to manage persistent storage, State and Atomic State. It would very helpful to know how State and Atomic State are implemented. What does happen in the background? For Atomic State, is the API calling for some locking mechanism in the underlying system (e.g. Cassandra)?

I also have a question regarding how the Hub works. Once the hub receives a request/command from the cloud platform, is that put into a queue to guarantee that order is preserved? Does the hub have multiple threads to serve requests or serves one such request/command at a time? If there are multiple threads, does scheduling of these threads guarantee completion in order? Do events received concurrently get dropped?

Conflicting apps
( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #2

Lots of interesting questions, but based on your questions, I’m predicting you’re not going to “like” the answers you get.

To the best of my knowledge, there is no guarantee of order execution in SmartThigns.

IMHO, in the “real world” of consumer home automation, this seldom is an issue, and rarely a serious one. SmartThings has plenty of too frequent “worse” problems than rare out-of-sequence event processing.

@JDRoberts may elaborate at length (not staff, but he’s a well of knowledge).


Sorry, I have no idea how the cloud platform operates beyond what’s been posted to the forums. I was a network engineer, but not for Samsung/SmartThings. ( search the forums for “Cassandra” and you’ll find most of the technical discussions On the cloud architecture .)

There’s no guaranteed sequencing in the third-party protocols that SmartThings uses, zigbee and Z wave. Those are both deployed as mesh topologies, and messages can, and do, bounce around the network and can arrive at the hub in any order. It’s even possible for a “door closed” message to arrive at the hub before a “door opened” in some circumstances. That’s why the SmartThings developer docs say that they can’t guarantee scheduling in less than one minute increments. That same section of the developer documentation discusses what happens when multiple events are scheduled in overlapping windows.

Cron jobs are only allowed to run at a rate of 1 minute or slower. If your cron expression runs faster than once per minute, it will be limited to a one minute interval. For more information, see this community post.

SmartThings does support atomic.state which is intended to help avoid race conditions among two smartapps which access the same information

But there isn’t anything in the platform that I know of to keep two smart apps from both requesting that the hub issue commands to the same end device, which is a different kind of race condition.

Mesh topologies by their nature are not appropriate for very fast Precision execution. You should use a tree or star topology for that instead. For example, you’d never run streaming audio or video over z-wave because the packets might arrive out of order. Z wave and zigbee home automation are intended for implementations where there are not very many messages, they are tiny, and they are not sent very often. Even energy monitoring is stretching the paradigm, as evidenced by the repeater problems you get when you put two energy monitoring zwave devices too close together.

If you need super precise superquick execution, Wi-Fi is a better fit.

But again, I don’t know what happens in the cloud or between the cloud and the hub in a specific SmartThings implementation. @jody.albritton might know more.