This turns out to be quite interesting.
The OH 1.x MiOS Action is implemented using two calls akin to:
sendMiosAction(<Item>, <String>, List<Pairs>)
So it’s expecting to be called with an openHAB 1.x Item as a parameter.
Per your example above, it uses a model that’s similar to
sendCommand(), and you get something like:
sendMiosAction(SonosChambreId, "Sonos/Say", ...)
With Rules executing under openHAB 2.x, we’re working with ESH Item instead, which is a wholly different beast (different Java package/Interface) and, as a result it doesn’t find a signature match and fails with the error you’re seeing above.
In theory, there are a few options to address the problem but, in practice, most of these run into other issues:
OPTION A: Overload the static methods in the MiOS Action declaration to include “String-based” parameter variants.
Users moving to OH2.x would convert from using the Item, to using the name-of-the-Item when making the calls.
ISSUE: In practice, this doesn’t work. The runtime appears to have a problem matching the String-only version or the presence of the (OH1) Item-based one confuses it, so it fails with a different type of error.
ISSUE: It’s not consistent with the commonly used internal method
sendCommand(<Item>) - although it has both variants.
OPTION B: Wrap the incoming parameters with OH Compat 1.x equivalents (for Item)
so the method-matching logic will find the OH 1.x Action implementation correctly.
I’m not clear on how this part of the code works today, so this may be more complex than I’d imagine, but it would provide for the best overall compatibility.
ISSUE: Given there are only a handful of Bindings that use Structured type parameters, this may be overkill.
OPTION C: Overload the static methods in the MiOS Action declaration to include variants with ESH Item.
Similar to option (A)
ISSUE: This would likely have the reverse problem of dragging ESH dependencies into the OH1 Binding that might cause it not to resolve correctly in an OH 1.x environment (existing users break, in theory)
ISSUE: It has the same issue with overloading that OPTION A had.
OPTION D: Cutover to using String-based static methods for the implementation, and not use Item parameters.
ISSUE: Backwards compatibility would be broken for existing rules, and users would have to cutover “all at once” since, due to OPTION A issues, there couldn’t be an easy overlap version that lets them migrate.
Each has it’s own set of issues and some, like the Overloading scenarios.
At this point I’m tempted to break compatibility (OPTION 4) but, IMHO, this doesn’t provide a very natural scripting experience in openHAB.
@watou, It looks like you’re using Item class in the parameters of your Action Bindings for Nest and EcoBee. Can you confirm that you’re successfully exercising OH 2 Rules using these via the Compat layer? Maybe there’s something else I’m missing.