# Problem with Modbus integration and maybe duplicate \_msgid

**URL:** <https://discourse.nodered.org/t/problem-with-modbus-integration-and-maybe-duplicate-msgid/86439>\
**Category:** General\
**Tags:** modbus\
**Created:** [14 March 2024 18:54 UTC](https://discourse.nodered.org/t/problem-with-modbus-integration-and-maybe-duplicate-msgid/86439 "2024-03-14T18:54:17Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mamonetti](https://avatars.discourse-cdn.com/v4/letter/m/c6cbf5/32.png) [@Mamonetti](https://discourse.nodered.org/u/Mamonetti)\
**Post date:** [14 March 2024 18:54 UTC](https://discourse.nodered.org/t/problem-with-modbus-integration-and-maybe-duplicate-msgid/86439/1 "2024-03-14T18:54:17Z")

</div>

Hi,

I'm trying to integrate a heat recovery unit using Modbus RTU and **node-red-contrib-modbus**.

The flow I'm working in is here (sorry for the comments in Spanish btw):  
[flows\_integrationRecuperador.json](https://discourse.nodered.org/uploads/short-url/8YKlYHrIdhNgsFzOE2JqqdvGgkZ.json) (37.6 KB)

Here you also have a screenshot of a quick execution of the flow:

 ![screenshot](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/9/f/9fe98f5b31aa6cec252bed5c4ec6905eee95290f.jpeg)

At the beginning everything was running ok, but eventually I noticed that the loop got stuck. The problem appeared when a timeout was detected by the **READ** node ( **Modbus-Flex-Getter** ). As a result, an exception was caught by **catch READ** and the loop went back to the **task** node to handle the retries.

If you take a look at the screenshot, once the first exception is generated (debug node **debug catch READ** ), all the following messages include the same **\_msgid**. My guess is that there's a problem there because the last message sent through the first output of **task** (can be seen in debug node **msg1** ) is valid, and after that, nothing happens. Obviously there's a timeout (I'm forcing it now on purpose, I've disconnected the device), but I get no more exceptions.

Do you think this could be the cause? And if the answer is yes, how can this be solved? If you take a look at the function node **ERROR READ** , I _clear_ the message that's returned through the first output (the one sent back to **task** ) before returning it. Actually when I create again the message that's sent through the first output of **task** (the Modbus request), I also _clear_ it.

Final part of **ERROR READ** :

```auto
if (flow.get("debugIsEnabled")) {
    msg2 = {};
    
    msg2.taskStatus = status.taskStatus;
    
    node.send([null, msg2]);
}

msg = {};

return [msg, null];

```

Code of **task** where the message sent to the Modbus node (msg1) is cleared:

```auto
    case "SENDING_FIRST_GET":
        status.taskStatus = "WAITING_ACK_FIRST_GET";
        
        msg1 = {};
        
        msg1.payload = formatGetRequest();
        
        if (flow.get("extraDebugIsEnabled")) {
            msg4 = {};
            
            msg4.debug = "SENDING_FIRST_GET -> WAITING_ACK_FIRST_GET";
        }
        
        break;

```

Just FYI, in case you find some weird stuff in **task** , I'm still trying to figure out how to remove the warning indicators in switch statements with no break. I could remove a few useless jumps between nodes with it (I know it's only a warning, but I don't like to be constantly looking at these damn triangles 😄). Maybe newer versions provide some sort of /\* no break \*/ warning remover like eclipse? (I'm still using 2.x)

Regards

---

<div class="post-metadata">

**Author:** ![Mamonetti](https://avatars.discourse-cdn.com/v4/letter/m/c6cbf5/32.png) [@Mamonetti](https://discourse.nodered.org/u/Mamonetti)\
**Post date:** [15 March 2024 10:49 UTC](https://discourse.nodered.org/t/problem-with-modbus-integration-and-maybe-duplicate-msgid/86439/2 "2024-03-15T10:49:59Z")

</div>

Ok, it looks like the problem wasn't there. I decided to create a simple alternative flow which injects the Modbus requests in a synchronous way every 5 seconds (periodic injects) and still the problem was there (the second request got stuck and no timeout was generated).

Seeing this, I unmarked the **Reconnect on timeout** checkbox on the **modbus-client** configuration and voilà, it worked! Since I'm working with a serial port, I expected this flag to be related to reconnecting to the serial port when there's a problem, but I guess it's only necessary when working with Modbus/TCP clients, and as you can see, activating it has important side effects in this case 🤔

In general, **I'd recommend to include some tooltips in the configuration panels** of the different nodes (as well as in the configuration of the modbus-client) because it's not clear what happens when you enable/disable certain options.

I'll close this thread once I've confirmed it really works fine, but so far so good. And btw, these warnings disappear if you use **monaco** instead of **ace** as **codeEditor** (search for **codeEditor** in **settings.js** ).

Regards

---

<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:** [29 March 2024 10:50 UTC](https://discourse.nodered.org/t/problem-with-modbus-integration-and-maybe-duplicate-msgid/86439/3 "2024-03-29T10:50:35Z")

</div>

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