this problem is driving me crazy. I’m running 2.5 M1
In a rule I’d like to compare the state of my vaccumer. Here is the specific part:
when
Item RR_statusType changed
then
logInfo("roborock.rules", "previousState(): " + RR_statusType.previousState().state.toString + " state: " + RR_statusType.state.toString)
Here is the log output:
2019-03-22 10:40:15.183 [INFO ] [marthome.model.script.roborock.rules] - previousState(): Returning Dock state: Returning Dock
2019-03-22 10:42:13.354 [vent.ItemStateChangedEvent] - RR_statusType changed from Returning Dock to Charging
2019-03-22 10:42:13.416 [INFO ] [marthome.model.script.roborock.rules] - previousState(): Charging state: Charging
How come the previousstate is NOT different according to my logInfo() output. As you can see above the state did change from “Returning to Dock” to “Charging”.
There is a runtime problem. It takes a little time for the persistance service to write it to the database and get it back from there.
I did not solved this. Because the time thsi needs is not really clear. If I really need the previous state of a item I changed right now I use a different item for that.
timeline:
item state changes
OH sees this
writes it to the DB
DB needs time to write it
OH previousstate reads from DB (and this is the problem, there is no time sync)
OH has or has not the right previousstate.
If you wait some sec. this problem is gone, but there is no real indicator how long to wait.
thans for offering help, but I tend to disagree with both of you.
@HomeAutomation
Please take a look at my phpMyAdmin screenshot above. You see the states with timestamps.
According to DB the previous state was “Returning to Dock” and 2min it changed to “Charging”. But my logInfo() rule claims the previousState was “Charging”. This cannot be true actually the state BEFORE “Returning to Dock” was “Cleaning”.
@5iver
That might be the solution but does not explain the issue. How come the previousState in my case is just wrong? The state switched from “Cleaning” via “Returning to Dock” to “Charging”. So, the state was always different. It was never a repeating state like “Returning to Dock”, “Charging” and then again “Charging”
The Rule is triggered by changed so you should be using the previousState implicit variable to get the actual previousState the Item was in.
Some states like NULL and UNDEF do not get saved to persistence. It takes some time for values to be saved to persistence. So when you call previousState in a Rule immediately without out sleeping for a bit to give the DB a chance to save the new value the result of previousState is indeterminate. You might get the previous value, you might get two values back.
IIRC the previousState method has two different modes. When you don’t supply true to the call, the method returns the most recent value stored in the database. Depending on timing and the persistence strategy that value could be the Item’s current state, it could be the Item’s previous state, it could be even older.
When you use the previousState method with true, it returns the most recent value stored in the database that is different from the Item’s current state.
Depending on timing and the persistence strategy that value could be the Item’s current state, it could be the Item’s previous state, it could be even older.
Ouch, that’s not good. So in my case adding the “true” will probably solve the issue. I’ll give it a try and will report back!
It’s not wrong… it’s the persisted value of the Item. If you want the state of the Item before it changed, use previousState(true), which is also what you will get from the implicit variable, but without the potential for a timing issue, or due to using a persistence strategy other then everyUpdate or everyChange. You need to use the right tool for the job.
Flarg… I just looked up and people have replied for me… oh well…
The persistence service as a whole is essentially a v1 legacy; it does not really handle UoM. So far as I know, it will store your data, stripped of units. And recover it, assuming units from the Items default? Not sure.
That might present a problem for tools like previousState(true), the recovered value could be 10.0 but the current state 10.0°C, which is obviously different.
Alsp potential to get in a right mess if you change the Item’s UoM - stored data won’t track that.
