Issue with final parameters when using lambda to create "function"

That is correct. The variables passed to a lambda are passed as vals, not vars so you cannot change them. One sort of work around is to use a collection (Map, List, etc) as the variable itself is a val but you can setill change the contents of the collection from inside your lambda.

One thing to know about the way VSCode works is it connects to your actual OH server and runs the code through the exact same compiler that OH uses to parse and load the rules files. So errors that show up in VSCode are real errors and will almost certainly show up in openhab.log as well. What probably happened was you were using a version of the openHAB extension from before the connection to the language server in OH was added.

The problems you are seeing have always been problems. And you should have been seeing them in openhab.log as well.

Cast both sides of the < operation to Number. The problem is that the first argument is a Type and it is also a Number so the Rules Engine cannot tell which version of the < operator you intend to call.

The same goes for the postUpdate. This is usually caused when you cast the state of a Number Item to DecimalType instead of Number, or fail to cast the state of a Number Item at all. This is why I always recommend casting to Number and never casting to DecimalType.

As shown in the link Vincent posted, you should (this is just a warning so it isn’t an error that stops anything from working) provide the types of the arguments to the lambda:

val Functions$Function3 <NumberItem, NumberItem, SwitchItem, Timer> themostatlogic = [ current_temperature, target_temperature, heater |

NOTE, is it not clear what your lambda is supposed to be returning. The last argument type (Timer) defines the return type of the lambda. The return value of the last line of the lambda is what gets returned. In the else at least that is a Timer.

If you don’t need a return value then use Procedures$Procedure and omit the “Timer” between the < >.

Having said all of that, it really looks like this is a good candidate for using Design Pattern: Associated Items and the triggeringItem implicit variable which would let you use just one rule and avoid the lambda entirely.