I have a question regarding mm Unit in an item and in the graph showing.
the item is a number:length type and showing this:
opening the graph, it´s displayed the following, changing the 9,5 mm into 0,0095 mm.
Is this expected behaviour or a bug? Can i change this somehow?
I try to believe this also influences my tries to get a valid value from persitence with “averageSince” which don´t match with reality.
I am on 3.1.0 M3.
It’s going to be something confusing about default units.
Persistence stores numbers without units at all. When data is retrieved later, assumptions have to made about the proper unit.
So far as I know, there’s no conversion for storing - it just strips the unit and stores the number e.g. Item state “4.5 mm” store “4.5”.
First thing perhaps is to look in API explorer at the Item and see what the real state is, never mind what the UI display says (because that can be transformed).
Next, use API explorer to view actual persisted values to verify what is stored.
On retrieval, persistence must try to reconstruct the appropriate unit. There’s a number of places it can look for a unit.
Each individual Item may have a default unit assigned in ‘pattern’ metadata. I think this takes priority, if it is there.
Each type of Item may have a system default unit. Not all types do, but Number:Length I believe does - it’s probably “m” for non-USA folks.
It could look to see if the current Item state has any unit, and use that, but I don’t think it does.
The upshot here is that the assumption of a unit on retrieval might not be the same as the unit when it was stored.
You might run a test in a rule to see what units a e.g. historicState() returns , to see what persistence is thinking here.
Meantime, charting is doing its own thing. Any of these factors might come into play, affecting both charted data and the labels on the axis, they might not match. But find out exactly what persistence is doing first.
thanks @rossko57 for your insights and pointing me in the right direction.
There was no pattern set yet in the state description as the state seemed to be correct. I changed it to %.1f %unit% and the behaviour did not change for the graph ( but below for the value to store ), BUT when i changed to %.1f mm, the graph´s unit seems to pick this change up right away.
This does the trick for atleast the graph and unit conversion, “jumping” from 0,01mm to 10mm :
This is what the REST API in correspondence brings as values for persistence… goes in line with the graph´s change.
{
"time": 1618060200000,
"state": "0.010000000000000002"
},
{
"time": 1618060260000,
"state": "0.010000000000000002"
},
{
"time": 1618060320000,
"state": "0.01"
},
{
"time": 1618060380000,
"state": "4.921749999999999"
},
{
"time": 1618060440000,
"state": "9.916749999999999"
},
{
"time": 1618060500000,
"state": "10.0"
},
My current take away is to work with state description pattern in the form of ( %.2f mm ) as this seems to have two effects:
the values / units in the graphs is ok and the persisted data looks ok. It all is dependent from each other.
So it was storing in metres.
The missing puzzle piece is what the Items actual state was , might still be evident in your old events.log changes.
in the event log every change reported is in mm, here the last example:
2021-04-10 15:03:17.777 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RegenmesserGartenKumulierterNiederschlag24h' changed from 9.8999996185302734375 mm to 10 mm
so comes in in mm, OH is storing the m value as a default value for Number:length, value and so persistence and gaph executed again in m. Setting the item state pattern to %.2f mm changes the behaviour to store and execute again in mm.
The question is, bug or feature…
The bit that suprises me is conversion from state units to system default units before persisting. I didn’t think that happened.
It does make a sort of sense that it persists in the same units that is going to assume when retrieving.
In the end, the persistence worked as intended I think, storing an accurate value. Or rather, storing something that can be accurately reconstructed as a quantity value.
The charting messed up, by assuming current state units should be used with data from persist. (It must have done that to come up with mm)
If it had labelled your chart in m, it would be accurate with only a presentation cosmetic issue, which is the kind of thing we might expect to fix with ‘pattern’.
I would say it’s a minor charting bug, and it should use the same process as persistence to determine units for historical data.