Currency type UoM

[mstormi]

I noticed there seems not to be any UoM type to reflect currencies or "money" the dimension is.
With dynamic power tariffs and such raising, these should be added fast before we have binding devs and users embark on any type of workaround in rules.

Related: #983
Related: #3282

[rkoshak]

The challenge is exchange rates change so fast that any conversion will by necessity need to reach out to some cloud API. That would make currencies work completely different from all the other units which have a fixed conversion calculation.

Given that I wonder if UoM is the correct or even a feasible way to handle this. Maybe something closer to how OH handles TTS or configs or a binding would be more appropriate.

Some implementation questions:

• Do we know of a cloud based service that's free we can use for conversions?
• Support for crypto?

[J-N-K]

https://exchangerate.host/#/#our-services

Looks like a nice one and easy to integrate. But there are indeed a lot of questions regarding the modeling.

[mstormi]

Oh dear, I was just thinking of a static Number:Money data type in the first place.
But of course I won't hold you back from going anywhere beyond.
Exchange rates are probably better handled through some binding, though.

[J-N-K]

I had a look at the PR linked above. It proposes adding a new numeric type MonetaryType besides QuantityType, DecimalType and PercentType. To be useful we would need another type PriceType=QuantityType/MonetaryType or similar. This could then be used e.g. to calculate the cost of one run of the dryer by multiplying the consumed energy with the current energy price. This sounds rather complex. OTOH including money in the current UoM (which would automatically allow doing these calculations because composite units are already possible) would sort of reinventing the wheel.

[J-N-K]

@kaikreuzer I think the currency issues should be discussed here.

I found an interesting JavaDoc for AbstractUnit which made me wonder if we need it that complex:

The class represents units founded on the seven SI base units for seven base quantities assumed to be mutually independent.
For all physics units, unit conversions are symmetrical: u1.getConverterTo(u2).equals(u2.getConverterTo(u1).inverse()). Non-physical units (e.g. currency units) for which conversion is not symmetrical should have their own separate class hierarchy and are considered distinct (e.g. financial units), although they can always be combined with physics units (e.g. "€/Kg", "$/h").

And this is of course correct, the exchange rate for €/$ is not the same as for $/€, because buying and selling has to be treated differently. But do we want it that complex of can we assume that (€ to $) = 1 / ($ to €)? In that case it would be much simpler and we could extend AbstractUnit and use much more code that is already there.

[spacemanspiff2007]

Wasn't the initial use case more something like e.g.
My energy tariff is 0,3€/kWh and the dish washer run used 2kWh, how much did it cost. So €/kWh * kWh = €
It would be enough to make the respective currency symbols available to UoM but without conversion between currency symbols.
I think nobody would expect openHAB to automatically convert between e.g. € and $.

But if the currency symbols are available wouldn't it be easy to have a binding provide the factors $/€ and €/$ e.g. through some exchange API so conversion can easily be done in a rule.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh4-uom-price-dimension/148332/2