Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TCP modbus connection not restored after device restarted #100063

Closed
evaliukonis opened this issue Sep 10, 2023 · 36 comments
Closed

TCP modbus connection not restored after device restarted #100063

evaliukonis opened this issue Sep 10, 2023 · 36 comments
Assignees

Comments

@evaliukonis
Copy link

evaliukonis commented Sep 10, 2023

The problem

I am using Modbus over TCP. If I reboot the device or Wi-Fi access point HA does not connect again to Modbus. I need to click on reload in the YAML menu.
There is no error or logs. Just not working until reload or HA restarted.

What version of Home Assistant Core has the issue?

core-2023.9.x

What was the last working version of Home Assistant Core?

core-2023.8.4

What type of installation are you running?

Home Assistant Container

Integration causing the issue

No response

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

@dolenec
Copy link

dolenec commented Sep 10, 2023

Same problem was on 2023.9.0.
Something related with pymodbus 3.5.1 probably.. I hope that they are aware of this problem... currently solution is to stay on 2023.8.4.

@Swallowtail23
Copy link

This also appears to be triggered if the device loses comms temporarily. I have a couple of modbus-connected power monitors, connected over WiFi. They occasionally drop packets or are sluggish in responding. HA does this:

2023-09-11 09:37:51.303 ERROR (SyncWorker_14) [homeassistant.components.modbus.modbus] Pymodbus: Iammeter_3_modbus: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)

...drops modbus completely, all of the entities going to unavailable, and doesn't retry.
Run modbus.reload service and they come back.

@HarrisonPace
Copy link
Contributor

I'm having a similar issue with Modbus Serial, I have a device that often produces errors in the logs. Before upgrading to 2023.9.1, it would work fine, now it only works the first time after restarting the Modbus component via:
Settings -> YAML configuration reloading -> Modbus. Downgrading to 2023.8.4 solves the issue, So it's very likely a change upstream, in pymodbus 3.5.x:

image

As an aside, I don't think we should be upgrading the pymodbus library in minor releases unless there is a major bugfix. This isn't the first time an upstream change has caused problems for a lot of Modbus Users. 3.5.0 seems to have a few changes/

Additionally reports still been posted on this closed issue here: #99784

@petzi0815
Copy link

Same issue for me here. It used to work with core-2023.9.0 with the "close_comm_on_error: false" inserted but now after upgrading again even this line is not helping anymore. after a restart of HA it runs for some minutes until the sensors are not available anymore. seems to have an issue re-establishing the connection after it gets interrupted

Pymodbus: FoxESSInverterModbus: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)

@p4r4ll4x
Copy link

+1 Exactly the same issue here.

@ISNL-PimP
Copy link

Duplicate of #99784, should be fixed in #99988
Fix will probably be available in HA 2023.09.2.

@d4wn89
Copy link

d4wn89 commented Sep 12, 2023

I use an automation to fix the problem temporarily.


alias: Dienst= Modbus-Engine neustarten nach Verbindungsabbruch
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.total_dc_power
    to: unavailable
    for:
      hours: 0
      minutes: 5
      seconds: 0
condition: []
action:
  - service: modbus.reload
    data: {}
  - service: notify.mobile_app_patricks_iphone
    data:
      message: Modbus-Engine hat die Verbindung verloren. Neustart wurde veranlasst.
mode: single

@nbranquinho
Copy link

+1, I have the same problem

@dolenec
Copy link

dolenec commented Sep 12, 2023

+1

1 similar comment
@simp16
Copy link

simp16 commented Sep 13, 2023

+1

@HarrisonPace
Copy link
Contributor

Duplicate of #99784, should be fixed in #99988 Fix will probably be available in HA 2023.09.2.

It didn't seem to fix it for me, tried with 2023.9.2 to no avail, downgraded from 2023.9.2 to 2023.9.0 and it works again.

@simp16
Copy link

simp16 commented Sep 13, 2023

Duplicate of #99784, should be fixed in #99988 Fix will probably be available in HA 2023.09.2.

It didn't seem to fix it for me, tried with 2023.9.2 to no avail, downgraded from 2023.9.2 to 2023.9.0 and it works again.

It also works for me in 2023.9.0 but not in 2023.9.1 or 2023.9.2

@HarrisonPace
Copy link
Contributor

@simp16 Are you seeing errors in your logs, are you using TCP or Serial?

@nbranquinho
Copy link

For me, the 2023.9.2 version fixed. Since that, my modbus never reloaded again!

@simp16
Copy link

simp16 commented Sep 14, 2023

@simp16 Are you seeing errors in your logs, are you using TCP or Serial?

It is now working for me in 2023.9.2, but I think it is because the integration maintainer released a fix. I am using TCP.

@p4r4ll4x
Copy link

p4r4ll4x commented Sep 16, 2023

2023.9.2 does not fix it for me, it feels more stable, but the issue sill occurs.
I have an automation that restarts modbus when items become unavailable and it still triggers.
I have 64 modbus switches configured.

Pymodbus: wago_beneden: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)
00:32:58 – (ERROR) Modbus - message first occurred at September 13, 2023 at 18:11:15 and shows up 6 times

modbus wago_beneden communication closed
00:32:46 – (WARNING) Modbus - message first occurred at September 13, 2023 at 18:11:18 and shows up 9 times


@kevinkey619
Copy link

I'm still having this problem in 2023.9.2. I've done everything but wipe my HA install and start over from scratch! What am I doing wrong?!

Pymodbus: epever: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 4 bytes (0 received)

@dolenec
Copy link

dolenec commented Sep 16, 2023

Probably nothing.. after 4 days of working same happened to me.. simply stopped working.. restart solve problem but for how long?

@HarrisonPace
Copy link
Contributor

@dolenec Are you still experiencing issues, or is it stable now for you?

@dolenec
Copy link

dolenec commented Sep 25, 2023

@dolenec Are you still experiencing issues, or is it stable now for you?

From 2023.09.02 it is stable.. seems stable also on 2023.09.03.

@p4r4ll4x
Copy link

@dolenec Are you still experiencing issues, or is it stable now for you?

From 2023.09.02 it is stable.. seems stable also on 2023.09.03.

As mentioned by multiple people, the issue is not resolved in version 2023.09.02.
I'm now upgrading to 2023.09.03, i'll report here.

@dolenec
Copy link

dolenec commented Sep 25, 2023

@dolenec Are you still experiencing issues, or is it stable now for you?

From 2023.09.02 it is stable.. seems stable also on 2023.09.03.

As mentioned by multiple people, the issue is not resolved in version 2023.09.02.
I'm now upgrading to 2023.09.03, i'll report here.

For me it is stable.. Using TCP/IP modbus via yaml configuration (native config) + TCP/IP modbus via Node-RED + TCP/IP modbus via HACS integration..

@kevinkey619
Copy link

I'm still having this problem in 2023.9.2. I've done everything but wipe my HA install and start over from scratch! What am I doing wrong?!

Pymodbus: epever: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 4 bytes (0 received)

Update: Suddenly it's work for me again. :)

@p4r4ll4x
Copy link

@dolenec Are you still experiencing issues, or is it stable now for you?

From 2023.09.02 it is stable.. seems stable also on 2023.09.03.

As mentioned by multiple people, the issue is not resolved in version 2023.09.02. I'm now upgrading to 2023.09.03, i'll report here.

After updating to 2023.09.03, the issue appeared already. After reloading modbus, it is solved for some time. This happens every x hours with 64 modbus switches configured.

@dolenec
Copy link

dolenec commented Sep 25, 2023

@dolenec Are you still experiencing issues, or is it stable now for you?

From 2023.09.02 it is stable.. seems stable also on 2023.09.03.

As mentioned by multiple people, the issue is not resolved in version 2023.09.02. I'm now upgrading to 2023.09.03, i'll report here.

After updating to 2023.09.03, the issue appeared already. After reloading modbus, it is solved for some time. This happens every x hours with 64 modbus switches configured.

Which kind of modbus using? TCP/IP?

Can you share your config?

@p4r4ll4x
Copy link

p4r4ll4x commented Sep 25, 2023

@dolenec Are you still experiencing issues, or is it stable now for you?

From 2023.09.02 it is stable.. seems stable also on 2023.09.03.

As mentioned by multiple people, the issue is not resolved in version 2023.09.02. I'm now upgrading to 2023.09.03, i'll report here.

After updating to 2023.09.03, the issue appeared already. After reloading modbus, it is solved for some time. This happens every x hours with 64 modbus switches configured.

Which kind of modbus using? TCP/IP?

Can you share your config?

This config worked until i installed 2023.9.x

configuration.yaml:

modbus:
  - name: wago_beneden
    type: tcp
    host: x.x.x.x
    port: 502
    switches:
      - name: wago_beneden_DO01
        write_type: coil
        address: 512
        verify:
        scan_interval: 5
      - name: wago_beneden_DO02
        write_type: coil
        address: 513
        verify:
        scan_interval: 5
...
  - name: wago_garage
    type: tcp
    host: y.y.y.y
    port: 502
      - name: wago_garage_DO01
        write_type: coil
        address: 512
        verify:
        scan_interval: 5
      - name: wago_garage_DO02
        write_type: coil
        address: 513
        verify:
        scan_interval: 5
...

EDIT: i reviewed my code and it seems that i had older entries in switch.yaml. Since the hub reference was not used anymore, i guess they were just ignored. I removed them completely now, but the error is still there. And i'm sure not the only one.

@dolenec
Copy link

dolenec commented Sep 25, 2023

As I see you have multiple hosts defined..

probably different IP host, it should be different on same port.

Also hub1 is not defined.. hub1 should be name of wago_beneden and not hub1 if I am corect..

It is strange that not working only for you.. double check code and try to fix errors..

@HarrisonPace
Copy link
Contributor

HarrisonPace commented Sep 26, 2023

It is strange that not working only for you.. double check code and try to fix errors..

I'm still having issues since 2023.9.1+ , still isn't resolved in 2023.9.3:

#100421

@TonAlternantDePocket
Copy link

Running 2023.10 and still having issues

@home-assistant
Copy link

Hey there @janiversen, 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
Copy link
Member

please add the debug log and a short corresponding config, that shows the problem.

@janiversen
Copy link
Member

Anybody willing to share a debug log, with a small configuration, that shows the problem if not I will close this in a couple of days.

Saying "me too" does not help anyone, I think there are at least 3 issues not related to the title in the chat. Anyone having problems needs to:
a) reduce the configuration to a minimum, allowing us to debug easier (big configurations will simply not be looked at)
b) add a debug log a pr modbus documentation for the small configuration.
c) share the whole log, so we can see both the start and the problem.
Remark: as pointed out in the issue template, make sure you have removed all custom components, and run on the latest release.

The person who suggested not to upgrade pymodbus on minor versions, obviously should do his homework !! I happen to be maintainer here and of pymodbus.

@HarrisonPace
Copy link
Contributor

The person who suggested not to upgrade pymodbus on minor versions, obviously should do his homework !!

To be clear, several changes to the Modbus component have occurred in home assistant minor releases which had broken my configuration. This is where the frustration lied. I attempted to work with the maintainer, but the hostile demeanor made it difficult.

In my case (from a user's perspective), my device (custom device with Espressif ESP-Modbus library) was working in versions prior to 2023.9.0. My Siemens PLCs and various other hardware continue to work well in newer releases.

I appreciate @janiversen's contribution to Home Assistant Modbus Component & pymodbus regardless. But it was ultimately easier to replace the hardware, than attempt to resolve the issue given the circumstances.

@janiversen
Copy link
Member

Just to answer, of course there are changes in several minor releases, all bug fixes.

New features and incompatible changes are pr HA definition only in the monthly releases,

Of course a bug fix like any other change in the software can make it nessecary for a user to adapt the configuration and in some corner cases might make the software unsuited for a specific use.

I as maintainer look positive at every pull request issued, that helps the product, but of course I look to see what problems a PR can cause. That might have been what you see as negative.

@janiversen
Copy link
Member

I am still waiting for a debug log showing the original problem together with a reduced (as much as possible) configuration...without a debug log, there are no way for us to identify the issue.

If not provided I soon I will close this issue as solved.

@janiversen
Copy link
Member

Closing due to lack of activity.

@github-actions github-actions bot locked and limited conversation to collaborators Jan 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests