you won’t see anything in the code, because it’s not a problem with any one individual smart app. It’s because the person has set up rules which conflict with each other.
Here’s an example:
I’m using a lamp as a wake up “clock” for my son. I want to turn it on in the morning super dim with a certain color (tells him it’s not quite time to get up yet, so don’t come ask us!). The night before we would have turned off the lamp having full brightness. Problem is that I think there’s a race condition happening between the “on” command which resumes the previous lighting (full brightness the night before) and the set scene command from the canned smart lighting app in SmartThings. It sometimes comes on full brightness and other times comes on dim. Not sure how best to avoid or resolve this race condition. Any good ideas?
Here’s a developer discussion on the fact that there isn’t anything in the smartthings platform to prevent this:
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 othe…
(Tagging @tgauchat for more discussion on that one)
Here’s a warning from one developer regarding the problems that can occur because there isn’t anything in the platform to prevent against it:
I’m not seeing it here (west coast USA). The only way I could see Rule Machine being part of the problem is if your configuration has created a race condition, as described in the OP:
Caution: Rules that use multiple rule-truths as conditions can fail due to race conditions should those tied-to Rules change state simultaneously. Best practice would be to avoid using multiple rule-truth conditions in a single Rule. Triggers do not have this issue; multiple rule-truth events in a Trigger are treated such that any of the Rules proving true/false (as selected) causes the Trigger to take action.
If the above is not relevant to your situation, try opening a chat session with Support.
And a super technical discussion among developers where some of them are used to a platform which enforces sequential threading and are just learning how to make their way through the SmartThings asynchronous paradigm:
Hi, I am a newbie started to learn more about writing smartapps. I came across the atomicstate as I want to keep track of smartapp states (http://docs.smartthings.com/en/latest/smartapp-developers-guide/state.html ).
Based on the description of the atomicstate implementation, it only guarantee the read / write operations are of the most updated values across simultaneous execution of the same smartapp. A race condition can still exists between multiple read / write operations within the same instance of the smartapp. What I mean is:
Assume an atomicstate “a” with the following code sequence
atomicstate.a = 1;
if (atomicstate.a == 1) {
/* this part may never be executed */
}
Am I correct?
Since any smartapp can subscribe to one or more events, serializing event execution can lead to d…
2 Likes