Minus operator (-) does not work in rules (openHAB 4.2.0)

[quensen]

The minus operator (-) for subtraction does not work in rules in some cases since I updated from 4.1.3 to 4.2.0 Release Build.

Expected Behavior

The following code was working in 4.1.3:

	val sollflur = Temp_Soll_EG_Flur.state as Number

	val DateTime vor1Y = now.minusYears(1)

	val istdiele = Temp_Ist_EG_Diele.averageSince (vor1Y)
	val istflur = Temp_Ist_EG_Flur.averageSince (vor1Y)

	val solldiele = sollflur - (istflur - istdiele) // this is line 1543

Current Behavior

After I updated to 4.2.0, I am getting this error:
2024-07-08 14:13:57.877 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'main-40' failed: Unknown variable or command '-'; line 1543, column 30, length 18 in main

Possible Solution

My quick-fix was to add type Number to the variables:

	val Number istdiele	= Temp_Ist_EG_Diele.averageSince	(vor1Y)
	val Number istflur	= Temp_Ist_EG_Flur.averageSince		(vor1Y)

But that does not solve the original issue.

Steps to Reproduce (for Bugs)

Put the lines above in a text file rule and save it as test.rules in the rules folder in your config folder.
Watch the log file.

Context

I was trying to perfom the subtraction to calculate a derived value.

Your Environment

runtimeInfo:
  version: 4.2.0
  buildString: Release Build
locale: de-DE
systemInfo:
  configFolder: /etc/openhab
  userdataFolder: /var/lib/openhab
  logFolder: /var/log/openhab
  javaVersion: 17.0.11
  javaVendor: Debian
  osName: Linux
  osVersion: 6.6.31+rpt-rpi-2712
  osArchitecture: aarch64
  availableProcessors: 4
  freeMemory: 224180480
  totalMemory: 801112064
  uptime: 2694
  startLevel: 100
addons:
  - automation-jrubyscripting
  - automation-jsscripting
  - binding-astro
  - binding-exec
  - binding-fsinternetradio
  - binding-http
  - binding-knx
  - binding-lgwebos
  - binding-miio
  - binding-mqtt
  - binding-network
  - binding-tr064
  - misc-openhabcloud
  - persistence-rrd4j
  - transformation-jsonpath
  - transformation-map
  - transformation-regex
  - transformation-xslt
  - ui-basic
clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: false
    macos: false
    windows: true
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    os: windows
    pixelRatio: 1
    prefersColorScheme: dark
  isSecureContext: false
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 20
    language: de
    languages:
      - de
      - de-DE
      - en
      - en-GB
      - en-US
    onLine: true
    platform: Win32
  screen:
    width: 3440
    height: 1440
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: dark
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
    blocklyRenderer: null
  userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
    like Gecko) Chrome/126.0.0.0 Safari/537.36 Edg/126.0.0.0
timestamp: 2024-07-08T13:05:25.900Z

[mherwege]

averageSince now returns a QuantityType for Items that have a dimension. This is listed in the breaking changes. In your rule it causes a subtraction of a QuantityType (result of the subtraction in brackets) from a DecimalType (you defined sollflur as a Number). You should not convert sollflur or indeed, define the two others as a Number to stay consistent in your rule.
So I don’t think this is a bug.

[Intenos]

I have also a problem with some math operations since 4.2.0. I experienced the issue on different openHAB installations, with DSL rules as well as with blockly and with 4.2.0 as well as 4.2.2

On my side it is more about mulitplications and divisions. From there I´m not sure whether it is the same problem or should be reported separatly.

Anyhow, before 4.2.0 the calculations worked in the following way:

var Number kWh_verfuegbar_heute = (PV_Vorhersage_Solcast_Sued_Energie_HeuteVerbleibend.state as QuantityType<Number>).toUnit("kWh").toBigDecimal - 6 / 100 * (100 - PV_Batterie_Ladezustand.state as Number) 

kWh_verfuegbar_heute = kWh_verfuegbar_heute - (9 / 18 * (18 - now.getHour))

Since 4.2.0, it always subtracts 0. So the values remain the same. The really interesting part is, when I change around the multiplication and division, it works again!

var Number kWh_verfuegbar_heute = (PV_Vorhersage_Solcast_Sued_Energie_HeuteVerbleibend.state as QuantityType<Number>).toUnit("kWh").toBigDecimal - 6 * (100 - PV_Batterie_Ladezustand.state as Number) / 100

kWh_verfuegbar_heute = kWh_verfuegbar_heute - (9 * (18 - now.getHour) / 18)

The same with blockly:

This is not working:

This is working:

[Intenos]

I can confirm that adding "as Number" resolves the issue with "-". I also found one calculation today not working anymore and creating the same error message as written in the first post.

After adding "as Number" it works:
if ((LWZ_Status_Verdichter.sumSince(ZonedDateTime.now().with(LocalTime.MIDNIGHT)) as Number - LWZ_Status_WW.sumSince(ZonedDateTime.now().with(LocalTime.MIDNIGHT)) as Number) > 0)

@mherwege
May I ask you what you think about the multiplication and dividison issue I wrote above? Shall I create a separate bug report for it? Or is there also an explanation for it?

[mherwege]

May I ask you what you think about the multiplication and dividison issue I wrote above? Shall I create a separate bug report for it? Or is there also an explanation for it?

Sorry for the late reply. It is a bit hectic at work.

What are the types of the items in your Blockly rules? If these are QuantityTypes, you should not use the straigth mutiplication and division operators, but the methods provided with QuantityTypes in Blockly.

For DSL, I often struggle myself with the logic. But behind it is Java, and if you give Java 2 integers, it will divide into an integer result. That's why first multiplying and then dividing will probably work. You can also try first multiplying with 1.0 to make sure it is treated as a float. DSL does all kind of type magic as it tries to infer types, and that's where it often goes wrong.