previousState true/false always seems to be a bugbear.
Often it comes down to looking in the wrong database, but you seem to be on top of that here by specifying “influxdb”.
I do not know but believe the comparison will be with current Item state I.e. if most recent record is 1.11 and Item is 1.12, both true and false will return the same record. What happens if current state is 1.110 I do not know. Log state out for the rule execution moment.
Is this a Quantity type Item? There is scope for more confusion with that, as the persistence service must do a conversion to store numeric only, without units.
We are talking about Celsious values and because it is the setpoint they are in a range from 4 to 22. In my tests I only used values without decimals. The typical different values in my case are, 6 and 20. 6 will be set when windows gets open and 20 will be restored when the windows gets closed. This is because it was the setpoint value before the window opened.
I am not able to follow Your point about quantity types. In my understanding the previousState function look up the datastore for the most recent value (current value). From there it tries to find a value that is different from the current value. This is all done after the possible necessary conversion took place. Because we are only looking at values in the datastore.
I could be totally wrong, it is just how I anticipate from the docs how it works.
I would love give any helping hand to get this fixed. What I know from my tests is that all value changes that I made are in the datastore and I am able to query them with .historicState and they do have the right timestamp associated with them. It seems to me that the function somehow lost the desired functionality.
Well, that would be incorrect. You might have a persist strategy that saves only once a day, for example, and then we’d expect “current state” to be the current state i.e. the state of the Item. Not recovered from database at all.
So, to unanswered questions that may help understanding. Bear in mind we can’t see what you see, and have none of the data, states, or timestamps referred to so far.
What is your Item type? You’ve said it represents temperature but that still leaves likely candidates as either Number type or Number:Temperature
What is your persist strategy for this Item?
Would you add the Item state logging to your rule?
Can we see your actual output here?
There is possibility of a bug about false “difference” when Item current state is 11.0°C and stored data is 11.0, also when Item state is 11 and stored data is 11.0
Let’s explore this possibility.
I did a whole check of the environment, after a couple of days not looking after it. In the end a not successfully deployed influxdb.persist file caused the issue. Many thanks to rossko57 who asked the right questions,
btw. my Item type is Number:Temperature and I found no issues even with decimal numbers like 18.5 compared to 18 etc. Seems to me that all of that works as expected.
The only thing I am curious about is that my influxdb is installed and no influxdb.persist file told the system to save values to influxdb, but when I explicitly want historic values from influxdb no warning is in the log.
New for OH3; the “default persistence strategy”.- in the absence of a relevant xxx.persist file, each installed service will persist (and I think restore) everything it can, every five minutes or somesuch.
