Add extended response filter support to ModbusBridge - #438

I am afraid I have some objections against your PR.

Primarily it does not add real benefit as compared to the existing filter hooks, since the extraction of both address and length can easily be done within a regular filter callback.

Second, and even more relevant, the proposed change will try to extract these values even from Modbus messages that may have a completely different structure and hence will result in invalid data.

Changed to include the full request message reference along the response.

How is this now supposed to work? Where do you get the matching request and response messages when calling the filter?

These are populated in src/ModbusBridgeTemp.h, bridgeWorker, line 314-319

Can you give me an example on how to make a use from the extended callback?

I have implemented it like the following snipit. It allows to change the response parsing to be depended upon the request:

// filterResponseEx() - to be applied to returning responses
ModbusMessage filterResponseEx(ModbusMessage response, ModbusMessage request)
{
    if (request.getFunctionCode() == 0x04)
    {
        uint16_t address;       // Initial address requested
        uint16_t words;         // Number of records requested

        request.get(2, address);
        request.get(4, words);

        //Serial.print("Got Addr: "); Serial.print(address); Serial.print(", Count: "); Serial.print(words); Serial.print(" --> ");
        //PrintResponse(response);
        ModbusRequestResponseMatcher::CheckForDataCaptureNeed(address, words, response);

        // Just dump out response
        HEXDUMP_N("Response", response.data(), response.size());    
    }

    // In any case forward the response
    return response;
}

I see, thank you. So basically who would need the plain response filter any more? How about replacing it with yours? I actually did not see the availability of the causing request for a response when writing the filter hooks 😆

I see, thank you. So basically who would need the plain response filter any more? How about replacing it with yours? I actually did not see the availability of the causing request for a response when writing the filter hooks 😆

You still need the original one in case you want to modify the request. And also to ensure this is not breaking existing implementations, I would advice to keep both.

@roelandkluit Thank you very much for your contribution.