If 'device' functioned like 'state' in ST, this DTH would be failing 100% of the time. It appears in ST device.currentValue attribute is a realtime fetch, or it works like "instant update" atomicState .
From the ST docs (for the record, I don't look everything up, I just happened to already have the ST docs open ) :
The current or latest state for an attribute value is the most recent value the device has reported to SmartThings. It is not calculated by polling or otherwise directly communicating with the device.
For example, someDevice.currentValue('someAttribute') will get the most recently reported value for the specified attribute. If the device has malfunctioned, or the SmartThings Hub has gone offline, it is possible that the value returned is not consistent with the physical status of the device.
So in this instance, if I am thinking correctly, the question is when does HE update the state after the lock() command is issued to the device.
Might be a question for the HE guys I guess, but I would have thought AFTER the instance execution of the driver. But I would have thought that on ST as well since it is supposed to read all states from the DB at the beginning, and write them all at the end... So external changes during execution shouldn't be seen. But based on your comments on how it worked in ST, I am obviously wrong.
I haven't run into a scenario where the timing mattered this closely for me. I need to noodle on this some more.
I think this line might speak for itself. It doesn't say "most recent value after the thread/instance that caused the attribute to change." This would be a very important nuance to note here. Instead it very clearly says "most recent value reported" period.
@JasonJoelOld I agree with what you're saying when dealing with state variables... But I suspect it's not the same thing. When you refer to state I think you're referring to a state variable, IE:
state.variableName = 'Some Value'
But that's not exactly the same thing as a device "attribute" like locked/unlocked or on/off, etc. They may be internally stored the same way perhaps, but they are exposed differently. For example, here's a basic dimmer switch device in HE:
On the right you have the "Current States" section which makes up the attribute values that are accessible using device.currentValue("attribute name")
At the bottom you have the "State Variables" section which lists the state variables that are only accessible within the device driver code using: state.stateVariableName
Again: maybe all of these are stored the same way in the same database. But they are definitely exposed and handled differently in the UI and from within Groovy.
I am definitely thinking in a state variable context. Maybe that doesn't apply here. If not, then I've just confused the situation more, instead of helping.
I guess I'll think some more before typing all my thoughts.
Yes, we cache these values for performance sake. typically you never need to access the value that you just sent.. ie in your example you are asking for the armMode but you just set the armMode 2 lines above.
If you really want to do this, or you need the non-cached current value, pass true as the second parameter:
Have you tried the sendevent with isStateChange: true, and no delay? I saw the commented out sendevent has statechange, but not the test with no delay.
Just curious as In ST that was needed if you wanted tile status to immediately update... Not sure if it has a similar effect in HE - might not.
So I guess we kinda just went along with what you were asking instead of asking what you are trying to accomplish. Yes, sendEvent is not instantaneous. It creates a request that is put in a queue and a separate thread picks up and runs. For human consumption this happens pretty much instantly, in the computer however it can very easily run the next line of code before any of that happens.
So I'll start over. What are you trying to accomplish by setting the armMode to a value and then looking up that same value again? can you post the full code and let us know what that method is trying to do?
It an existing ST DTH sometimes armMode attribute is updated in a routine
other routines subsequently test armMode and expect the most recent value.
So is the sendEvent is queued, and there is no enq / deque funtion that I am aware of to serialize a subsequent fetch of the data, it's hit or miss on getting the most recent value.
Could do it with states (or even a local variable?)...
Internal states get updated immediately in memory for the instance, so if you set state.armModeX (or whatever) on the line before/after the sendEvent, you can reference that all you want and it would be up to date...
I'm attempting to convert a working ST DTH to a HE Driver. Meaning as few logic and code changes as possible. I posted my functional workaround above that avoids this entire issue without using state.