Okay, this the Item you complain of, yes?
You have defined it as a member of gElectricReadingsNIGHT
, and it gets updated by Modbus.
So far as you’ve shown us, that is the only group it is a member of.
Next, persistence.
From your persist file -
So this Item, being a member of that group, gets persisted when your strategy nightTariff
dictates,
From the same persist file -
It’s a cron strategy, and will persist the Item every day at 07:30
And, so far as I can see, at no other time.
No matter how or when the Item changes or gets updated, 07:30 only, just as you requested.
We ought to be a bit more precise here. The system scheduler will initiate this task 07:30, in reality it has to spin up a thread, retrieve the Item value, etc. Let’s assume it takes about 100mS to grab the Item state, but make a note that will vary depending what else is going on.
So, an estimate that what will really get persisted is the item state from about 07:30:00.100
Meantime …
Also at 07;30 precisely you run a rule,
Note that the rule title is a bit misleading, because it never stores anything to any database. That’s okay, that’s what persistence is for.
The rule, which will take a bit of time (of variable length) to get fired up. Then it issues a REFRESH, causing the Modbus binding to make a read poll. That might have to wait for anything active to finish first - a periodic poll, say. But usually will go off relatively quickly, again indeterminate and depending what else is happening.
When your device gets around to it, having assembled the requested data, it responds to the poll.
Now the binding can process the raw data into Item updates and put them on the openHAB event bus.
At last, the Item state gets updated.
Looking in the events.log snips you supplied, that takes anywhere between 90 to 300mS, which seems reasonable.
Now recall your persistence, which started off at the exactly same time, is going to grab the Item state and persist it. We guessed that might take 100mS or so.
Next consider what gets stored if you are lucky, the REFRESH took 90mS end to end.
Then consider what gets stored if are less lucky, and the REFRESH cycle took 110mS.
That’s what I mean by “you have created a race”. Two processes kicked off at the same instant, which one gets to the crucial point first?
Frankly I’m amazed that you ever get the “new” value, I would have guessed persistence would be quicker than a Modbus read cycle.
There’s more than one way you can fix this.