I read OH4 annoucements regarding breaking changes in UoM in OH4. No complain about the new handling which is from technical point needed.
As a Car binding developer I still have a question regarding the region of hte user and the corresponding display of units of that region.
Situation in OH3
Carr binding is recognizig the Number:Length is Miles or Kilometres from the backend. Configuring channel-types with %unti% is always displaying the delivered Unit.
Situation in OH4
The bindig is still delivering Miles or Kilometres from backend and the channel has the correct value in metres.
But the user wants too see his values based on the configured region.
What shall I deliver in my binding project as channel-types.xml to reflect the correct UoM based on the cofigured region?
I can enter km as shown below to satisfy European customers - this works!
Unfortunately there was a deliberate decision to not allow bindings to supply unit metadata. You can supply actual units to the State Description Pattern but that’s just going to change the how the Item is shown.
The end users will have to supply unit metadata manually where their desired unit does not match what the system default is (which I think is feet for Number:Length when Imperial is chosen and meter for Metric.
Exactly this manually is bugging me. I’ve to tell each user of my Mercedes binding to change mileage, ranges, pressure (common is bar)…and so on.
There should be something possible like this (keep in mind, only display!)
system default - fine, used as standard
binding default - binding default - You and I know that mileage isn’t shown in metres / feet
user setting - user shall be able to define it’s own pattern and overwrite everything
To be honest from the mentioned Interface I not able to derive what you mentioned. I’m also not looking for a hack which is overwriting system defaults. If the problem is accepted as valid there should be proper solution for all - you mentioned already MyBMW but VW, Reanult, Tesla, have definitely the same issue.
What is needed is a method to more easily define the default state description in code. As it is on channeI type level, it is more convoluted then needed. It is missing from channel level. I would still vote against messing with the default unit in a binding, as that impacts much more than visualisation. It also messes with persistence, REST API, rules etc. And don’t forget that one item can be linked to 2 channels from different bindings, creating potential conflict. If it is only default visualisation, it is easy to override. All of this led to the changes in OH4.
I actually think you need less channel types doing this. You need one by unit. All the rest can be defined dynamically on the channel (including label and description) and will take precedence from there. So you will have less channel types, and your 9 channels will be created dynamically instead of defined statically.
That‘s not the point. You want to set the units in the binding „globally“, not per item. So you have to identify the users perference (regional settings) and transform what the api delivers to that unit.
Just to be sure: don’t take my statements as offensive:
No, fully disagree! The Car is Master => not openHAB!
Again no offence - I don’t care about about the regional settings of openHAB. See below pictures what I can configure for my german car. If Fahrenheit is configured please display Fahrenheit"!
But I understand your proposition
99,999 whatever percent of the users will use complete Imperial or Metric system based on region
0,001 whatever percent of users will have a fancy combination of measurements
Main Point is with the above solution we’re covering all possibilities!
I don‘t, of course😉
But i think, the only master is the user, not the car nor openHAB. Therefore, no matter what is configured in the car, openHAB should display what the user wants to see, and that is, from my perspective what he/she configured in the regional settings.