It is possible and likely that sometimes one command can result in more than one update. Since you are using everyUpdate to save you will get values saved.
So the questions I have are:
would everyCommand or everyChange work for you which will filter out these duplicate entries?
if not is there any pattern for when the duplicated entry shows up in the DB? For example, at certain times, the same command, etc?
I am late to this party, I know. I just stumbled across this, because I also had the problem with duplicate entries. Changing the persistence strategy from everyUpdate to everyCommand solved the issue for me. I do want to store the value, when it is explicitly set to the same value as before, which is why everyChange is not working the way I want.
So thank you for the helpful input here.
Question (maybe, @rlkoshak - you could answer this):
Is there a reason, that everyCommand ia not listed as a valid option on the Persistence documentation page?
I think it would be helpful, if it was included there.
If nothing speaks against it, I will try to put in a change request for that page (which would be my very first contribution
Don’t confuse command with state.
A command to an Item may result in a state change at some time, such state may not be directly related to the command (e.g. INCREASE giving 75%), or no state change may take place at all.
I don’t think any of the persistence services have ever stored any commands at all.
The OP’s problem was that he stored all Items on everychange (including his AlarmHist Item) and also stored AlarmHist on everyupdate, so storing it twice for every change (because you must have an update to get a change).
The persistence service was doing what was asked to do…
What @rossko57 said. It doesn’t make sense to store commands. The command may not even be savable to the database. To elaborate on his example, how would one store INCREASE in a database column of type Integer? Furthermore, it’s the binding that usually interprets what the command means and updates the Item’s State as appropriate. So it isn’t until the Item get’s updated that persistence will know what to store in the database.
Thanks for the quick reply - the difference between the command and the resulting state is now clearer to me and I realize, I have not been reading carefully enough.
Just out of curiosity: you talked about
But there is no persistence strategy called everyCommand - right? I changed the strategy to everyCommand in my .persist file which solved the duplicate updates.
But I realize now, that this just “disabled” persistence for this item in the respective line. But as I have the item elsewhere (as part of a group), it is still persisted via that line - just once now.
DOH!
I too am constantly learning about the ins and outs of openHAB. I now have two years more experience than I did when I wrote that. If I had a dime for every time I’ve said something incorrect on this forum I could quit my job and do this full time.
There is no everyCommand strategy because it doesn’t make sense.
