The chart is going to show what’s stored in persistence. At this time charts are not UoM aware and no conversion takes place between what’s stored and what’s shown based on the State Description.
If you want it to show km in the chart, I think your only option is to make it so km is what’s stored in the database by setting the unit metadata on the Item to km. That will convert the Item’s state to km before it is saved to the database and charting will show the correct units.
Thanks, I see. It’s working changing the items unit and chart display is fine … almost!
First: I develop bindings like
mercedesme - Standard Length Kilometers / Miles not meters / inches
sensorcommunity - Dimensionless Percent or Decibel
solarforecast - Power kW not Watt
Second: I’m not defining everything in .items files. I use Model and Add Equipment
And now the elephant is in the room -
Example below : First update comes with Watt and extreme high value (First Picture: 12h view) and after changing unit looks smooth (Second Picture: 4h view).
Suggestion:
I honestly don’t know what it takes to build the chart. But wouldn’t it be possible to give the chart for each item an own unit of measure? No matter if it’s kW or km? It’s the setting by the user.
All I can say is it was deliberately written such that bindings cannot supply the unit metadata, only the state description. I personally didn’t like that choice and said so on the thread but the maintainers disagreed.
I don’t understand how this is relevant. Do you list this because it takes an extra step to set the unit when creating Items that way? It shouldn’t be challenging to add unit to the Model. If you do create an issue for that, throw in adding unit to the “create equipment from thing” form too.
Changing the unit on the Item doesn’t retroactively change the values stored in the database. And the database doesn’t store the unit at all. So if a value in W made it into the database and you later change the unit to kW, there’s nothing to tell OH that that the old value(s) are in W so it treats it as kW.
The units of measurement are all implemented in Java on the server side. The UI (where charts live) have no access to the logic that converts between units.
2, The chart is built from a JSON formatted time series (datetime + value). You can see what it has to work with from the API Explorer Persistence endpoint.
Given the above, I think it could be supported but it would take a change to both openhab-core and MainUI. In core, the /persistence/items/{item name} endpoint needs to be enhanced so MainUI (or any client) can send the units it wants the values returned as. Then MainUI needs to be updated to ask for the units it wants.
A quick and easy implementation would be to have MainUI just pass the state description units in it’s request, and that should be the default behavior anyway. If that unit is different from the unit metadata on the Item, core iterates through the results and converts each from unit to the passed in desired unit before returning the JSON to MainUI for charting.
Once that’s working it’s not too far to add a “unit” property to the Charts so you can supply yet a different unit from unit and state description.
It’s technically feasible, so long as you can supply the PR or find someone to work it. An issue is the place to start though. I think this is useful enough one of the maintainers might volunteer to add it. But it’ll take some coordination.
Sure, this will solve the setup. But I think the problem is deeper (see also last quote).
Assume you’re a normal user without deeper knowledge, please try .
You install a car binding and setup everythig. What’s your assumption of Unit State of Charge? It’s Percent right? But it’s shown as 0.83 one. Question already asked. I as a user would think "Dumb Developer! Cannot present the right unit and now I have to do it on my own. "
Now change your role and assume you’re developer of this binding.
Will you describe in readme "Dear user, if you add items to the channels please take care of units for mileage, range, trip computer fuel level, state of charge, …? There’s already enough to implement to discover i18n and present miles or kilometers. And after that mileage is presentf in inches?
There must be a way to define it as binding developer.
And of course the user can overrule afterwards. State of charge shall be per mill - feel free to change as you describe above! But don’t bother the 99,9% of users which are expecting kilometers, miles and percentage!
Description above shows how to setup. But I have items for approx 4 years with nice data inside, e.g. my driven kilometers. Now it’s converted into meters for all these years and I cannot change it anymore, right?
That’s my origin question - how can I dsipay a chart with my driven kilometers, not meters.
Since neither the database nor the charts know anything about units, you’ll have to ensure all the values in the database are stored as km. And the only way to do that, for now, is to set the Item unit metadata.
If there are values in the database that are of different units, you’ll have to manually correct those entries or remove them so all entries are of the same unit.