Yeah with that phoenix one of the issues was writing individual bits to register. That would not be solved by above Thing setup alone. Have to remember the write multiple / write single register support, though.
As discussed else where writing values that are less than 16 bits (bit, int8) are problematic conceptually. With 32bit types it’s easy as you said, just not implemented.
I’m thinking of removing broken features such as writing 8bit integers (current binding writes 16bit integers), and logging warning that write was discarded:
- <16 bit (bit, int8) read: will be supported
- <16 bit (bit, int8) write: will not be supported (at least in the first phase), will log warning. Current binding writes the value as 16bit integer (overwriting the whole register with 0/1 value, for example) which is quite ockward.
- =16bit (int16) read & write: will be supported
-
16 bit read (int32, float32): will be supported
- ``>16 bit write (int32, float32): might be supported, will consider this
Other features that I’m planning to drop
- support for UP/DOWN & INCREASE/DECREASE commands. Current binding increases or decreases last polled value by one (buggy once again with value types, and has the same conceptual issues as writing of <16bit types). With transformations and rules one can convert the commands to numeric values of course.
I would say OH should follow that philosophy and keep the binding relatively simple.
So long as we can define in/out separately and optionally, and can use transforms - something like a rollershutter should be manageable with rules? Build a library of templates for Brand X rollershutters, Brand Z airconditioner etc.
Indeed, I think this is something to look after. I argumented against having the “single-brand” roller shutter implementation in the modbus binding here.
On the other hand, it seems that rules and “proxy items” are really something the community hated with roller shutters, see this response for example. The extended item syntax helped the users to formulate these kind of cases in a straightforward fashion, without additional rules and proxy items.
I do agree with you that it makes sense to have the bindings simple, otherwise we end up having custom logic in each and every binding, which makes it hard for the user to learn the system. Also the binding maintenance burden increases. On other hand, I think we agree that some sort of abstraction and complexity is required, to support the typical use cases such as 32bit floats over modbus (instead of just exposing 16bit integers and letting users to do the conversions with rules).
The functionality provided by the extended item syntax goes to the gray area, I think. Perhaps it is too powerful (read: complex) to be included in the binding, and we should encourage users to use rules instead. Might be tough to migrate existing configuration though if the functionality requires a lot more logic etc…
I keep reading about “re-usable” rules and “script libraries” with openHAB2, so I think we might have something coming that way. If we would have rule libraries, perhaps one could share e.g. “roller shutter logic” in a easy way, and the binding itself could remain simple.
Let’s see if others have any feedback, have to think this for a while and decide what would be the best way.
Best
Sami