Wow, go to a movie with the family and get a night’s sleep and this thread exploded!
You keep saying this but I’m not sure I completely agree. Most measurement units are relatively arbitrary. Somewhat recently a number of SI units were retconed to be based on physics, but they are still arbitrary. There is nothing in the universe that says a meter must be exactly the distance light travels in a vacuum in 1/299792458 seconds. Why 1/299792458 seconds? Because that’s pretty much exactly the length of a meter prior to it’s redefinition.
So no, the units are not defined by physics. They are defined by convention. Most of the world exclusively uses SI units. Some parts of the world mostly use imperial units (which have not ben retconed and are still based on historic conventions) and some parts of the world that use SI units for some things and imperial units for other things.
I agree with @rossko57, it is not cut and dry.
That’s what I thought too, and it’d still be a problem if the binding doesn’t support units. But in the case where the binding does support units it is converting the °C to *F as expected. Even the charts are correct. To be specific,
- A plain number representing °C is published to an MQTT topic.
- I set the MQTT Channel’s
unit
property to “°C” - I set the pattern in the State Description to “%.0f °F”
The value is converted from °C to °F and displayed with °F.
This is a bit of a concern of mine as well. But I haven’t sat down yet to think through whether or not this is a really big deal or not. My initial concern was repeated conversions between units on every restoreOnStartup which could result in the value drifting but I don’t think that will be the problem. At max only one conversion should occur on that initial save.
My understanding is:
- there is a default unit for every Number:X type Item
- that default unit is based on the locale (if you are in most of the world it means you’ll get SI units as the default, in the US and a few other places it means Imperial Units)
- when a value is persisted, no matter what units the Item is carrying, it will be converted to the default units for that Number:X type
- when restored, the Item’s state will carry that default unit, not what ever unit it had originally nor the unit defined by the state description
- however, you can change the way it appears with the state description pattern per usual and you can use
toUnit()
on theQuantityType
to convert it to a desired unit in a rule
That’s the way it’s always worked before.
I’m not so sure it always works that way now though. For instance, if it still worked that way all the time, what’s converting my temperature Item to °F? I have confirmed that persistence is saving the converted value.
The binding is delivering to the Item °C. Maybe temperature works different from length?
I wouldn’t put too much weight on the docs right now. I’m not sure we ever really understood UoM well enough to make the docs correct in the first place and they haven’t been updated since these latest changes.
Not in rrd4j.
This is a good argument for normalizing the values to the same unit before persisting.
But what’s the precision of the database?
I can’t remember, it’s either feet or yards. A mile is closer in scale to the sorts of things you would measure with km. I tried to suggest defaults for the imperial units that were close in scale to the SI unit defaults.
It probably doesn’t. But a lot of systems will punt and just represent decimal fractions instead of inches and fractions of an inch. So you’d get something like 25.5 ft instead of 25 ft 6 in. Though it’d be pretty awesome if it did it right.
That’s not what @rossko57 means. What he meant is that the precision and range of BigDecimal doesn’t matter because the range and precision of the database itself is going to be less.
It depends. BigDecimal gets its range and precision by using an alternative to IEEE-754. But pretty much all databased I’m aware of use IEEE-754 to represent floating point numbers. So myBigDecimal.toFloat()
or toDouble()
gets called to convert from the internal BigDecimal format to IEEE-754 which is limited in precision in strange and interesting ways.
If it were feasible at all I would push for that approach. But as long as we support rrd4j storing the units with the values is simply not feasible.
This! I hate inconsistency more than anything. The behavior of UoM seems to be inconsistent. There may be good reasons but I think we need to look through the code and set up experiments to exactly nail down the current behavior and then move on to what the behavior should be.
It would touch pretty much everything, core, add-ons, and require a pretty significant rework on charting in MainUI.
It may be heated but, at least for now, I think it’s been productive.
However, if this starts to spin out of control with no progress, I’ll close it down. We’ve had threads run out of control before and caused harm to the community. I don’t want to let that happen again.