Problem with Modbus integration and maybe duplicate _msgid

[Mamonetti]

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 (37.6 KB)

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

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:

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:

    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

[Mamonetti]

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