I know to not mix state and atomicState in apps.
However if I use atomicState in my app, as it seems I’m going to have to, do child apps and inparticular child device handlers of that app all have to use atomicState ?
1 Like
When asking for assistance here, it is helpful to give as much detail regarding your use case as possible.
The solution might be to avoid needing atomicState entirely, but no one can advise this without knowing your Application.
Ahh… I hoped the question was pretty self complete and didn’t depend on any use case. It was just a clarification about the child need for atomicState if the parent used it.
However… I have a device driver (using state variables) that is discovering devices - lots of them and they appear asynchronously, maybe 100+ in 30 seconds. I post events back to my ‘atomicState’ app as each one is found and count them with atomicState.count++ as well as append to a string that contains these device names. But that string is incomplete with devices that are missed, or appear and then later vanish. The count of the devices is also way short. Then in the same method I call createChildDevice() and I am getting the correct number of child devices created. But atomicState.count is wrong, this var is only used in this single place in the code apart from being initialised in def updated()
I swapped to atomicState because of these issues with state which I took to be because of the sudden burst of device discovery causing multiple concurrent execution.
I’ll try and reduce my code to a simple app that illustrates this
1 Like
atomicState is very inefficient. I haven’t checked the latest docs and/or Forum posts about it, but if I recall correctly, it forces the state to be written to persistent storage with every update, instead of when the SmartApp finishes an invocation or there is a periodic cache flush.
I presume atomicState also must force a read from persistent storage with every update … and lock it so that other concurrent invocations of the SmartApp cannot concurrently update.
Frankly - I doubt that it works consistently 100% of the time; even if it works better than non-atomicState.
I haven’t done much with child devices; so I don’t know if there is a “better way” to handle this situation. I recommend checking the source code for something like the Hue Device Handler (all the bulbs are children, right?) and see if it gives you clues as to when atomicState should be used - or if its logic avoids the need for it.
My findings now back this up… but I have introduced 50ms delays in key places and now all is well. I do not think that ‘lock’ you mention is implemented but careful implementation, albeit with tweaking delays has made it stable.
1 Like