[SOLVED] Previousstate not different than current state

Hi all,

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:

        Item RR_statusType changed
        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”.

This is what I see in phpmyadmin

What persistance service do you use?

I will not work with MAPDB and RRD4J.


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.

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.

Use <item>.previousState(true) to get the previous state that is different than the current state. I have not seen this issue in the new rule engine.

thans for offering help, but I tend to disagree with both of you.

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”.

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”

Is mariaDB your default persistance service? If you have more then one you must give this as a parameter to previousstate(true, “JDBC”)

yes it is, but it says “mysql” in paperui. Should be fine though, correct?

yes, should ok. I use not the native binding I use the jdbc.

Please do a simple test and try to read the date of the change from persistance.

item.lastUpdate(“mysql”) maybe there is a hint what value you really get from persistance binding.

You guys do know that the imlicit variable previousState is up to date and uninvolved with persistence?

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.

Thanks again to everyone who’s helping here!

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!

Actually, in your case, using the previousState implicit variable is the correct approach.

sorry, I’m not a prof. developer You mean without true? So why doesn’t it work then? :wink:

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…

1 Like

See the docs for implicit variables. Do not call the method at all.

logInfo("roborock.rules", "previousState(): " + previousState + " state: " + RR_statusType.state.toString)

I am having this same issue. No matter what I do I always get back the current value


I found that when I have my item defined as a Temperature this always happens
Number:Temperature HouseAverageTemp

But not when I have my item defined as a standard number
Number HouseAverageTemp

I am not sure why, so I just removed the Temperature from my item. Not and ideal solution, but it worked for me.

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.

More details here…

For now, your workaround is the best you can do.