I’m trying to determine the water usage per 10 sec, if water is running. I’m reading the totals of the watermeter so to determine the delta between 2 readings, I’m storing the previous reading, subtract is from the current reading and store the delta in an Item. All Items store their data in a MariaDB sql database.
this is the script in the rule, it gets triggered whenever the total reading is updated.
logInfo("water","WaterDelta rule loopt")
var Number waterTotaal = (Watermeter_watertotaal.state as Number)
var Number waterVorig = (WaterTemp.state as Number)
var Number waterVerschil = waterTotaal-waterVorig
logInfo("water",waterVerschil.toString())
WaterDeltaNew.postUpdate(waterVerschil)
WaterTemp.postUpdate(waterTotaal)
The problem is the postupdate rule of the Item WaterDeltaNew, it updates only 1 out of 10 on average. The logInfo does show all delta in the openhab logfile, so the rule is triggered, and does the calculation.
The WtaerTemp postUpdate also works fine. If I check the WaterDeltaNew Item, it also isn’t updated, so the sql table also isn’t updated.
var double waterTotaal = (Watermeter_watertotaal.state as Number).doubleValue
var double waterVorig = (WaterTemp.state as Number).doubleValue
var double waterVerschil = waterTotaal - waterVorig
How are you verifying this? Note that updates do not appear in events.log, only changes so if the new delta is the same as the old delta you won’t actually see anything in the logs to indicate the Item has been updated.
What is your persistence strategy? If it’s not everyChange then updates to the same value also won’t be saved. Only changes would be saved. If you are relying on the default strategy, that is going to be everyChange.
I can verify the 1 out of 10 by counting the entries of totals (watermeter_watertotaal) compared to waterTempDelta in the sql database. And the items count of waterTempDelta are the same as the sql entries.
My persistance strategy is that every change in item value is placed in the SQL database.
I changed the rule to ‘DoubleValue’ as @bwubwu adviced, and it’s a lot better, I’m now missing only 12 updates of waterTempDelta on a total of 119 readings. Still not perfect but a lot better.
Well, like I said, if the value didn’t change, it won’t be persisted. You should use an everyUpdate strategy or else when ever the value is the same, it won’t be saved.
You’re right… the deltas are most of the 0.001 or 0.002 and I always saw one after the other. Changing the DouvleValue did make a difference because they differ a little bit more. But it didn’t solve it.
So I guess my jdbc.persist strategy should look something like this?
Assuming that’s the only Item you want to persist with jdbc. If not, you’ll need to include them all. You also should consider desired restoreOnStartup behavior and such.
Right, everyChange is only going to save changes. You need everyUpdate.
It should be additive. The addition of everyUpdate to the WaterTempDelta Item should have caused it to do both.
First I imagine you should verify that we are on the right track and that the Item is in fact updating. There are a few ways you can do this. For me the easiest is to open the developer sidebar (alt-shitf-d) in MainUI and set up a filter for WaterTempDelta. You should see all events on that Item as they occur.
You can also change the log level of the ItemStateUpdateEvent logger in log4j2.xml to INFO and Item updates will appear in events.log.
You can also trigger a rule based on updates to that Item and log something.
HI @rlkoshak The value calculated is updating, I already logInfo the result value in the logfile and it does show up there, so it updates. And when the same value is calculated, it doesn’t update the Item, different values do update the Item. I checked that by comparing the logfile Info messages to the actual database table and the Item graph in OH.
And if I change the default strategy to everyUpdate, it does update the Item and the database, but also 150 other Items which is a little bit too much
Could this be a specific MariaDB persitancy problem??
There is a lot that happens between your rule and your database. We know that your rule updates the Item whether or not the value has changed (right?). But we don’t know if the update event ever hit the event bus. We don’t know if the event was received by the persistence add-on or if it was received it was rejected for some reason.
Looking at the event bus logs will at least confirm that the event isn’t being stopped there. Next step will be to put the persistence into trace logging and see what it does with the event when it receives it.
In that case, my understanding on how the strategies work may be wrong. Show the full .persist file with everyUpdate applied to that one Item.
logInfo("water","WaterDelta rule loopt")
var Number waterTotaal = (Watermeter_watertotaal.state as Number)
var Number waterVorig = (WaterTemp.state as Number)
var Number waterVerschil = waterTotaal-waterVorig
logInfo("water",waterVerschil.toString())
WaterDeltaNew.postUpdate(waterVerschil)
WaterTemp.postUpdate(waterTotaal)
The Item graph in OH doesn’t show the values at 16:02:
We don’t know that yet. All we know is the value wasn’t saved.
But the fact that it works when you change the strategy for all Items to everyChange and everyUpdate implies that the Item is being updated. The Item update event is completely independent from what persistence is doing.
So put the jdbc add-on into trace logging level and see what it does when it sees an update that Item.
But I think I solved my problem. The Item I used was a manually added Item without a Channel/Thing. After changing to another Item which had a Channel/Thing it worked like it supposed to work. So there’s a diffenrence in acting between the 2 versions of Items.
I’m glad you have it working but the Channel Link shouldn’t matter. An Item is an Item and Persistence doesn’t know anything about how an Item is updated.