I'm reading out my solar inverter over modbus interface. My current script reads out 4 holding registers in a nested function where the next holding register is read when the previous is done. Simply put it looks like this.

client.readHoldingRegisters(30775, 2).then((resp) => {
  // do something with resp.payload
}).catch((err) => {
  console.log(err);
}).done(() => {

  client.readHoldingRegisters(30517, 4).then((resp) => {
    // do something with resp.payload
  }).catch((err) => {
    console.log(err);
  }).done(() => {

    client.readHoldingRegisters(30783, 2).then((resp) => {
      // do something with resp.payload
    }).catch((err) => {
      console.log(err);
    }).done(() => {

      client.readHoldingRegisters(30513, 4).then((resp) => {
        // do something with resp.payload
      }).catch((err) => {
        console.log(err);
      })

    })
  })
})

At some point I get a time out error when reading out one of the registers. I dont know why, it's wired connection on a stable network but I would assume the script would catch the error and wont continu in the done() function. I handle the catched error by closing the client connection and reconnecting in one minute. However, looking at the log it seems the script still read out the next register even though a time out error was catched. See the log below.

Connected ...
{ err: 'timeout' }
2018-09-01 11:24:47 [log] [ManagerDrivers] [inverter] [0] Error: write after end
    at writeAfterEnd (_stream_writable.js:236:12)
    at Socket.Writable.write (_stream_writable.js:287:5)
    at Socket.write (net.js:704:40)
    at Object.<anonymous> (/node_modules/node-modbus/node-modbus/modbus-tcp-client.js:1:2318)
    at Object.emit (/node_modules/stampit-event-bus/src/stampit-event-bus.js:20:38)
    at Object.<anonymous> (/node_modules/node-modbus/node-modbus/modbus-client-core.js:1:1047)
    at Object.queueRequest (/node_modules/node-modbus/node-modbus/modbus-client-core.js:1:2591)
    at Object.<anonymous> (/node_modules/node-modbus/node-modbus/handler/client/ReadHoldingRegisters.js:1:961)
    at Promise._execute (/node_modules/bluebird/js/release/debuggability.js:303:9)
    at Promise._resolveFromExecutor (/node_modules/bluebird/js/release/promise.js:483:18)
    at new Promise (/node_modules/bluebird/js/release/promise.js:79:10)
    at Object.readHoldingRegisters (/node_modules/node-modbus/node-modbus/handler/client/ReadHoldingRegisters.js:1:844)
    at client.readHoldingRegisters.then.catch.done (/drivers/inverter/device.js:62:20)
    at tryCatcher (/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/node_modules/bluebird/js/release/promise.js:569:18)
Client closed, retrying in 60 seconds
Reconnecting now ...
Connected ...

And last but not least. After the initial time out error the script keeps reporting this error as if it's not capable of reconnection even though the client.close() was called and new connection was started. The only way to get a working connection is to stop/start the script. This last error looks a lot like the issue described here: #5 . But this is supposed to be fixed.

I would really appreciate it if someone could help me fix this so time out errors dont result in endless loops of new time out errors.

https://github.com/biancode/node-modbus/blob/master/src/modbus-server-core.js#L53

In the server core code, there's a small issue if the server receives empty data, causing pdu to simply be a Buffer of size 0 which would cause the readUInt8(0) call to throw a RangeError with the message: index out of range and subsequently crashing the process.

This was observed by running the server on any port and running nmap 127.0.0.1 -p 502 -A.

nmap is a very popular port scanning tool in the network security community and as a part of its scanning script, it may sometimes send little to zero data to see how the service reacts.

Current:

let fc = pdu.readUInt8(0)

Proposed:

let fc = pdu.length > 0 ? pdu.readUInt8(0) : someDefaultValueLikeZero

Client options appear to include an 'endianType' member which defaults to "LITTLE" (modbus-client-core,js, lines 42 & 43).

This is referenced in modbus-serial-client.js but not in modbus-tcp-client.js. It appears that the behavour for a Tcp Client is always big-endian irrespective of the value of endianType.

I'm trying to read multiple holding registers but keep running into { err: 'modbus client not in "ready" state' } error messages. Obviously I'm doing something wrong. I would appreciate if you could point me in the right direction. My sample code looks like:

const node_modbus = require('node-modbus')

const client = node_modbus.client.tcp.complete({
    'host': '192.168.0.128', /* IP or name of server host */
    'port': 502, /* well known Modbus port */
    'unitId': 3,
    'timeout': 5000, /* 2 sec */
    'autoReconnect': true, /* reconnect on connection is lost */
    'reconnectTimeout': 15000, /* wait 15 sec if auto reconnect fails to often */
    'logLabel' : 'ModbusClientTCP', /* label to identify in log files */
    'logLevel': 'debug', /* for less log use: info, warn or error */
    'logEnabled': true
})

client.on('connect', function () {
  client.readHoldingRegisters(30775, 2).then(function (resp) {
    //console.log("SMA Power AC");
    console.log(resp.payload.readUInt32BE(0, 1));
  }).catch(function (err) {
    console.log(err)
  }).done()


  client.readHoldingRegisters(30517, 4).then(function (resp) {
    //console.log("SMA Daily Yield");
    console.log(resp.payload.readUInt32BE(4));
  }).catch(function (err) {
    console.log(err)
  }).done()

  client.readHoldingRegisters(30513, 4).then(function (resp) {
    //console.log("SMA Total");
    console.log(resp.payload.readUInt32BE(4));
  }).catch(function (err) {
    console.log(err)
  }).done()
  
  client.readHoldingRegisters(30783, 2).then(function (resp) {
    console.log("SMA Volt");
    console.log(resp.payload.readUInt32BE());
  }).catch(function (err) {
    console.log(err)
  }).done(function () {
    client.close()
  })

})

client.on('error', function (err) {
  console.log(err)
})

client.connect()

Hi,

The example in the readme has flaws, where it uses strings for things like baud rate, which your library wont allow. So it won't run without changing a lot.

I tried the client example in github (with a few modifications for my own environment):

var ModbusClient = require('node-modbus');
var client = ModbusClient.createSerialClient('/dev/ttyAMA0', 115200)

client.on('connect', function () {
  client.log("Connected");
  client.readInputRegister(0x000E, 2).then(function (resp) {
    console.log(resp)
  }).fail(function (err) {
    console.log(err)
  }).done(function () {
    client.close()
  })
})

client.on('error', function (err) {
  console.log(err)
})

But this gives me the following:

INFO : ModbusClientTCP log level: debug
DEBUG : ModbusClientTCP set on send method
DEBUG : ModbusClientTCP serialport settings: {"baudRate":115200,"autoOpen":true,"parity":"none","xon":false,"xoff":false,"xany":false,"rtscts":false,"hupcl":true,"dataBits":8,"stopBits":1,"bufferSize":65536,"lock":true,"platformOptions":{"vmin":1,"vtime":0}}

And it never runs the connect event..

I also cannot see where I specify the ID of the modbus device I want to read data from?

Hi ,
this is a great package, however, it doesn't display the correct value it if data sent from the Modbus device is a float or a long
I'm using this command to read the data
client.readHoldingRegisters(0, 11).then((response) => console.log(response.register))
if the data sent was 245 as a float it detects it as 17269 , and if is a long int it detects it as 0

Hello, it is possible to use this library to connect to an industrial machine from a mobile phone?

I am building an App using Ionic2 framework

Thanks and Best Regards

/examples/tcp/AutoReconnect.js - call to fail at line 30 needs to be replaced by catch

Currently, node-modbus has a hard specification which version of node.js it supports: "node": "6.x" in its package.json. This is very limiting.

Can you add node v8 support or change the version to >6.x

I have a simple implementation of a TCP client which initialises in autoconnect mode as follows:

{
    this.client = modbus.client.tcp.complete({
      'host': this.host,
      'port': this.port,
      'autoReconnect': true,
      'reconnectTimeout': 5000,
      'logEnabled': true,
      'logLabel': "ModbusTCP Client" + this.host + ":" + this.port
    }).connect();

It then polls a circular queue of read requests (to holding registers) using this code snippet:

this.client.readHoldingRegisters(curJob.address, curJob.size)
      .then(function (resp)
      {
        // Does some processing here
        ....

      })
      .catch(function (err)
      {
         // Process error here
      })
      .then(function ()
      {
        // Increments or restarts queue
        self.setupNextRead();
      })
  };

If I connect to a controller on another IP address then cut the connection (eg by unplugging the server's network cable or by turning off my WiFi card), the catch handler is called with err.err === "timeout" (as expected). However, when the connection is restored, the client does not recover and continues to call the catch handler with the same timeout error for all subsequent requests.

This issue does not happen if I disconnect by switching off the modbus server device.

I have fixed in my code by calling .close() then .connect() in the catch handler. But surely this shouldn't be necessary?

Other info:
Running on MacOS 10.13.2, node-modbus version 4.0.1

Is there any documentation about this package?
I would like to know all client methods/events. Is there any method like client.isConnected() to know if the client is connected instead of make all reads inside the on 'connect'?
Is there a way to provide a queue of reads?

Is there a way to set the unit ID of a Modbus Serial/TCP client? Can't find any reference function like setID in the code.

Hello, I try with this example (Try to connect and read holding registers from address 0 to 10): https://gist.github.com/cpfarher/a97aa614b9cf11743e29d2a7430e8610

This is the output:
npm run-script main

[email protected] main /home/chris/test-modbus-serial
node main.js

INFO : ModbusClientSerial log level: debug
DEBUG : ModbusClientSerial set on send method
DEBUG : ModbusClientSerial serialport settings: undefined

node: 8.11.3
"node-modbus": "^4.3.0"