Modbus Serial Device only works once: connection is lost under 2023.9.1+

[HarrisonPace]

The problem

Possibly an upstream change, but since the upgrade of pymodbus v3.5.0 in 2023.9.1, my Modbus Serial connection only works one time before it fails.

In releases prior to 2023.9.1, the modbus connection is stable. The fixes added in 2023.9.2 have not resolved my connection issues. I see these errors in my Logs:

What version of Home Assistant Core has the issue?

2023.9.2

What was the last working version of Home Assistant Core?

2023.9.0

What type of installation are you running?

Home Assistant OS

Integration causing the issue

modbus

Link to integration documentation on our website

https://www.home-assistant.io/integrations/modbus/

Diagnostics information

No response

Example YAML snippet

modbus:
  - name: Curtain Controller
    type: serial
    method: rtu
    port: /dev/serial/by-id/usb-www.freetronics.com_0003_95437313934351505191-if00
    baudrate: 9600
    stopbits: 1
    bytesize: 8
    parity: N
    delay: 2
    timeout: 5
    close_comm_on_error: false
    switches:
      #Curtain Controller
      - name: "Bedroom Curtain - UP"
        slave: 1
        address: 0
        write_type: coil
      - name: "Bedroom Curtain - Down"
        slave: 1
        address: 1
        write_type: coil
      - name: "Bedroom Curtain - Stop"
        slave: 1
        address: 2
        write_type: coil

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant]

Hey there @adamchengtkc, @janiversen, @vzahradnik, mind taking a look at this issue as it has been labeled with an integration (modbus) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of modbus can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign modbus Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

modbus documentation
modbus source
_{^{(message by IssueLinks)}}

[janiversen]

Please read the documentation, your configuration ask for a termination in case of an error.

[janiversen]

Just to be clear pymodbus was upgraded to 3.5.1 not 3.5.0 which have a problem.

[HarrisonPace]

Please read the documentation, your configuration ask for a termination in case of an error.

Reviewing the documentation I see I have set it to false, implying it does not close the connection, no?

close_comm_on_error: false

Also it was working in all versions prior and including >2023.9.0. I have made no yaml changes.

[HarrisonPace]

Just to be clear pymodbus was upgraded to 3.5.1 not 3.5.0 which have a problem.

Understood, to be clear the communication closed is a result of a manual reset of the Modbus Component.

I retested the behaviour, in 2023.9.0 it works and in both 2023.9.1 & 2023.9.2 it does not work.

@janiversen I would appreciate the issue is reopened, until it's addressed.

[janiversen]

But it is addressed your problem is the configuration, at least reading from your documentation.

There have been a lot of documented changed between 2023.0 and 2023.9.2, and the bump of pymodbus might very well be cause why you have a configuration problem (just to be clear, the configuration is correct, but you seem to want something that is not default behaviour).

You did not mention "manual reset" in your description, how do you expect us to guess that. You need to provide a debug log as pr modbus documentation, otherwise we have no way of helping you.

I will reopen the issue, and give you a change to provide the debug.log, but it is still correct that your configuration asks for termination as soon as an error is detected.

[janiversen]

Just wondering what is a "manual reset", I do not recall that the integration support "reset" nor that HA offers that.

[HarrisonPace]

But it is addressed your problem is the configuration, at least reading from your documentation.

I don't really follow what your implying...

close_comm_on_error: false

Based on the the english interpretation of ["close comm(s) on error" = false], implies it should not close comms on error, no?

If you see a problem with the configuration it would be appreciated to explicitly point out what, I haven't changed my configuration in the last 6 releases. Everything prior to 2023.9.0 was working.

There have been a lot of documented changed between 2023.0 and 2023.9.2, and the bump of pymodbus might very well be cause why you have a configuration problem (just to be clear, the configuration is correct, but you seem to want something that is not default behaviour).

If it's an option to change the default behaviour to continue on error, it should be supported, no?

My configuration was working in HASS 2023.9.0, versions 2023.9.1+ have issues for my specific use case, however communication to my Siemens PLC over Modbus TCP continues to work fine.

The last 3 comments are people running 2023.9.2, who also continue to have issues: #100063 (comment)

It seems there may be an underlying problem here?

You did not mention "manual reset" in your description, how do you expect us to guess that. You need to provide a debug log as pr modbus documentation, otherwise we have no way of helping you.

OK, I'm happy to provide a debug log, happy to supply whatever you need. Here is the debug log:

home-assistant_2023-09-17T13-51-20.593Z.log

I will reopen the issue, and give you a change to provide the debug.log, but it is still correct that your configuration asks for termination as soon as an error is detected.

Please explain this to me, I am utterly confused by the documentation and this close_comm_on_error: false?

Just wondering what is a "manual reset", I do not recall that the integration support "reset" nor that HA offers that.

When I say reset the Modbus component, I simply imply that I reloaded the yaml:

Thanks for your continued support of this component @janiversen, apologies for any delayed replies, as a close family just got diagnosed with cancer and therefore I may be delayed in responding...

[janiversen]

Based on the the english interpretation of ["close comm(s) on error" = false], implies it should not close comms on error, no?

You do not need to interpret the english dictionary for me ! I never said that was the parameter, there are something like 4 parameters handling different versions of your problem

If you see a problem with the configuration it would be appreciated to explicitly point out what, I haven't changed my configuration in the last 6 releases. Everything prior to 2023.9.0 was working.

Nice for you that you haven't needed to change anything, but a bit of a surprise to me, considering what was change.

My job here is to solve problem in the code, not to make support, for that we have the forum and our documentation.

If it's an option to change the default behaviour to continue on error, it should be supported, no?

Of course any change is "supported", I do not understand what you want to say.

The last 3 comments are people running 2023.9.2, who also continue to have issues: #100063 (comment)

To be honest those are comments that help nobody ! where are their configuration and the debug log. #Metoo is not a way to help solve an issue, on the contrary it demotivates the maintainers.

home-assistant_2023-09-17T13-51-20.593Z.log

The log interesting, first of all you have a number of custom_components which might or might not affect the modbus integration.

Did you read the log it states clearly "This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant"

The debug log is made correctly, thanks.

Here is an example where modbus do not receive the expected and continue:

2023-09-17 23:50:30.094 DEBUG (SyncWorker_10) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2023-09-17 23:50:30.094 ERROR (SyncWorker_10) [homeassistant.components.modbus.modbus] Pymodbus: Curtain Controller: Modbus Error: [Input/Output] No Response received from the remote slave/Unable to decode response
2023-09-17 23:50:31.917 DEBUG (SyncWorker_5) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2023-09-17 23:50:31.917 DEBUG (SyncWorker_5) [pymodbus.logging] Running transaction 142

and here:

2023-09-17 23:50:41.943 DEBUG (SyncWorker_0) [pymodbus.logging] Getting transaction 159
2023-09-17 23:50:41.943 DEBUG (SyncWorker_0) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2023-09-17 23:50:42.023 DEBUG (SyncWorker_4) [pymodbus.logging] Transaction failed. (Modbus Error: [Invalid Message] Incomplete message received, expected at least 4 bytes (2 received)) 
2023-09-17 23:50:42.023 DEBUG (SyncWorker_4) [pymodbus.logging] Processing: 
2023-09-17 23:50:42.024 DEBUG (SyncWorker_4) [pymodbus.logging] Getting transaction 1
2023-09-17 23:50:42.024 DEBUG (SyncWorker_4) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2023-09-17 23:50:42.024 DEBUG (SyncWorker_4) [homeassistant.components.modbus.modbus] Pymodbus: Curtain Controller: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] Incomplete message received, expected at least 4 bytes (2 received)
2023-09-17 23:50:45.879 WARNING (MainThread) [homeassistant.components.mqtt.cover] Payload is not supported (e.g. open, closed, opening, closing, stopped): Active
2023-09-17 23:50:46.805 DEBUG (SyncWorker_3) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2023-09-17 23:50:46.805 DEBUG (SyncWorker_3) [pymodbus.logging] Running transaction 160

Apart from those, and a couple more similar, I see a modbus integration working.

There are no:

• "reset" as you confusingly called the "reload" (which is very different from a reset)
• There are reconnect
• There are no failing connect.

So in total I cannot see how the log shows that "modbus only connects once".

Please explain this to me, I am utterly confused by the documentation and this close_comm_on_error: false?

Read the documentation, if you need it written differently, then Pull Requests are welcome.

When I say reset the Modbus component, I simply imply that I reloaded the yaml:

Well it would be a lot more natural to "you reloaded the integration", otherwise we need to guess what you actually did.

The log does not contain a reload, as far as I can see.

Thanks for your continued support of this component @janiversen, apologies for any delayed replies, as a close family just got diagnosed with cancer and therefore I may be delayed in responding...

Sorry to hear, hope its a type easy to cure.

[HarrisonPace]

@janiversen I understand as a maintainer it can be fatiguing and you are donating your time. But I am also trying to improve software and resolve bugs, if I am experiencing this issue, it's likely other will too.

So in total I cannot see how the log shows that "modbus only connects once".

That is the behaviour, I can write to the Modbus Device Curtain (Coil), once and then it no longer works. After restarting Home Assistant it will work one time again and then stop. It only ever works once after reloading the Modbus Component or restarting.

[janiversen]

You have lost me. You wrote in the issue:

"Possibly an upstream change, but since the upgrade of pymodbus v3.5.0 in 2023.9.1, my Modbus Serial connection only works one time before it fails."

There are no reconnects in the log....then you tell me it happens after a "reset", but there are no "reload" in the log.

Now you tell me is a problem with the curtain, which have a couple of failures in the log, but the modbus integration continues to send and receive data.

Reporting bugs is a good thing, but reporting one bug, then changing it a couple of times, is really not the art to report a bug !

Right now I have NO IDEA whatsoever what your problem is....and the others that used #metoo, I have no idea if they have a problem or not.

This issue will be closed, unless there is a correct and fulfilling explanation of the problem together with a debug log showing the problem.

[HarrisonPace]

@janiversen I actually think you're been quite hostile. I am trying to be amiable and provide you with information but the tone in these messages is fairly hostile and condescending. I am closing this issue, noting the problem is not resolved.

I am going to fork the component from 2023.9.0 and use it as long as it's functional.

I never changed the issue, you're misunderstanding the messages leading to confusion.

[janiversen]

For the curtain problems in the log, it is your device that do not respond, that might be due to a wrong configuration (type of write, value etc), that is NOT a bug in the modbus integration.

If you can only send 1 command to your curtain, and then no more, that is something easy to pinpoint:

The log will show the first write as OK,

If the log shows the next command failing, then its likely a device problem,

If the log does not show the second command, then its likely a problem with how you send the service call.

If the log shows that the modbus integration sends the next commands, but your device does not respond (current error message), then there is likely between what your device expect and what you have configured.

You need to verify which it is, and then provide the debug log to show that.

[janiversen]

I am not being as polite as I could be..but how can you write:

"I never changed the issue, you're misunderstanding the messages leading to confusion."

There is a big difference between the serial connection only working once, and a single element (your curtain) have a problem.

Feel free to copy the old version. I simply cannot help without the proper information.