It seems to me, that the above aprove just works well until openHAB3 gets restarted 
I suspect the restore on startup causing messed charts because it restores derived values from rrd4j persistence instead of the last counter readings:
Explanation:
When using such persistence definition (example taken from openHAB3 rrd4j documentation):
ctr24h.def=COUNTER,900,0,U,60
ctr24h.archives=AVERAGE,0.5,1,480:AVERAGE,0.5,10,144
ctr24h.items=Item1,Item2
… then openHAB persists actual counter values but retrieves derived values which equals the difference of the persisted item value per time slot.
If these retrieved values are used for restore on startup, then a item will be set to a derived value instead of the last known counter value! This low derived value afterwards gets persisted (policy every-change/every-minute) and when the next real reading from the counter comes in, the difference to the former value will be huge compared to the tiny (derived) increments to be retrieved from the persistence service.
This messes up any counter-charting when openHAB’s startup is included in the chart’s period …
Well, the documentation already warns about that behaviour:
Please note that the persistence extensions will return difference instead of the actual values if you use this type; this especially leads to wrong values if you try to restoreOnStartup!
O.k., I think I understood what’s causing the issue. But how to circumvent?
In openHAB2 I simply would not have included these items in restore on startup.
Is there an option in openHAB3 to prevent an item getting “restored”?
EDIT: solved here [solved] [openHAB3 persistence] How to PREVENT "restore on startup"? - #4 by curlyel