calling client.close() does not terminate the client process but causes a reconnect.

[janiversen]

Versions

• Python:
• OS:
• Pymodbus:
• Modbus Hardware (if used):

Pymodbus Specific

• Server: tcp/rtu/ascii - sync/async
• Client: tcp/rtu/ascii - sync/async

Description

What were you trying, what has happened, what went wrong, and what did you expect?

Code and Logs

# code and logs here.

# please use the following to format logs when posting them here
import pymodbus
pymodbus.pymodbus_apply_logging_config()

[ElTarget]

This is because the call function is connected by default during the process of sending packets

[janiversen]

Of course the client is connected when sending packets, this is done so to ensure an automatic reconnect if the server closes the connection. However the problem described is different, when the app calls client.close() it should not continue.

[janiversen]

I assume you are aware that the line you point out, is NOT an actual tcp/ip connect(), but it a method in our classes.

[ElTarget]

For example, if we call the read_coils() function, it will enter the transaction.py file, as long as we have a configuration client, then calling read_coils(), is to try to connect once, both to judge the connectivity and to connect. So I will judge client.socket before using it, this object exists in our different clients.

[janiversen]

You have lost me, I am not really sure what your idea are. BUT Pull requests are welcome and then we can review the suggested changes.

is_socket_open() is in serial.py not the general for all types, and it is because for serial we need to know if the communication is open (which is NOT the same as being connected).

[ElTarget]

Well.. I'm just giving an example. Because we use functions that will enter the transaction.py. I think this is why we manually client.close() and then use something like "read_coils()" to execute.

[janiversen]

The app (not pymodbus) uses client.close() when it wants to terminate the client, and continue doing other things, so the app expects the client to close connection and communication. The app will not do any more client calls.

The current version does however reconnects to the server after a delay instead of keeping it closed. The workaround at the moment is to do

   client.close()
   del client

but that is not a good solution.