# Node-red-contrib-modbus get and sequencer node status="stopped"

**URL:** <https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038>\
**Category:** General\
**Created:** [29 March 2023 03:21 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038 "2023-03-29T03:21:09Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![ssnowa](https://avatars.discourse-cdn.com/v4/letter/s/4af34b/32.png) [@ssnowa](https://discourse.nodered.org/u/ssnowa)\
**Post date:** [29 March 2023 03:21 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038/1 "2023-03-29T03:21:10Z")

</div>

I have a system running; redeployed some node changes and a sequencer and the initial getter node in the flow reached state "stopped". Now injecting a message results in an error complaining that the node is in state stopped. What can be done to get the stopped nodes back to "active"?

---

<div class="post-metadata">

**Author:** ![UnborN](https://avatars.discourse-cdn.com/v4/letter/u/4491bb/32.png) [@UnborN](https://discourse.nodered.org/u/UnborN)\
**Post date:** [29 March 2023 15:13 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038/2 "2023-03-29T15:13:51Z")

</div>

so you have a Modbus-Getter node that has some configuration  
and then you introduced a Modbus-Sequencer node that uses the **same** Config as the Getter ?  
if yes .. then i guess that would break the config of the Getter since this is the purpose of the Sequencer .. to dynamically change the config but without sharing your flow its hard to tell.

Is this Modbus TCP or Serial ?  
If TCP .. Can you create a totally new Config (add new modbus-client) for the one used in Sequencer ?

or better include the Read that you are doing with the Getter, in `msg.sequences` so the read is done by the Sequencer instead.

---

<div class="post-metadata">

**Author:** ![ssnowa](https://avatars.discourse-cdn.com/v4/letter/s/4af34b/32.png) [@ssnowa](https://discourse.nodered.org/u/ssnowa)\
**Post date:** [29 March 2023 19:10 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038/3 "2023-03-29T19:10:32Z")

</div>

I just want to know if there's something that can be done in a flow to address the state of a modbus node that has become "stopped" - then I could consider implementing a response via a status node.

- for example, when the received status is "stopped", send the message required to restart the node. Meanwhile, the "stopped" nodes have been returned to "active" after a subsequent deployment that changed a couple modbus nodes.

I don't understand your assertion that modbus-flex-sequencer is to "dynamically change the config".  
That node accepts one server, just like the getter, read, and write nodes. Right now, I'm directly encoding in the sequencer node a series of disjoint reads, rather than encoding msg.sequences to send to the sequencer node.

The single modbus getter I mentioned appears early in the flow, to read a single system configuration register; flow continues to the sequencer node upon success (so when there's a modbus error I get one error from the one getter node rather than many errors from the series of reads in the sequencer node). Since I had seen a read quietly fail, stopping a flow, I use a trigger to repeat the read until it succeeds, as discussed in this Steve Cope video starting about 4:20: [Using the Node-red Trigger Node - YouTube](https://www.youtube.com/watch?v=C0XHl88J7tc).  
[  
{  
"id": "2b2027fc14cd6102",  
"type": "change",  
"z": "fe2c538af62e54a6",  
"name": "Set Reading true",  
"rules": [  
{  
"t": "set",  
"p": "reading",  
"pt": "flow",  
"to": "true",  
"tot": "bool"  
}  
],  
"action": "",  
"property": "",  
"from": "",  
"to": "",  
"reg": false,  
"x": 870,  
"y": 60,  
"wires": [  
[  
"486b4963a32f6dc4"  
]  
]  
},  
{  
"id": "486b4963a32f6dc4",  
"type": "trigger",  
"z": "fe2c538af62e54a6",  
"name": "Trigger every 5 s",  
"op1": "1",  
"op2": "1",  
"op1type": "str",  
"op2type": "str",  
"duration": "-5",  
"extend": false,  
"overrideDelay": false,  
"units": "s",  
"reset": "",  
"bytopic": "all",  
"topic": "topic",  
"outputs": 1,  
"x": 1110,  
"y": 60,  
"wires": [  
[  
"8c5f3a28b5f422e8"  
]  
]  
},  
{  
"id": "8c5f3a28b5f422e8",  
"type": "modbus-getter",  
"z": "fe2c538af62e54a6",  
"name": "Read System Config",  
"showStatusActivities": true,  
"showErrors": true,  
"logIOActivities": false,  
"unitid": "",  
"dataType": "HoldingRegister",  
"adr": "1018",  
"quantity": "1",  
"server": "628fb65d.a65618",  
"useIOFile": false,  
"ioFile": "",  
"useIOForPayload": false,  
"emptyMsgOnFail": false,  
"keepMsgProperties": false,  
"x": 1380,  
"y": 60,  
"wires": [  
,  
[  
"842da3dac06b03a7",  
"02bf6c1f701e8beb",  
"218d377ced69a918"  
]  
]  
},  
{  
"id": "02bf6c1f701e8beb",  
"type": "change",  
"z": "fe2c538af62e54a6",  
"name": "",  
"rules": [  
{  
"t": "set",  
"p": "reset",  
"pt": "msg",  
"to": "true",  
"tot": "bool"  
}  
],  
"action": "",  
"property": "",  
"from": "",  
"to": "",  
"reg": false,  
"x": 1120,  
"y": 120,  
"wires": [  
[  
"486b4963a32f6dc4"  
]  
]  
},  
{  
"id": "842da3dac06b03a7",  
"type": "function",  
"z": "fe2c538af62e54a6",  
"name": "Read System Config",  
"func": "if (typeof msg.values !== 'undefined') {\n msg.payload = msg.values[0];\n} \nelse {\n msg.payload = null;\n}\nreturn msg;",  
"outputs": 1,  
"noerr": 0,  
"initialize": "",  
"finalize": "",  
"libs": ,  
"x": 1220,  
"y": 200,  
"wires": [  
[  
"a2b54feaf0fecaa8"  
]  
]  
},  
{  
"id": "628fb65d.a65618",  
"type": "modbus-client",  
"name": "Trumpf Truconvert System Control",  
"clienttype": "tcp",  
"bufferCommands": true,  
"stateLogEnabled": true,  
"queueLogEnabled": true,  
"failureLogEnabled": true,  
"tcpHost": "10.40.6.38",  
"tcpPort": "502",  
"tcpType": "DEFAULT",  
"serialPort": "/dev/ttyUSB",  
"serialType": "RTU-BUFFERD",  
"serialBaudrate": "9600",  
"serialDatabits": "8",  
"serialStopbits": "1",  
"serialParity": "none",  
"serialConnectionDelay": "100",  
"serialAsciiResponseStartDelimiter": "0x3A",  
"unit\_id": 1,  
"commandDelay": 200,  
"clientTimeout": 1000,  
"reconnectOnTimeout": true,  
"reconnectTimeout": 2000,  
"parallelUnitIdsAllowed": false  
}  
]  
The "Read System Config" node is one of the nodes that showed status "stopped" earlier. While in that state, all reads unsurprisingly produced a modbus error.

On the notion of using a status node, I see that status nodes configured to monitor individual modbus nodes fire when the configured server status changes, not only when the node monitored is triggered. That this would happen is predicable too by the status display under a node - my connect node, sequencers, getter and flex-write all go from showing "active" to "queueing" simultaneously when the flow triggered periodically to read a set of modbus registers is running, while the handful of write nodes (but not the flex-write) in subflows on the same editor tab show only "active". Consequently, where I monitor sequencers, I have flow variables indicating which one is active to stop the status flow for inactive sequencers.

---

<div class="post-metadata">

**Author:** ![UnborN](https://avatars.discourse-cdn.com/v4/letter/u/4491bb/32.png) [@UnborN](https://discourse.nodered.org/u/UnborN)\
**Post date:** [29 March 2023 22:12 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038/4 "2023-03-29T22:12:31Z")

</div>

i must have misinterpreted your original question ..  
i have now run a Modbus Slave simulator and attached a Status node on your Modbus Getter.

When the device is online and i trigger a Read, the `msg.status.text` changes that i see are  
**connected, queueing, reading done, active.**

When the device is offline and i trigger a Read i get a failure and the reconnect kicks in.  
**failure, reconnecting after 2000 msec., timeout, initialize, reconnecting after 2000 msec ..**

I neither case did i see a state "stopped". When does that happen ?

But besides that .. what do you want to do when the device is offline / stopped / failed to reply ?  
In my project for example, instead of using a Status node to re-trigger a read, I do my reads every x seconds and have the Modbus nodes set to produce an "Empty msg on Modbus fail"

![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/2/b/2bfc3b4a917aaff4d009387f97d7fc80cf6e1396.png)

and then handle it by settings the failed reply's payload to null (as i see you try to do in your function node)  
if it was a successful read I just send the value

```javascript
if (msg.payload == "" || msg.hasOwnProperty('error')) {
    msg.payload = null;
}
else {
    msg.payload = msg.payload[0];
}

return msg;

```

Test Flow

```auto
[{"id":"842da3dac06b03a7","type":"function","z":"7bdde9e9b6e1d37d","name":"Read System Config","func":"if (msg.payload == \"\" || msg.hasOwnProperty('error')) {\n msg.payload = null;\n}\nelse {\n msg.payload = msg.payload[0];\n}\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":350,"y":520,"wires":[["67b20ca16098f323"]]},{"id":"5bcc20071e8a1ef8","type":"inject","z":"7bdde9e9b6e1d37d","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":220,"y":380,"wires":[["d816410827ad688b"]]},{"id":"67b20ca16098f323","type":"debug","z":"7bdde9e9b6e1d37d","name":"debug 37","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":560,"y":520,"wires":[]},{"id":"5e73b141c292a3ce","type":"debug","z":"7bdde9e9b6e1d37d","name":"debug 38","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":780,"y":320,"wires":[]},{"id":"49a195ae72e090ad","type":"modbus-flex-getter","z":"7bdde9e9b6e1d37d","name":"","showStatusActivities":true,"showErrors":true,"showWarnings":true,"logIOActivities":false,"server":"628fb65d.a65618","useIOFile":false,"ioFile":"","useIOForPayload":false,"emptyMsgOnFail":true,"keepMsgProperties":false,"delayOnStart":false,"startDelayTime":"","x":580,"y":380,"wires":[["5e73b141c292a3ce","842da3dac06b03a7"],[]]},{"id":"d816410827ad688b","type":"function","z":"7bdde9e9b6e1d37d","name":"1018","func":"msg.payload = {\n 'fc': 3,\n 'unitid': 1,\n 'address': 1018,\n 'quantity': 1\n}\n\nreturn msg","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":370,"y":380,"wires":[["49a195ae72e090ad"]]},{"id":"628fb65d.a65618","type":"modbus-client","name":"Trumpf Truconvert System Control","clienttype":"tcp","bufferCommands":true,"stateLogEnabled":true,"queueLogEnabled":true,"failureLogEnabled":true,"tcpHost":"10.40.6.38","tcpPort":"502","tcpType":"DEFAULT","serialPort":"/dev/ttyUSB","serialType":"RTU-BUFFERD","serialBaudrate":"9600","serialDatabits":"8","serialStopbits":"1","serialParity":"none","serialConnectionDelay":"100","serialAsciiResponseStartDelimiter":"0x3A","unit_id":"1","commandDelay":"200","clientTimeout":"1000","reconnectOnTimeout":false,"reconnectTimeout":"2000","parallelUnitIdsAllowed":false}]

```

maybe this "Empty msg on Modbus fail" is something you can implement in your bigger flow and helps simplify things instead on relying on the Status nodes.

---

<div class="post-metadata">

**Author:** ![ssnowa](https://avatars.discourse-cdn.com/v4/letter/s/4af34b/32.png) [@ssnowa](https://discourse.nodered.org/u/ssnowa)\
**Post date:** [30 March 2023 17:02 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038/5 "2023-03-30T17:02:17Z")

</div>

I don't know just how the read and sequencer nodes became "stopped", except that it happened as a consequence of deploying Modified Nodes where some of the modifications involved modbus-write and modbus-flex-write nodes; the deploy happened while the flow was running, doing periodic modbus reads from the same server as the writes use.

Thanks for the reminder about "Empty msg on Modbus fail" - heretofore I've been assuming errors are thrown, but I understand that to get catchable errors one needs to have set DEBUG=contribModbus\*; it'll be better not to rely on nodered configuration since it'll eventually be running on other systems than the one I am developing on.

The status nodes monitoring sequence nodes currently aren't being used to detect errors, just the completion of operations. I suppose I can instead rely upon the order of read operations in the sequence and just branch off the response to the last one to continue the flow.

---

<div class="post-metadata">

**Author:** ![UnborN](https://avatars.discourse-cdn.com/v4/letter/u/4491bb/32.png) [@UnborN](https://discourse.nodered.org/u/UnborN)\
**Post date:** [31 March 2023 01:15 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038/6 "2023-03-31T01:15:19Z")

</div>

may i ask what version of **node-red-contrib-modbus** nodes you are using ?  
I found some Github issues that could be related to what you are seeing with the "stopped" state  
( [source1](https://github.com/BiancoRoyal/node-red-contrib-modbus/issues/185), [source2](https://github.com/BiancoRoyal/node-red-contrib-modbus/issues/225) ) apparently this is fixed and the error handled properly in newer versions of Modbus

---

<div class="post-metadata">

**Author:** ![ssnowa](https://avatars.discourse-cdn.com/v4/letter/s/4af34b/32.png) [@ssnowa](https://discourse.nodered.org/u/ssnowa)\
**Post date:** [31 March 2023 15:20 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038/7 "2023-03-31T15:20:30Z")

</div>

thanks for your continued attention. I am using node-red-contrib-modbus 5.23.2, on Nodered v3.0.2.

---

<div class="post-metadata">

**Author:** ![UnborN](https://avatars.discourse-cdn.com/v4/letter/u/4491bb/32.png) [@UnborN](https://discourse.nodered.org/u/UnborN)\
**Post date:** [31 March 2023 17:42 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038/8 "2023-03-31T17:42:15Z")

</div>

try the latest modbus `5.25.0` .. maybe the developers fixed something related to your issue ([changelog](https://github.com/BiancoRoyal/node-red-contrib-modbus/blob/master/CHANGELOG.md))

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [30 May 2023 17:42 UTC](https://discourse.nodered.org/t/node-red-contrib-modbus-get-and-sequencer-node-status-stopped/77038/9 "2023-05-30T17:42:43Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.