I want to calculate a new average inside temperature from four sensors. I have created a rule to update the new item InsideTemperature when one of the sensor values changes. The rule triggers an inline blockly ECMAScript (262 edition 11, OH4 4.2.0 stable).

The issue I have with the script is that division (or multiplication) of the inside temperature by a constant factor does not work and produces an incorrect result. However, addition and subtraction work as expected and give a new temperature in Â°C. The same script worked before updating OH (donâ€™t know what version I had before), so something must have changed under the hood how the unit of measurement (Â°C or K) is treated.

For example, if the sum of the four temperatures is 114.6Â°C, dividing by 4Â°C to calculate the arithmetic mean temperature of the four sensors gives 1.39906187984845751398159841241205134450, a dimensionless number (I guess when dividing Â°C/Â°C, the unit cancels out). However, when in the next line updating the item InsideTemperature with the variable Inside_Temp, the unit Â°C gets appended and the state of the item becomes 1.39906187984845751398159841241205134450 Â°C.

Multiplying 114.6Â°C by 4Â°C gives 107464.9125 KÂ˛ and the following error message:

14:19:31.298 [WARN ] [openhab.core.library.items.NumberItem] - Failed to update item 'InsideTemperature' because '107464.9125 KÂ˛' could not be converted to the item unit 'Â°C'

Any ideas what is going on under the hood and how to obtain the correct results for division and multiplication operations?

Now instead of calculating the average by summing the individual sensor values and dividing by the number of sensors, I use create list with block and the median of list function as shown in your example.

However, it is still a bit cumbersome to convert the item state into a pure number first, then do the median calculation and finally appending the unit again during the post update to InsideTemperature item. I thought the math calculation blocks are now able to handle the value plus the unit directly without stripping off the unit. Rules Blockly - openHAB Extensions to the Standard | openHAB

indeed becomes 107464.9125 KÂ˛ because scientifically it is the correct way. Celsius must be only multiplied by a scalar. I am not sure why you want to multiply the temperature by another one but if you do, scientifically it must be converted to Kelvin first which then results into Kelvin (squared) of course, which then cannot be applied to the state of course.

There are 2 issues in your rule. As you want to calculate an average, you should not divide by 4 Â°C, but just by 4. However, dividing is done on the absolute temperature, which is 273.15 K + the some of your temperature differences, yielding the wrong result in your case. You will get the correct result if you subtract 273.15 K before dividing by 4 and then add 273.15 K back to it. Or you can convert all to K before adding up and dividing, and then convert to Â°C again.

Beyond everything thatâ€™s been said I just want to add that there is a â€śto unitâ€ť block you can use to convert your Itemâ€™s states to K before calculating the average, and then convert the result back to Â°C using the same block.

@stefan.hoehn and @Mherwege , do we know if the Group AVG aggregation function handles temperatures correctly? Iâ€™m not in a place where I can try it easily right now. Iâ€™ll try to remember later today if you donâ€™t know off the top of your heads.

@pohl7542 , if it works, you donâ€™t need this rule (or at least this part of the rule). Just put all these Items into a Group:Number:Temperature with an average aggregation function and the state of the Group will be the average of all the members of the Group.

@Mherwege Thanks for providing the detailed explanation for what is going on under the hood. I didnâ€™t expect that OH converts temperatures to the absolute temperature scale internally before doing calculations with it. I double checked, 114.6 Â°C * 4 Â°C is indeed 107464.9125 KÂ˛ when converting to K first. The division 114.6 Â°C by 4 Â°C equals 1.3991 (no unit!) is also correct when doing on the absolute temperature scale.

@rlkoshak Using a group with the AVG aggregation function is probably the way forward as I donâ€™t need to create the rule to update the InsideTemperature item anymore.