The binding follows the thing hierachy described in here (Alternative proposal (better?) version).
So you have to define the following things
- Connection, e.g. 192.168.1.100 port 502.
- you can define parameters specific to endpoint, such as the the time between transactions etc. (previously in the old binding these were in the connection string)
- Poll definition (use connection as bridge)
- what to poll (holding register, input register, coils, discrete inputs)
- how often to poll (use zero to disable polling!)
- how many items to poll, starting from what index
- readwrite definition (use poller as bridge): gathers different “read rules” and “write rules”, similar to item config string in the old binding
- no configuration
- read definition, optional, use readwrite as bridge
- specify the index (relative to polled items) from which to read, how to read it (valuetype), trigger and transform a bit similarly as with old binding
- TODO: need to document this more carefully and improve the help text in UI
- write definition, optional, use readwrite as bridge
- now should support non-16bit writing, e.g. writing float32
- what modbus item to write: coil or holding register
- address to write, not relative to polled data
- how to write: value type
- transform and trigger as with old binding
- TODO: need to document this more carefully and improve the help text in UI
It’s most convenient to use readwrite channels to read the data; values from all read are aggregated from all the read things. This is similar how old binding item state reflected all the “read definitions” in the config string.
Please comment!
Best,
Sami