I started the to think whether it is actually needed to have all these channel types
number
switch. Would have some parameters to convert the value from/to device in a sensible way to ON/OFF
etc
Modbus and Mqtt binding both follow this approach. I find the serial binding following same approach
Now thanks to profiles and transformation, I am questioning whether this makes sense. Bindings bring their own configuration parameters (“on” vs “onValue”) and the learnings are not transferable to other bindings.
In Modbus, most use cases are covered with simple number channel, and that is convertible eg to switch using normal openHAB functionality. The binding could even bring pre-made MAP/SCRIPT transformations during install
From learning point of view, I consider it better that bindings would rely on “standard” functionality, not each having their own ways of transforming the values
What do you think? What should be the OH4.0 way to do things?
I would say that profile is an additional effort for user, thus it will complicate their setup if it must be added for each number read by binding. Making it possible to turn numeric values to switch or contact is great, but it heals issues with modbus protocol design for certain devices. If you can make onValue part of channel configuration then its consistent within modbus itself and close to device mapping (profile is specified at item/metadata level). Both mqtt and serial bindings have same issues which come from fact that they are making sense out of fairly generic transport.
You can have multiple channel types - standard numer channel and extra number-switch which would work with numer on device side but communicate OnOffType on other end. It seems clear then and keep user setup tight.
If other bindings have similar situations then it makes a sense to align their options and description/docs, because handling of values (encoding of numbers towards devices) will always differ.
Existence of switch-number profile is fair too, but I would reserve it for situations where binding can not handle that directly.
This has been a pet peeve of mine since before OH 2. I don’t think that the bindings should be in the business of providing transformations. These should be outside the binding and standardized so that all bindings can benefit from a standardized approach.
Unfortunately, the only current candidate to replace them is the transform profile and there are limitations in the way that those work that would eliminate many things that some bindings are using transforms to achieve (e.g. I’m told transformation chaining is not feasible in profiles).
But one area where eliminating Channel types would be a step back is that right now that is what is used to tell OH what type of Item should be linked to a Channel by default. Without it, “Create equipment from Thing” and similar capabilities become much more work. I think Modbus (and KNX) are somewhat of an outlier in this regard. Most bindings are able to provide a reasonable Channel type out-of-the-box so there’s nothing that the end user has to additionally configure. It just works.
