Another question...
When a device attribute is updated by a sendEvent, is the new value immediately available to all threads that can see the attribute, or is it like the state variables and only available to other threads when the updating thread terminates?
Example... if attribute named "position" has a value of 0 when a thread starts, and the code does...
sendEvent( name: "position", value: 100 )
log.debug("Position value: ${device.currentValue("position")}" )
...will the log message show 0 or 100, or does the value of "position" remain zero until the thread terminates, even for the thread doing the sendEvent?
Use
log.debug("Position value: ${device.currentValue("position", true)}" )
instead, otherwise you’ll get the cached value instead of the value that was just written to the database. (Most time the cached value is what you’ll want, but in this instance…)
1 Like
I made the changes to set skipCache to true on all the messages, but still got unexpected/inconsistent results.
I wrote a test function to try to better understand this. The only way I got the expected results was to put a pauseExecution(1000) call after every sendEvent() call. My guess is the pauseExecution time could be a lot less, but I didn't try any other values.
Does this mean that the sendEvent function is an asynchronous thread, so when the driver code gets control back from the sendEvent call, the database might not have been updated yet? If so, is there a way to make sendEvent synchronous? If sendEvent is not async, what else could cause what I'm seeing? I can post the test code and log results if it helps.
Edit: Turns out there are quite a few posts about this scenario. Based on what I read, the code is working as expected with/without the pauseExecution.
