Using the new Currency Units of Measurement in 4.1

J-N-K · January 5, 2024, 8:29am

Looks like a bug. I also found an issue when converting energy prices.

laursen · January 5, 2024, 9:00am

See also here for additional information:

Comment by jlaur to [UoM] Add currency handling

openhab:main ← J-N-K:feature-currency

Thanks for rebasing, @J-N-K. I have now built `org.openhab.core.config.core` and… `org.openhab.core` from your fork and replaced the JARs in my installation from latest snapshot. Configured provider: ![image](https://github.com/openhab/openhab-core/assets/19519842/0ec86b77-38ea-4eab-9a4d-70071e6034da) (I'm wondering if this should be part of regional settings rather than a separate unit settings - do you expect more unit settings since you put it separately?) Created an item: ```yaml label: Currency Item type: Number:Currency category: price groupNames: [] groupType: None function: null tags: [] ``` ![image](https://github.com/openhab/openhab-core/assets/19519842/7eebaaa6-6acf-42ca-9de1-71063a88ea8a) And first tests: ```shell openhab> openhab:update CurrencyItem "100 kr." Update has been sent successfully. openhab> openhab:update CurrencyItem "200 DKK" Error: State '200 DKK' is not valid for item 'CurrencyItem' Valid data types are: ( DecimalType QuantityType UnDefType ) openhab> openhab:update CurrencyItem "300 $" Error: State '300 $' is not valid for item 'CurrencyItem' Valid data types are: ( DecimalType QuantityType UnDefType ) openhab> openhab:update CurrencyItem "400 €" Error: State '400 €' is not valid for item 'CurrencyItem' Valid data types are: ( DecimalType QuantityType UnDefType ) openhab> openhab:update CurrencyItem "500 kr" Error: State '500 kr' is not valid for item 'CurrencyItem' Valid data types are: ( DecimalType QuantityType UnDefType ) ``` Result: ![image](https://github.com/openhab/openhab-core/assets/19519842/277ac238-fc2e-46c5-9ff9-d0718dac17b4) Besides not being able to use currency code for the update, I think it behaves as I would expect. I assume the error when trying unit symbols $, € and kr. is because I have configured DKK indirectly through `LocaleBasedCurrencyProvider` and because I don't have any `CurrencyProvider` that can convert DKK to any of those? _EDIT_: After changing to fixed currency SEK, my existing state of 100 kr. (DKK) changed to 100 SEK. Then: ```shell openhab> openhab:update CurrencyItem "200 kr" Error: State '200 kr' is not valid for item 'CurrencyItem' Valid data types are: ( DecimalType QuantityType UnDefType ) openhab> openhab:update CurrencyItem "200 SEK" Update has been sent successfully. ``` So when using the `FixedCurrencyProvider`, currency **code** can only be used as unit when updating state, and is also shown in the UI, whereas when using `LocaleBasedCurrencyProvider`, currency **symbol** is used for both. This seems inconsistent, is this expected? Also, is it expected that the state value is kept, but the unit is changed, when another currency is configured? Unit metadata doesn't seem to have much impact: ![image](https://github.com/openhab/openhab-core/assets/19519842/ab399b03-e688-4ee2-bb0a-4ac49a610855) When eventually adding a new `CurrencyProvider` implementing currency exchange, how do I select in the unit settings that my global/system currency is DKK and at the same time select which currency provider to use? Or do you need to define the currency on each item in this case?

github.com/openhab/openhab-addons

Review by jlaur in [energidataservice] Provide work-around for currency issues

openhab:main ← jlaur:energidataservice-currency-workaround

I see this only as a work-around to ensure reliable state updates in 4.1, would …you agree? And do you see anything in all this that is worth creating an issue for in core? We currently have the limitation that the UoM system know only one currency. When this will change, I would somehow expect: - Always being able to update state for known currencies, even if there is no currency exchange service provided/installed - without risking `IllegalArgumentException` being thrown. With known currencies, all I mean all defined by ISO 4217. - In this case IMHO it would still be better to keep the source currency unit rather than overwriting by user configured currency unit without converting the amount. I know this contradicts 4.0 UoM because we cannot enforce "target unit", and I don't have a good proposal for tackling that. It's different, because we can always expect to be able to convert °C to °F, but we can't always expect to be able to convert DKK to EUR. And we cannot make the assumption that exchange rate is 100, because then prices will be plain misleading. - Being able to update state with currency code as unit rather than symbol. When all currencies will become available and we are able to convert between them, symbols can become ambiguous as previously discussed.