When specified URL values override the corresponding form parameter.

$3

The MODBUS binding uses and provides plain binary data for reading and writing. Therefore in most cases, it will be associated with the content type application/octet-stream. Please refer to the description of this codec on how to decode and encode plain register values to/from JavaScript objects (See OctetstreamCodec). Note array and object schema are not supported.

Along with content type application/octet-stream, this protocol binding accepts also an optional byteSeq parameter. byteSeq specifies the endian-ness of the raw byte data being read/written by the MODBUS binding. It follows the notation application/octet-stream;byteSeq=value, where its value can be one of the following:

- BIG_ENDIAN, which is the default value
- LITTLE_ENDIAN
- BIG_ENDIAN_BYTE_SWAP
- LITTLE_ENDIAN_BYTE_SWAP

Note: the list above may be extended in the future.

In particular, the decimal numbers 9545 and 22880 will be encoded as follows:

- BIG_ENDIAN: 25 49 59 60
- LITTLE_ENDIAN: 60 59 49 25
- BIG_ENDIAN_BYTE_SWAP: 49 25 60 59
- LITTLE_ENDIAN_BYTE_SWAP: 59 60 25 49

For register resources, the payload is just the plain sequence of bytes read from or written to the registers. For coils and discrete inputs, the payload is a sequence of bytes, each corresponding to a single coil or discrete input. Each byte contains the value 0 or 1. So the encoder and decoder should work on this series of bytes and does not have to take care about handling the individual bits. Mapping each coil or discrete input to a single property of type boolean works just fine.

Another parameter that can be used in conjunction with application/octet-stream is length. This parameter specifies the length of the payload in bytes. This is useful to indicate the actual length of the payload when reading or writing a sequence of registers. For example, when reading a property using readHoldingRegisters, the payload length can be used to specify the number of registers to be read. Notice that the payload length must always
be equal to the number of registers multiplied by the size of the register in bytes.

$3

The protocol does not support security.

Implementation notes

This implementation handles multiple requests to the same slave by serializing and combining them if possible. In the following, the terms request and transaction are used as follows to describe this:

- A request is a read or write request to a resource as issued by a user of the node-wot API.
- A transaction is a Modbus operation and may cover the data of multiple requests.

$3

When two requests of the same type are issued and these requests cover neighbored registers, then they are combined into a single transaction reading or writing the combined register range. Note that this algorithm is currently rather simple: New requests are just checked if they can be prepended or appended to an existing transaction. If not, a new transaction is created. When a transaction completes, all requests contained in this transaction are completed.

$3

Multiple transactions to the same slave are serialized. This means that a new MODBUS transaction is only started when the previous transaction was finished. Transactions are held in a queue and executed in a first-come-first-serve manner.

$3

To help the MODBUS binding to perform combination a user of the API should create several requests for neighbor registers and resolve them all together in a single call to Promise.all(), e.g. as follows:

`javascript
console.info("Creating promise vl1n");
let vl1n = pac3200Thing.readProperty("Voltage/L1N");
console.info("Creating promise vl2n");
let vl2n = pac3200Thing.readProperty("Voltage/L2N");
console.info("Creating promise vl3n");
let vl3n = pac3200Thing.readProperty("Voltage/L3N");

console.info("Resolving all promises");
Promise.all([vl1n, vl2n, vl3n])
.then((values) => values.forEach((v) => console.info("Voltage = ", await v.value())))
.catch((reason) => console.warn("Failed ", reason));
`

This procedure guarantees that the requests are all combined into a single transaction _before_ this transaction is executed. A similar approach can also be used to write multiple properties in a single transaction.

Valid Form Examples

$3

Reads the 8th input register of the unit 1

`json
{
"href": "modbus+tcp://127.0.0.1:60000/1/8",
"contentType": "application/octet-stream;length=2",
"op": ["readproperty"],
"modv:function": "readInputRegister",
"modv:timeout": 2000
}
`

$3

Read and write the 8th holding register of the unit 1

`json
{
"href": "modbus+tcp://127.0.0.1:60000/1/8",
"contentType": "application/octet-stream;length=2",
"op": ["readproperty", "writeproperty"],
"modv:entity": "HoldingRegister"
}
`

$3

Polls the 8th holding register of the unit 1 every second.

`json
{
"href": "modbus+tcp://127.0.0.1:60000/1/8",
"contentType": "application/octet-stream;length=2",
"op": ["observeproperty"],
"modv:entity": "HoldingRegister",
"modv:pollingTime": 1000
}
`

TODOs

- [x] TEST
- [ ] (Modbus Server Protocol Binding)
- [x] Connection pooling
- [ ] More sophisticated algorithm for combining requests. Some ideas
- Not only append or prepend requests to transactions, but also combine transactions which become neighboured later on
- Impose some limit to the overall number of registers. The MODBUS protocol has such a limit and devices may define even lower values
- [ ] When a connection times out, re-connection does not work (see connectionTimeout` in modbus-client.ts)
- [x] When a Modbus device is not reachable, scripts using binding-modbus stop working - corresponding error handling is necessary

More Details

See .