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.
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.
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
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.
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.
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")
or
var mainsetpointnow = (MainThermostat14_SetpointHeating.state as QuantityType<Temperature>).toUnit("°F") as Number
The Number will happily hold the Quantity type value.
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.