diag_force_listen_only with no response expected always returns an error

[scully-jmccarthy]

When performing a diag_force_listen_only operation with no_response_expected=True and the device supports the command, and thus no response is expected, the pymodbus library always returns a spurious error.

Example:

    print("Set listen only")
    try:
        # See all calls in client_calls.py
        rr = await client.diag_force_listen_only(device_id=1, no_response_expected=True)
    except ModbusException as exc:
        print(f"Received ModbusException({exc}) from library")
        client.close()
        assert 0
    if rr.isError():
        print(f"Received exception from device ({rr})")

Output

Set diag listen only
2025-10-10 10:33:50,895 DEBUG transport:375 send: 0x1 0x8 0x0 0x4 0x0 0x0 0xa1 0xca
Received exception from device (ExceptionResponse(dev_id=1, function_code=255, exception_code=0))

I have confirmed with an oscilloscope that there is no response being sent back by the server device, so this exception response is internal to the library.

The behavior was validated to be correct when no_response_expected=False
Example:

    print("Set listen only")
    try:
        # See all calls in client_calls.py
        rr = await client.diag_force_listen_only(device_id=1, no_response_expected=False)
    except ModbusException as exc:
        print(f"Received ModbusException({exc}) from library")
        client.close()
        assert 0
    if rr.isError():
        print(f"Received exception from device ({rr})")

Output

Set listen only
2025-10-10 10:28:13,161 DEBUG transport:375 send: 0x1 0x8 0x0 0x4 0x0 0x0 0xa1 0xca
2025-10-10 10:28:15,147 DEBUG transport:375 Repeating....
2025-10-10 10:28:17,155 ERROR transaction:200 No response received after 1 retries, continue with next request
Received ModbusException(Modbus Error: [Input/Output] No response received after 1 retries, continue with next request) from library

[janiversen]

I am not sure, what the bug is ???

no_response_expected = True, means the call returns immediately....it can either raise an exception which would be wrong, since there are no bug, or return a future to satisfy the await. pymodbus returns an internal generated ExceptionResponse, and due to isError and the function_code it is clearly not a response to the request.

no_response_expected = False, means the call waits for a response or a timeout which raises a ModbusException.

If you have a better solution, then a pull request would be welcome.

[janiversen]

Please remember that if a device do not support ListenOnly it will (should) return an ExceptionResponse, with the function code...so it would be wrong to not have a return.

You might not have noticed, but this is the standard behavior for any request with no_response_expected.

[scully-jmccarthy]

I agree, that in the case listen only is not supported that there should be a Modbus exception response for it not being supported.

The bug is that when listen mode is supported and the call returns immediately with an error, as shown in my original message.

no_response_expected = True, means the call returns immediately....it can either raise an exception which would be wrong

This is the behavior I have shown

[scully-jmccarthy]

When the device supports listen only, the response should have no error. What I have shown is that when the device supports and does not respond, the library is returning an error with what appears to be a nonsensible payload.

Received exception from device (ExceptionResponse(dev_id=1, function_code=255, exception_code=0))

As I stated in my original report, I have an oscilloscope on the physical bus, and I can confirm that my device sends no response, thus the pymodbus library on the host side has an internal to the library bug that causes this behavior. The bug is when no response is sent by the server, the pymodbus client is falsely reported a received exception response, despite nothing being received from the serial transport layer.

[janiversen]

I am aware that the device do not respond, that is not the problem. The problem is how pymodbus returns an internal generated response to complete the request, this is how it was decided to do it.

ExceptionReponse pr definition returns isError set, so the only other option is to have a normal response, but that would be a lot more confusing.

I highly disagree with your analysis, how would you terminate the call..it is either returning something or raising a modbusException...and the library have chosen to return an ExceptionResponse, but with function_code 255 so it is clear that it is not from the device (which would have used the request function code).

You also forget to the bigger picture, the flag can be used on any request, and the return is the same.

However if you have a better idea, feel free to submit a pull request.

[scully-jmccarthy]

I disagree with you that showing a "normal response" when an operation succeeds is more confusing than an esoteric error. If someone is trying to use a library and is actively handling errors, getting spurious false errors just because that's how the library is written is more confusing. I appreciate that you have spent lots of time with this library, but you seem to very dismissive of others viewing behaviors as unexpected, which you chalk up as just them not knowing all of the ins and outs of the library. The purpose of using a library is to not have to implement it yourself or need to go read through all of the code just to be able to use it.

As a programmer, I compare adding the no_response_expected=true to something like fwrite() with a count of 0. If you call with a count of 0, the function returns 0 and no error is set in errno, not some spurious error. If I told it expect no response, then getting no response is not an error.

I think that you are missing the bigger picture and are stuck on the library level rather than library use. Imagine you were using this library in an installation with dozens of devices attached, and you got a response at the application level with function code 255. If you didn't have an oscilloscope on the line to know that it wasn't a device misbehaving but rather this library, you would be misguided in troubleshooting. Listen only was added to Modbus to be used to troubleshoot misbehaving devices, so this library is obfuscating the purpose of the functionality existing in the specification in the first place. Just because you don't expect function code 255 in your unit tests, doesn't mean that isn't a potential in the real world.

[janiversen]

The exception response is changed to values either outside the modbus standard or directly not possible to be returned from a device.

[scully-jmccarthy]

The exception response is changed to values either outside the Modbus standard or directly not possible to be returned from a device.

I reiterate "I think that you are missing the bigger picture and are stuck on the library level rather than library use." Last I checked, 255 fits in a byte, therefore it is a possible value returned from a device, albeit a misbehaving device. You are further incorrect, in that 255 IS defined in the Modbus specification, specifically as a reserved exception response:

Device ID 1 and Function code 255 are both inside the Modbus Standard, AND are possible values that a device can return. Just because they are not expected values does not mean they are not possible to be returned.

If anything, returning function code 0 instead of 255 would at least then fall into the Modbus standard of an invalid function code.

[janiversen]

Seems you did not have a look at what was actually merged.