In Rules DSL by far the most common issue is trying to force the types of the variables. There are only a few rare cases where doing so doesn’t cause more problems than they solve. If you stop doing that, the error generated will likely be more informative.
So, assuming you want a lambda to call to default an Item’s state to 0 if it’s NULL (don’t forget UNDEF too) change it to:
val nvlFloat = [ GenericItem theItem |
if(theItem.state == NULL || theItem.state == UINDEF) 0 else theItem.state as Number
]
Notice how even with the lambda we don’t muck about with over-specifying types. Specifying theItem as a GenericItem is probably unnecessary here.
Now for your calculations:
var DAR = nvlFloat.apply(I_KG_Heizraum_Assentemperature) - nvlFloat.apply(I_KG_Heizraum_Keller_TemperaturNormalSoll)
We don’t tell it that DAR is a Float or BigDecimal or Number because it can figure that out at runtime. In fact, even though you’re trying to force it to be a Float, it’s really going to be converted to a BigDecimal on you in the background anyway.
The same goes for the second calculation.
One case that this approach wont handle though is if one or more of these Items is a QuantityType (i.e. has units of measurement). You can tell if the Number Item is defined with a type (e.g. Number:Temperature) or by watching events.log. If you see these Items changing to something like 22.345 °C instead of just 22.345 than you have to deal with the units.
If you are dealing with units, it’s best to keep the units. You can define a constant in Rules DSL with units as follows: 1.23|°C.
One final bit of advice. Break these calculations up. There’s no prize for writing the fewest lines of code and long calculations like this are hard to read, understand, and debug. So convert your Items to Numbers and store those into meaningfully named variables. Then your actual calculation will be much easier to read and understand. And you can log out the converted states of the Items for debugging.