While off Topic, this is a great observation that’s worth a little discussion…
The SmartThings App actually behaves exactly in this manner (ie, immediately changing the Tile State when tapped rather than waiting for the Thing and SmartThings Cloud infrastructure to report/confirm it’s new State)… with one difference in some DTHs:
It is not done universally or consistently (but still pretty common): Many SmartThing DTHs have hardcoded a transitional State that is local to the UI only.
Easiest to just give an example:
Tapping an Unlocked Lock in SmartThings App transitions the Tile immediately to “Locking”, rather than “Locked”. That latter state is eventually reached when the physical Lock sends its updated State to the SmartThings Cloud (vis the Hub).
99% of the time, the transitional state is so momentary, the user never notices it, especially for Switches that say “Turning On” or “Turning Off”. Furthermore, these transitional states are not documented as valid in the SmartThings Developer API / Capabilities except for some specific types like Garage Door (Opening, Closing).
So ActionTiles chose not to implement transitional states unless they are in the official Capability Definition, due to (a) the minimal proportionate value of this, and (b) the overhead at the front end of deciding how long to leave Tiles in a transitional state before having to determine and set to the genuine state. That’s non-trivial complexity.
(I don’t actually know offhand how long the SmartThings App will stall on a transitional State. This is important, because there has to be a predictable result when the user taps a Tile that is in a transitional State: e.g., if Tile says “Locking” should tapping send another “lock” Command attempt, or should it send “unlock”, or neither?)
In ActionTiles, we have implemented the transitional mode for Garage Door and perhaps we will consider it for certain critical Thing types that take time to transition, like Lock, in the future.
Back to this Topic:
The solution I proposed is to put the obligation in the DTH to respond immediately with a sendEvent asserting the accurate closed/open (ahem; locked/unlocked) state, by leveraging the ability to do this with only a couple lines of code in the fake Command methods.
Fun stuff!