# Issues with node-red-node-serialport Module

**URL:** <https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455>\
**Category:** General\
**Tags:** node-red-node-serialport\
**Created:** [3 June 2024 08:16 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455 "2024-06-03T08:16:00Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![khalil\_khalil](https://avatars.discourse-cdn.com/v4/letter/k/ea666f/32.png) [@khalil\_khalil](https://discourse.nodered.org/u/khalil_khalil)\
**Post date:** [3 June 2024 08:16 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/1 "2024-06-03T08:16:00Z")

</div>

Hello,

I have encountered issues while using the `node-red-node-serialport` v2.0.2 (latest version). Here are the configuration parameters for the "serial request" node:

1. `msg.timeout` is the timeout (in ms) after which the incoming message is propagated to the output with `msg.status` set to "ERR\_TIMEOUT" and no payload. If not present, the default value is 10000 ms (10s).
2. `msg.count` if set, will override the configured number of characters as long as it is less than the configured number.
3. `msg.waitfor` must be a single character, escape code, or hex code. If set, the node will wait until it matches that character in the stream and then start the output.

My requirement is to find a configuration to achieve the following: I have a device that, when I send a serial command, returns a message. The delay between sending and receiving is not fixed and can vary, sometimes it’s 100 ms, 300 ms, or even 1 second. I want to set a fixed `msg.timeout` to wait for the serial response. If the device does not return any data within the defined timeout, it should return "ERR\_TIMEOUT". However, if the device returns data within the timeout, the data should be displayed immediately without waiting for the `msg.timeout` to finish.

I do not want any splitting of the returned data since the responses from the device contain different characters each time. Here are some examples of responses:

- Response 1: contains "\n\r xxxx \r\n"
- Response 2: contains "\n\r xxxx"
- Response 3: contains "xxxx \r\n"
- Response 4: contains "xxxx"

In my Node-RED flow, I have followed all the steps to use this serial request configuration, but I encountered a problem. When using `msg.timeout` and receiving, for example, the following response: "\n\r xxxx \r\n", it immediately splits the response and only displays "\n".

serial request configuration :

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/f/0/f08dd583d0a9b21cd91e3537dae8a70bfd124f76.png)

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [3 June 2024 08:22 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/2 "2024-06-03T08:22:29Z")

</div>

> [@khalil\_khalil](#):
>
> I have a device

What exactly is "the device"?

What is the serial protocol?

Are you in control of what the device sends back (i.e. if it doesnt have a well defined response pattern/protocol, are you in a position to change that?)

I ask because if it ALWAYS ended with a specific control character, then this would be pretty simple.

If not, there there are a few threads on the forum about reconstructing the serial data using a temporary buffer.

---

<div class="post-metadata">

**Author:** ![khalil\_khalil](https://avatars.discourse-cdn.com/v4/letter/k/ea666f/32.png) [@khalil\_khalil](https://discourse.nodered.org/u/khalil_khalil)\
**Post date:** [3 June 2024 08:48 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/3 "2024-06-03T08:48:44Z")

</div>

The device I'm referring to is an industrial card connected via an RS232 cable. Each time a command is sent to it, it returns a different response. As I explained earlier:

- Response 1 for Command 1: contains "\n\r xxxx \r\n"
- Response 2 for Command 2: contains "\n\r xxxx"
- Response 3 for Command 3: contains "xxxx \r\n"
- Response 4 for Command 4: contains "xxxx" And so on.

Regarding the serial protocol, unfortunately, the device doesn't adhere to a consistent response pattern or protocol. It returns varying responses based on the command sent.

I'm not directly in control of what the device sends back, and it doesn't consistently end with a specific control character. This variability in response patterns complicates the data handling process.

If you have any suggestions or guidance on reconstructing the serial data using a temporary buffer, I would greatly appreciate it.

Thank you for your assistance.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [3 June 2024 09:48 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/4 "2024-06-03T09:48:27Z")

</div>

> [@khalil\_khalil](#):
>
> - Response 1 for Command 1: contains "\n\r xxxx \r\n"
> - Response 2 for Command 2: contains "\n\r xxxx"
> - Response 3 for Command 3: contains "xxxx \r\n"
> - Response 4 for Command 4: contains "xxxx" And so on.

Is that what you have determined from looking at the node-red debug?

what i mean to say is, it _kinda_ looks like each response is terminated with `\n\r` but your current setup is splitting on a time base & you are getting part responses.

You might need to do a serial capture and post that for us to see if we can formulate a better means of correctly handling your data.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [3 June 2024 09:55 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/5 "2024-06-03T09:55:23Z")

</div>

I agree. I would start by setting it to always split on \n and then monitor the debug. I would then remove any \r before further processing.

---

<div class="post-metadata">

**Author:** ![khalil\_khalil](https://avatars.discourse-cdn.com/v4/letter/k/ea666f/32.png) [@khalil\_khalil](https://discourse.nodered.org/u/khalil_khalil)\
**Post date:** [3 June 2024 09:59 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/6 "2024-06-03T09:59:49Z")

</div>

![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/2/6/2627388924bac400a828246552a9fd53add2efc8.png)  
debug node-red

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [3 June 2024 10:04 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/7 "2024-06-03T10:04:08Z")

</div>

Sorry but your image is at least 70% darkgrey with nothing in it and the detail parts are too small to read.

Also, please answer questions posted.

> [@Steve-Mcl](#):
>
> > [@khalil\_khalil](#):
> >
> > - Response 1 for Command 1: contains "\n\r xxxx \r\n"
> > - Response 2 for Command 2: contains "\n\r xxxx"
> > - Response 3 for Command 3: contains "xxxx \r\n"
> > - Response 4 for Command 4: contains "xxxx" And so on.
> 
> Is that what you have determined from looking at the node-red debug?

Lastly, a screenshot is not _really_ a serial capture. A serial capture is either a hardware or software device that logs the EXACT bytes transmitted and received. It would be helpful to determine the best way to handle this.

---

<div class="post-metadata">

**Author:** ![khalil\_khalil](https://avatars.discourse-cdn.com/v4/letter/k/ea666f/32.png) [@khalil\_khalil](https://discourse.nodered.org/u/khalil_khalil)\
**Post date:** [3 June 2024 10:11 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/8 "2024-06-03T10:11:40Z")

</div>

![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/f/8/f820865ac729cd9a8851379e0a02d929a5c03b32.png)

Is that what you have determined from looking at the node-red debug?

--\>yes

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [3 June 2024 10:19 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/9 "2024-06-03T10:19:37Z")

</div>

> [@khalil\_khalil](#):
>
> Is that what you have determined from looking at the node-red debug?
> 
> --\>yes

then it seems to be messed up due to your settings.

As far as I can see, every response is terminated with CRLF but there are (it appears) some extra CRLFs in there - possibly due to your serial port settings but on the whole, it looks like whoever wrote the protocol didn't really care about the pain it would cause an integrator. It looks more suited to a telnet session!

* * *

Question: Where was the data in that screenshot generated? From your node-red data?

Question: Can you post that as text instead of a screenshot?

Question: Can you capture raw bytes to file (without any pre-processing? e.g. does it REALLY send `<CR><LF>` or did you interpret those for readability?

---

<div class="post-metadata">

**Author:** ![khalil\_khalil](https://avatars.discourse-cdn.com/v4/letter/k/ea666f/32.png) [@khalil\_khalil](https://discourse.nodered.org/u/khalil_khalil)\
**Post date:** [3 June 2024 10:36 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/10 "2024-06-03T10:36:36Z")

</div>

> Question: Where was the data in that screenshot generated? From your node-red data?

Answer: "No, it was from Docklight scripting, which is a serial reading software."

> Question: Can you post that as text instead of a screenshot?

```auto
2024-04-01 : 07:15:53,8548[TX]::GN 1 2E7A<CR>
2024-04-01 : 07:15:54,0561[RX]::<LF><CR>ME20002004 OK 54b5<CR><LF>
2024-04-01 : 07:15:54,3459[TX]::MI 1 39F9<CR>
2024-04-01 : 07:15:54,5469[RX]::<LF><CR>32 OK 5a87<CR><LF>
2024-04-01 : 07:15:54,7968[TX]::ME 89A7<CR>
2024-04-01 : 07:15:54,9966[RX]::<LF><CR>3 OK 11ba<CR><LF>
2024-04-01 : 07:15:55,2295[TX]::GN 2 7B29<CR>
2024-04-01 : 07:15:56,2801[RX]::<LF><CR>1SAG10234621 OK 0bef<CR><LF>
2024-04-01 : 07:15:56,4610[TX]::GY 0878<CR>
2024-04-01 : 07:15:56,6620[RX]::<LF><CR>2024/04/01-W1 07:18:55 80 OK c800<CR><LF>
2024-04-01 : 07:15:56,8120[TX]::SN 7 "253972606_B" ABA6<CR>
2024-04-01 : 07:15:57,0145[RX]::<LF><CR>OK c4c8<CR><LF>
2024-04-01 : 07:15:57,1085[TX]::GN 7 84DC<CR>
2024-04-01 : 07:15:57,3094[RX]::<LF><CR>25398566_B OK 5000<CR><LF>
2024-04-01 : 07:15:59,7265[TX]::SP 1 1ADB<CR>
2024-04-01 : 07:16:01,7770[RX]::<LF><CR>OK c4c8<CR><LF>
2024-04-01 : 07:16:03,3317[TX]::CB 0 DB7F<CR>
2024-04-01 : 07:16:03,5335[RX]::<LF><CR>þ˜ž˜ xàx˜€
2024-04-01 : 07:16:09,1439[TX]::GN 1 2E7A<CR>
2024-04-01 : 07:16:09,3455[RX]::<LF><CR>ME240900002004 OK 54b5<CR><LF>
2024-04-01 : 07:16:09,4115[TX]::SC "U0JPWAAAAAAAAAAAAAAAAAUAAAAACkFFUy0xMjgtS1cFEAAAAAdrZXlfMDAxBgAAAAAFU0hBLTEAAAAAAAAAAE1FVEEAAAEAAAAABzg1MjU0MTQAAAAAAAAAAAAAAAAATUVUQQAAAgAAAAAJMjUzOTcyNjA2AAAAAAAAAAAAAABNRVRBAAACEAAAAA5LU04yNDA1MTE0Mjg2MQAAAAAAAEdTREMAAEtGAAAAENfsJl5t51KWu+jhyNqf1PwAAAAf8hnjn9eI8W5XiIADuYhAqJobV8Clb6QlwAAqmDfWwfpCY4ilweJC+cSNJ17qAgAAAAAAAAAAAAAAAEdTREMAAVJEAAAAOEOhG0Ue981BexEyvFxmL8eTIPPelZddR5GAqZHc8Cf52uAzKwiZ3ZsbcLGLdPDnpywCtIqiuTV9AAAAAAAAAAAR1NEQwABAQYAAAAoVjimDNOQytu9dsd2Xz/rx8s0OhChnIOK8BUty9or3NMFMJsOGPUhDQAAAAAAAAAAAAAAAEdTREMAAQEhAAAAKFY4pgzTkMrbvXbHdl8/68fLNDoQoZyDivAVLcvaK9zTBTCbDhj1IQ0AAAAAAAAAAAAAAABHU0RDAAEBIgAAACj69/KUOEuYrhbfpLDWk+IuSBmOkcAQ3p5QDuGaQFy3ASNxPZIxdKT+AAAAAAAAAAAAAAAAR1NEQwABAQEAAAAonBQKahoKNWaBNsO0mBKgf8hnjn9eI8W5XiIADuYhAqJobV8Clb6QlwAAAAAAAAAAAAAAAEdTREMAAQEgAAAAKGodEdlVj9Pv9mjUGUq4Qkwk2mjie8+zEfAm09ORXQtPO5TEJS/AV88AAAAAAAAAAAAAAABHU0RDAAFMSwAAAGiA0ZlLFenyeOsIOBLQQrA+xoPbTSR4fxbvgbaAH4IZ4VvWkevRwcRuwFVrejCa8feOEI0oo5i5c/uQdk/gvJPbKKZtWXZdcHRbvbFA0lcra6SKLUnxjsbcLGLdPDnpywCtIqiuTV95/AAAAAAAAAAAAAAAAFNJR05HkfvExcIDAEFMuihR+jiyG4u1xfq6XkfyIhtB+ITETj9Ca2K1JDfB" 04B6<CR>
2024-04-01 : 07:16:14,4646[RX]::<LF><CR>"U0JPWAAAAAAAAAAAAAAAAAUAAAAACkFFUy0xMjgtS1cFEAAAAAdrZXlfMDAxBgAAAAAFU0hBLTEAAAAAAAAAAE1FVEEAAAEAAAAABzg1MjU0MTQAAAAAAAAAAAAAAAAATUVUQQAAAgAAAAAJMjUzOTcyNjA2AAAAAAAAAAAAAABNRVRBAAACEAAAAA5LU04yNDA1MTE0Mjg2MQAAAAAAAE1FVEEAABAAAAAABFBBU1NNRVRBAAAQAQAAAAAAACkFFUy0xMjgtS1cFEAAAAAdvrqDR8lQmypfuObsRQx298zd/xmBU9NZ122ClJ2Cc=" OK 1800<CR><LF>
2024-04-01 : 07:16:25,7810[TX]::FR E3B2<CR>
2024-04-01 : 07:16:52,7116[RX]::<LF><CR><CR><LF> Resetting ext flash..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................OK<CR><LF> Resetting...<LF><CR>We<CR><LF>Service components: 23, DB size: 174 bytes.<CR><LF>Cosem objects: 719, DB size: 6232 bytes, 2 records.<CR><LF>Total DB size: 6406 bytes.<CR><LF>lcome on the CLI monitor<LF><CR>Type - at any time to go back to root menu<LF><CR>(Press ? for help or ? <command> for help on a specific command)<LF><CR>
2024-04-01 : 07:16:54,2598[TX]::IC FFC1<CR>
2024-04-01 : 07:16:54,4597[RX]::<LF><CR> OK f386<CR><LF>

```

> Question: Can you capture raw bytes to file (without any pre-processing? e.g. does it REALLY send or did you interpret those for readability?

Response: "The card itself sends '\r\n', not me." In certain returns, it does not contain "", for example: `"<LF><CR>þ˜ž˜ xàx˜€"`

---

<div class="post-metadata">

**Author:** ![khalil\_khalil](https://avatars.discourse-cdn.com/v4/letter/k/ea666f/32.png) [@khalil\_khalil](https://discourse.nodered.org/u/khalil_khalil)\
**Post date:** [3 June 2024 10:50 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/11 "2024-06-03T10:50:09Z")

</div>

Is there a FIFO method without waiting for CR LF or any specific command (similar to TCP principles)?

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [3 June 2024 10:59 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/12 "2024-06-03T10:59:03Z")

</div>

> [@khalil\_khalil](#):
>
> `<CR><LF>lcome on the CLI monitor<LF><CR>Type - at any time to go back to root menu<LF><CR>(Press ? for help or ? <command> for help on a specific command)<LF><CR>`

This is a huge clue.

the interface is designed for human interaction (as I guessed earler)

Unless the device has a proper integration protocol (like ModBus or other well formated protocol) this is not going to be a pleasant task,

> [@khalil\_khalil](#):
>
> Is there a FIFO method

You can invent whatever you need to get the job done.

For example, you could use context and JS arrays in a function node to store each incoming value in an array and use the built in `push` / `pop` / `shift` / `unshift` functions to make a FIFO

Some resources:

1. [Array - JavaScript | MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)
2. [Working with context : Node-RED](https://nodered.org/docs/user-guide/context)

---

<div class="post-metadata">

**Author:** ![khalil\_khalil](https://avatars.discourse-cdn.com/v4/letter/k/ea666f/32.png) [@khalil\_khalil](https://discourse.nodered.org/u/khalil_khalil)\
**Post date:** [3 June 2024 12:56 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/13 "2024-06-03T12:56:45Z")

</div>

> [@Steve-Mcl](#):
>
> You can invent whatever you need to get the job done.

Is there a First In, First Out method in the configuration of the `node-red-node-serialport` node (i.e., data received is directly sent to the output node without delimiter (split) characters), or do I need to modify the `node-red-node-serialport` code to meet my requirements?

Regarding the Modbus node, I will test this node. Can we change the baud rate with the Modbus node and open/close the connection like with the serialport node?

---

<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:** [1 September 2024 12:56 UTC](https://discourse.nodered.org/t/issues-with-node-red-node-serialport-module/88455/14 "2024-09-01T12:56:56Z")

</div>

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