[Solved] postUpdate not synchronous. Is it on purpose?

Setup, Configuration and Use Scripts & Rules
1

When using postUpdate within a rule, I’m experiencing an indefinite amount of time until a state read from the item actually shows the updated value.

Example:

postUpdate(p1_start_time, new DateTimeType())   //update item p1_start_time with current timestamp (i.e: was previously x, is now y)
...
logWarn("test", "test 1 {}",p1_start_time.state)   // shows old value x
...
logWarn("test", "test 2 {}",p1_start_time.state)  // may show value x or y
...
logWarn("test", "test 3 {}",p1_start_time.state)   // shows value y
...

Log output for test 1, 2 or 3 may still show the old value for the item’s state (before the postUpdate), with varying results, especially dependent on the length of time the intermediate statements take.

Probably this asynchronous activity is expected by postUpdate, but I’ve written my rule code so I use items in a way as global variables, and not too sure how I can work around the problem other than reading to local variables at the start of a rule, working on them, and only postUpdating at the end of the rule.
I’d have expected a postUpdate should first synchronously somehow mark the item’s state as dirty, and only when the update is complete (asynchronously), allow reads from it.

1 Like
2

postUpdate and sendCommand are processed asynchronously. You cannot expect the state of an Item you just postUpdate to to reflect the new state immediately. It takes some milliseconds for the update to get processed round trip.

That’s fine, but if you change the Item in a Rule, you already know what it was changed to. So just use a local variable inside the Rule. If other Rules or future runs of this same Rule need the data too, then also publish the data as an update to the Item.

Using Items to store variables makes good sense when that variable needs to be preserved over multiple runs of the Rule or across multiple Rules. If the value is only used by the one run of the one Rule the using an Item is a bad idea. Use a local variable instead.

It does not work like that and frankly if it did work like that it would be close to a disaster for other parts of how Rules work.

I’m not recommending this as a solution, but you could also add a Thread::sleep after you call postUpdate, but that can cause problems as well.

So your proposal of using local variables and then calling postUpdate is probably your best bet.

1 Like
3

Thanks, yes, I use the variable across various rules, so will figure out a way to work locally and do the postupdates at the end - just worried about rules updating values in parallel.

Regarding the async-write with a temporary read-lock on the item, was just thinking of queuing the reads while this happened, but I totally trust your view on it being a bad idea.

4

Sometimes it’s worth having a hard think about rule structure. Say something needs to happen after state updated. Perhaps an approach is to do that something in another rule, triggered by the update.
Doesn’t always work out, but often it will.

1 Like