Add dimension for calorific value and related unit

[cweitkamp]

• Added dimension for calorific value and related unit

Use Case: Gas suppliers use the calorific value to convert volume (m³) to energy (kWh) for billing.

Signed-off-by: Christoph Weitkamp github@christophweitkamp.de

[Copilot]

Pull request overview

This pull request adds support for the CalorificValue dimension and its associated unit (kWh/m³) to the openHAB core library. This enables gas suppliers to convert volume measurements (m³) to energy (kWh) for billing purposes using the calorific value conversion factor.

Changes:

• Added new CalorificValue dimension interface
• Added KILOWATT_HOUR_PER_CUBICMETRE unit to Units.java
• Added test coverage for the new unit and its conversion behavior
• Integrated CalorificValue into the I18nProvider dimension map
• Added CalorificValue to the XSD schema for thing descriptions

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
bundles/org.openhab.core/src/main/java/org/openhab/core/library/dimension/CalorificValue.java	New dimension interface for calorific value
bundles/org.openhab.core/src/main/java/org/openhab/core/library/unit/Units.java	Added KILOWATT_HOUR_PER_CUBICMETRE unit constant and registered its label
bundles/org.openhab.core/src/test/java/org/openhab/core/library/unit/UnitsTest.java	Added test to verify unit symbol and multiplication behavior
bundles/org.openhab.core/src/main/java/org/openhab/core/internal/i18n/I18nProviderImpl.java	Registered CalorificValue dimension with default unit
bundles/org.openhab.core.thing/schema/thing/thing-description-1.0.0.xsd	Added Number:CalorificValue enumeration value

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[boehan]

Just FTR, as calorific value may have different reference values (volume, mass, amount of substance), which cannot be directly derived one from another, I wonder if it wouldn't be too general to use volume-related as THE calorific value (even though it may be the by far most common in the smart home context). Not saying that the other reference values should be implemented as well, but that they should be kept in mind to not run into a dead end for later implementations.

[cweitkamp]

@boehan Thanks for mentioning it. From my point of view a dimension can have several units even if they are in convertible. For example Dimensionless has units for percent and part per million. Meaning we can add additional units for the dimension CalorificValue like Energy / Mass (e.g. 142 MJ/kg) later.

[boehan]

@boehan Thanks for mentioning it. From my point of view a dimension can have several units even if they are in convertible. For example Dimensionless has units for percent and part per million. Meaning we can add additional units for the dimension CalorificValue like Energy / Mass (e.g. 142 MJ/kg) later.

Ah, okay, my assumption was that the UoM system provides convertibility between units of common dimension. If inconvertible units work nonetheless, it's fine for me (I have no hard opinion on it anyway, just wanted to make sure you are aware of it).
I just wonder what happens, if a channel provides a value of unit x and the item (state description) is set to inconvertible unit y of the same dimension?
BTW, the units of Dimensionless that are defined in OH, are all transformed from ONE, so they should be convertible between each other.

[cweitkamp]

You are right. All Dimensionless units are derived from ONE. With one exception DEUTSCHE_HAERTE:

openhab-core/bundles/org.openhab.core/src/main/java/org/openhab/core/library/unit/Units.java

Lines 96 to 97 in d12b1f8

	public static final Unit<Dimensionless> DEUTSCHE_HAERTE = addUnit((Unit<Dimensionless>) new TransformedUnit<>("°dH",
	MetricPrefix.MILLI(Units.MOLE).divide(Units.LITRE), MultiplyConverter.of(0.17833)));

IIRC the state / label of the items shows something like "Err". But I have to dig deeper if you like a proofed answer for that.