One suggestion, which came up in another thread I’d started related to some weirdness with sending commands via a rule – I think the ESH metadata defining channels needs to be updated to have the concept of a primary type and supported types, and the framework should send commands of supported types through to the binding directly. The “as()” conversions should be deprecated, and the system needs to log appropriately when a command of the wrong type is sent to a binding.
Right now you’ve got conversions running in the framework from some types to some other types which may or may not be appropriate to the binding, and a situation where a conversion not happening causing a type mismatch doesn’t trigger anything in the logs – the event just vanishes.
My use case was a little more specific, but to be more generic about it, an example would be a channel representing a dimmer state. Right now a dimmer state may take a PercentType, and if you send an OnOffType, the system down in OnOffType will convert that to a PercentType(100). The binding therefore has no idea the user sent ON, just that they sent 100. The binding may want ON to mean something else, so you end up having two channels that can take ON – one that is interpreted as ON and can do something binding specific (restore to prior state, for example) and one that receives 100, and the user needs to know the difference (which isn’t obvious, because both will take either command type) The inverse is even weirder, because the as implementation in PercentType is different for OnOffType vs OpenClosedType, for example. (Only 100 is OPEN, but anything non-zero is ON).
What I’d really like to see – both from the standpoint of a binding author and a binding consumer – is the ability to tell the framework “this channel is a PercentType, and if you ask my state, that’s what you’re getting, but I’ll accept an OnOffType”. Then I can do a binding-specific interpretation of the other types rather than hoping the type conversions and logic in the defined item type matches my behavior, rather than having to define multiple channels that do almost-but-not-quite the same thing.