Maybe that is the place for Modbus id / slave address? Different id usually correspond to separate physical slaves. Obvious for serial, not so obvious where TCP gateway in use.
Yeah, it would make sense to include it here. Then one does not need to repeat the id many times.
Connection sharing would work as currently, based on host+port or serial device
We do expect the binding to follow different behaviour in the usual polled-read + on-demand-write setup.
What did you mean by this?
I certainly don’t have enough OH2 knowledge to see why the common readwrite “thing” is a Thing and not straight to a Channel. I think I have a clue that a readwrite Thing would have several Channel ‘children’ - one for Number, one for Contact, one for Rollershutter etc.
Well, if it would be a channel and the read and write definitions would be configuration, I think the channel’s parent thing would be tied to those read & write definitions. Since we want to allow having many read & write definition pairings, separate thing type is required… Or at least that’s how I understand it.
( I obsess about fault management, and have in mind the use-case to reduce/stop polling a broken slave, and so avoid excessive waiting on timeouts )
This is hopefully not so much an issue as all the polling will be in different threads in openHAB2 version… Do not have answer for ConfigAdmin analogy.
Alternative proposal (better?) version:
endpoint thing (bridge) {
// thing config parameter: ip port
poller thing (bridge) {
// thing config parameter: poll period
// thing config parameter: start, length of registers/coils to read
// thing config parameter: type of items to read (coils, discrete inputs, holding registers, or input registers)
readwrite thing {
// note: not part of bridge!
// analogous to old binding item config
// thing config parameter: read definitions (thing UIDs as comma separated)
// thing config parameter: write definitions (thing UIDs as comma separated)
// channel: switch, number, string, ... (all known channel types, similar to openhab 1 binding supports all items as long as correct transformation is in place)
(zero or more) read definition thing {
// config parameter: what to read (index of register/coil)
// config parameter: how to read
// - trigger,
// - value type (e.g. 16bit integer vs 32bit integer)
// - and transformation
// channel for different item types: switch, number, string, etc.
}
(zero or more) write thing {
// thing config parameter: where to write (index of register/coil)
// thing config parameter: what kind of data to write (coil or holding register)
// thing config parameter: how to process data for modbus
// - trigger
// - transformation,
// - value type (e.g. 16bit integer vs 32bit integer)
}
}
}
}
Upside compared to first alternative
- GUI configurable, no need to refer to “channel IDs” in thing configuration
Obvious downside
- not possible to combine coils with input registers, or read holding registers with coils, etc.
- not really elegant for write-only outputs, needs poller definition which is semantically wrong
I tried looking for a example (or convention) to follow but I could not find any general purpose binding that would have been ported for openHAB2, all the similar protocols (KNX, MQTT, HTTP, …) have not yet made it. As far as I can see, the things in other bindings currently refer to real physical entities, not abstract items like proposed here. I’m thinking if we are misusing the thing / channel abstraction here.
Of course one option is to keep the binding simple, and leave it to the rules to have transformations etc.
Best,
Sami