Thanks! Yeah actually good point about serial connections, the com port is only criteria for “pooling” the connection. Serial parameters should not affect the pooling, instead the connection needs to be configured with the correct parameters before each query.
More about the related configuration change experimentation:
I have been also experimenting with the idea of separating modbus connection configuration from item configuration. This relates to the connection pooling somewhat. I think it would be useful to define the connections in openhab.cfg, i.e.
- ip address & port or serial params and serial encoding
The items could then define
- the valuetype, e.g. float32
- modbus function code to use (holding/coil etc)
- register/coil address
This way the connection can be specified only once and all the items would use the same connection.
I can think of following pros & cons:
- single slave definition = physical slave. In the current implementation, one needs to define as many modbus slaves as you have valuetypes and types. For example, if one is reading float32 & int16 input registers, discrete inputs and float32 holding registers, 4 modbus slaves need to be define (each havings its own valuetype and type)
- would allow configuration specific to items. E.g. whether to write floats are rounded integers, but read them as float32.
- when polling data from slaves, naive implementation make as many requests to the modbus server as there are items. The current implementation is effective as it reads consecutive registers (e.g. registers between 0-50) using a single request.
- configuration change is backwards incompatible. However, we could support both the old and new way of configuring (if slave has length configured, it would use the old way; otherwise the new way. If using new way, items could define the rest of the modbus query parameters)