Issue with Quantity of temperature since upgrade to OH4.1.1 from 4.0.4

The following code worked fine in OH4.0.4 but doesn’t in 4.1.0:

deltaTempGradient = Quantity('186' + 'K');'deltaTempGradient: ' + String(deltaTempGradient)));
deltaTimeGradient = Quantity('80' + 'min');'deltaTimeGradient: ' + String(deltaTimeGradient)));
heatingGradient = (Quantity(deltaTempGradient).divide(Quantity(deltaTimeGradient)));'heatingGradient: ' + String(heatingGradient)));
actualSetpoint = items.getItem('Remote_tutesOpenHAB_Gateway_Item_PLC_11_TSoll_Hauptschmelze').state;'Setpoint: ' + String(actualSetpoint)));
actualTemperature = items.getItem('remote_PLC_11_Item_PLC_11_TIst_Hauptschmelze').state;'actualTemperature: ' + String(actualTemperature)));
actualDeltaTemp = (Quantity(actualSetpoint).subtract(Quantity(actualTemperature)));'actualDeltaTemperature: ' + String(actualDeltaTemp)));
timeNeededToHeat = (Quantity(actualDeltaTemp).divide(Quantity(heatingGradient)));

but now it behaves a bit strange, but explainable:

to explain what happens:
heating gradient gets calculated correctly 186 K / 80 min = 2.325 K/min
the substraction 215°C - 215°C = 0°C is somehow right, but it’s not… The result of °C - °C is always K[elvin], even we use it in language different, the difference between 18°C and 19°C is exactly 1 Kelvin.
And in the followup, OH4.1.1 quantity interpretes 0°C correctly as 273.15K and does the operation:
0°C [273.15K] / 2.325 K/min = 117.483870967… min

I don’t know how it did it before, but it worked correctly resulting in 0 min or the intended mins if there is a delta.
I ASSUME it was calculating correctly [°C] - [°C] = [K] or it did a incorrect conversion of 0°C to 0K.

So please correct this or give me a hint, where in github the code is, that does the quantity calculations…
Corrrect is
0°C equals 273.15K
And [°C] - [°C] = [K], where it is decideable if you first calculate and then convert or first convert and then calculate, what I suggest.

And yes, even some may not believe: 215°C - 215°C = 273,15°C… This is correct :slight_smile:

In between I will correct my code that it first converts to Kelvin and then starts the calculation, as this will result correctly also :slight_smile:

Yes, the behaviour was changed, see Adjust QuantityType calculations for temperatures by mherwege · Pull Request #3792 · openhab/openhab-core · GitHub

The PR contains a description about the why and how.

@Mherwege points to the what changed and why (tl;dr temperature calculations were not working correctly before). And because it’s fixed, you no longer need to mess with Kelvin any more.

You code though is a bit more complicated than it needs to be.

deltaTempGradient = Quantity('-87.15' + ' °C'); // if you want to stick with °C do so'deltaTempGradient: ' + String(deltaTempGradient)));
deltaTimeGradient = Quantity('80' + ' min');'deltaTimeGradient: ' + String(deltaTimeGradient)));
heatingGradient = deltaTempGradient.divide(deltaTimeGradient); // both temp and time gradients are already Quantities'heatingGradient: ' + String(heatingGradient)));
actualSetpoint = items.getItem('Remote_tutesOpenHAB_Gateway_Item_PLC_11_TSoll_Hauptschmelze').quantityState; // state is always a String, if you are going to do math get the quantityState'Setpoint: ' + String(actualSetpoint)));
actualTemperature = items.getItem('remote_PLC_11_Item_PLC_11_TIst_Hauptschmelze').quantityState;'actualTemperature: ' + String(actualTemperature)));
actualDeltaTemp = actualSetpoint.subtract(actualTemperature); // if you use quantityState you don't need to parse the Strings back into Quanties'actualDeltaTemperature: ' + String(actualDeltaTemp)));
timeNeededToHeat = actualDeltaTemp.divide(heatingGradient); // the result of a calculation with Quantities is a Quantity

You can also force the units to be what you want them to be

deltaTempGradient = Quantity('-87.15' + ' °C'); // if you want to stick with °C do so'deltaTempGradient: ' + String(deltaTempGradient.toUnit('°F'))); // converts to °F for logging

Thank you, then i need to do a own request there, as the result of the correction obviously still is wrong…

Explaination for technicans:
Two same temperatures [energy niveaus] , nothing else is it have 0 distance to each other [idea of being same] and that means, they have 0K = - 273.15 °C = - 459.67 F distance from each other.

Explainations for mathematicans:
°C and F are linear offset units, so the do not contain a simple multiplication, with a fixed offset, where the offset is the distance between respective scales 0 point and the point of 0 energy is the offset. That’s the idea of temperature units. Therefor temperature calculations always should be done by converting it in a offset free scale unit, then excecute the operation and convert back to original unit if needed.

I am with you on this, but I don’t think that is how most people would see it.

If I follow your logic, adding let’s say 5°C to a temperature would add 278.15K. That is obviously not what one would expect. Most people would expect to see 5K being added. The same is through when adding 5°F. Most people would not expect this to be converted to K first and then being added, rather expect 5°F as an offset from 0°F being added.
In the end, you could decide the reference point is 0°C for any temperature calculation in any unit by convention and have totally different results. While that looks stupid, treating 0K as the reference point is only (a commonly accepted) convention.
The changes that where done where done to make the calculations easier to understand and more predictable for most people. At least now we are able to explain the results. Before we were not.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.