Ambiguous feature call error message in VS Code

Wasn’t following the VS code upgrade to 1.0 and carelessly upgraded when I was in the middle of something else. My bad. Anyway have most of it sorted, but get the following error on what I think is still a working file.

I have statements like


where the mainsetpointnew and upsetpointnew are in °F. The sendCommand(Item, Number) is not recommended in the documentation, yet I get this in the output section

Ambiguous feature call.
The extension methods
	sendCommand(Item, Number) in BusEvent and
	sendCommand(Item, Command) in BusEvent
both match.

Any insights would be appreciated.


mainsetpointnew and upsetpointnew are both of type QuantityType. QuantityType inherits from Number and from Command so it’s both at the same time. The error is saying that there is a sendCommand method that takes a Number and another sendCommand method that takes a Command and since you are passing something that is both it doesn’t know which method is the one that should be called.

You can give it the hint it needs by:

  • calling toString one mainsetpointnew and let sendCommand parse it back to a QuantityType later
  • casting it to Number
    = casting it to Command.

Rich- Thanks for responding.
This rule took advice from @rossko57 on temperature units to get right, so I want to be careful in resolving the ambiguity error message. I did see this morning that the rule still does what I want it to do, so it must be picking the right option. However, I do not like to see error messages. The relevant lines above the send command issues are;

var mainsetpointnow = (MainThermostat14_SetpointHeating.state as QuantityType<Temperature>).toUnit("°F")
var upsetpointnow = (UpstairsThermostat21_SetpointHeating.state as QuantityType<Temperature>).toUnit("°F")
    if( upstate == 1 && mainmode == 1) {
      var mainsetpointnew = mainsetpointnow + 1|°F
      var upsetpointnew = upsetpointnow + 1|°F

So I do not want to lose the °F, and honestly I do not understand either the concept of calling toString or casting it to command as I have never done either before. Could you elaborate a bit?


It’s a validator problem,not runtime.
As they’ve just released a new VSCode openHAB extension, might be worth installing that. I suspect it won’t help though.

Thanks for the insight

Actually it was the new VScode openHAB extension that sprung this error. It did not appear before & rule has been in use and unchanged for 4-6 weeks.


At runtime the rules engine has way more information to determine what needs to be done and what is correct to do than it has at at parse time. So there are many things that will generate an error in VSCode that will run just fine. But if you want to eliminate the warning in VSCode you need to give the parser a hint as to what type you are using.

should qualify for the hint, really. I expect the LSP thingy is not yet getting to grips with Quantities and their methods yet.

Ok I’m good for now. Thanks all for your comments.


I don’t think that should work. As you can see here, QuantityType inherits from Number and implements Command. Providing as QuantityType doesn’t resolve the ambiguity because the Object will still be both a Number and a Command. You would need to cast it down to eliminate the ambiguity, as Number or as Command.

Having had a play, the workaround is to give the validator what it wants.

var Number mainsetpointnow = (MainThermostat14_SetpointHeating.state as QuantityType<Temperature>).toUnit("°F")
var mainsetpointnow = (MainThermostat14_SetpointHeating.state as QuantityType<Temperature>).toUnit("°F") as Number

The Number will happily hold the Quantity type value.

Thanks again. Could not have solved this without you (Twice now).


EDIT: oops; spoke too soon. The Number (or as Number) in either location neutralizes the degrees F and I’m back to the absolute temperatures.

2021-04-16 20:51:24.859 [WARN ] [] - mainsetpointnew 548.5222222222222222222222222222222
2021-04-16 20:51:24.866 [WARN ] [] - upsetpointnew 549.0777777777777777777777777777778

I’m back to the original and will live with the ambiguity. Thanks for trying.

Oh, my fault, I was forgetting you’re doing maths after getting the states. Muddled ‘news’ and ‘nows’.

You need to do the maths using a real Quantity to get sensible unit-related results, and then get as Number for sending.

// back to Plan A for this part
var mainsetpointnow = (MainThermostat14_SetpointHeating.state as QuantityType<Temperature>).toUnit("°F")

      var mainsetpointnew = mainsetpointnow + 1|°F

// do the "conversion" at the last moment, just to satisfy validator
MainThermostat14_SetpointHeating.sendCommand(mainsetpointnew as Number)

Quantity types have functional units ; but in Numbers they’re just decorative.

Ok that worked. Thanks again. Math with temperatures is very tricky.