Cancel send, because not connected!

[FrankTub]

Describe the bug

Not really sure if this is really a bug but I keep seeing the following a lot lately in my logging:

Cancel send, because not connected! >>>>> send: 0x6 0xd 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x85 0x0 0x28 >>>>> recv: 0x6 0xd 0x0 0x0 0x0 0x53 0x1 0x3 0x50 0x0 0x67 0x0 0x32 0x2 0xbb 0x0 0xea 0x0 0xe8 0x0 0xe8 0xff 0xfe 0xf 0xdd 0xf 0xe1 0xf 0xf0 0x9 0x2e 0x9 0x2b 0x9 0x2f 0xff 0xff 0x3f 0xd1 0xff 0xff 0x13 0x89 0xff 0xfe 0x40 0x3e 0xff 0xff 0xb6 0xe 0xff 0xfe 0xd9 0x33 0xff 0xfe 0x0 0x88 0xaf 0x10 0x0 0x0 0x56 0x61 0xff 0xfc 0x1d 0x4c 0xff 0xff 0x40 0xc9 0xff 0xff 0x80 0x0 0xf 0x1a 0x80 0x0 0x80 0x0 0xff 0xfe 0x0 0x4 0x0 0x0 extra data: >>>>> send: 0x6 0xe 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xb1 0x0 0x2 >>>>> recv: 0x6 0xe 0x0 0x0 0x0 0x7 0x1 0x3 0x4 0x0 0x0 0x0 0x0 extra data: >>>>> send: 0x6 0xf 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8 >>>>> recv: 0x6 0xf 0x0 0x0 0x0 0x13 0x1 0x3 0x10 0x30 0x30 0x30 0x34 0x2e 0x30 0x30 0x32 0x31 0x2e 0x30 0x30 0x32 0x33 0x0 0x0 extra data: >>>>> send: 0x6 0x10 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x85 0x0 0x28 >>>>> recv: 0x6 0x10 0x0 0x0 0x0 0x53 0x1 0x3 0x50 0x0 0x67 0x0 0x32 0x2 0xb8 0x0 0xe7 0x0 0xe7 0x0 0xe8 0xff 0xfe 0xf 0xde 0xf 0xe3 0xf 0xf2 0x9 0x2c 0x9 0x2d 0x9 0x30 0xff 0xff 0x3f 0x8d 0xff 0xff 0x13 0x88 0xff 0xfe 0x3f 0xf5 0xff 0xff 0xb7 0xcc 0xff 0xfe 0xd9 0x31 0xff 0xfe 0x0 0x88 0xaf 0x12 0x0 0x0 0x56 0x8 0xff 0xfc 0x1d 0x4b 0xff 0xff 0x40 0x84 0xff 0xff 0x80 0x0 0xf 0x1a 0x80 0x0 0x80 0x0 0xff 0xfe 0x0 0x4 0x0 0x0 extra data: >>>>> send: 0x6 0x11 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xb1 0x0 0x2 >>>>> recv: 0x6 0x11 0x0 0x0 0x0 0x7 0x1 0x3 0x4 0x0 0x0 0x0 0x0 extra data: >>>>> send: 0x6 0x12 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8 >>>>> recv: 0x6 0x12 0x0 0x0 0x0 0x13 0x1 0x3 0x10 0x30 0x30 0x30 0x34 0x2e 0x30 0x30 0x32 0x31 0x2e 0x30 0x30 0x32 0x33 0x0 0x0 extra data: >>>>> send: 0x6 0x13 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x85 0x0 0x28 >>>>> recv: 0x6 0x13 0x0 0x0 0x0 0x53 0x1 0x3 0x50 0x0 0x67 0x0 0x32 0x2 0xb0 0x0 0xe6 0x0 0xe4 0x0 0xe5 0xff 0xfe 0xf 0xdd 0xf 0xde 0xf 0xef 0x9 0x2e 0x9 0x2c 0x9 0x2e 0xff 0xff 0x3e 0xba 0xff 0xff 0x13 0x87 0xff 0xfe 0x3f 0x24 0xff 0xff 0xb7 0xc5 0xff 0xfe 0xd9 0x32 0xff 0xfe 0x0 0x88 0xaf 0x14 0x0 0x0 0x54 0xe5 0xff 0xfc 0x1d 0x4d 0xff 0xff 0x3f 0xae 0xff 0xff 0x80 0x0 0xf 0x1a 0x80 0x0 0x80 0x0 0xff 0xfe 0x0 0x4 0x0 0x0 extra data: >>>>> send: 0x6 0x14 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xb1 0x0 0x2 >>>>> recv: 0x6 0x14 0x0 0x0 0x0 0x7 0x1 0x3 0x4 0x0 0x0 0x0 0x0 extra data: >>>>> send: 0x6 0x15 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8 >>>>> Repeating.... >>>>> send: 0x6 0x15 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8 >>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8
Cancel send, because not connected!

My polling frequency is 5 seconds, perhaps it is related?

Expected behavior

Stable connection with my inverter

Screenshots

No response

Diagnostic File

config_entry-solaredge_modbus_multi-01JKKFW47NRP3Z8ZB2E9GDVH2B.json

Debug logs

Home Assistant Version

2025.9.4

solaredge-modbus-multi Version

3.1.7

Installation Type

HAOS

Read the Instructions

• My configuration follows https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Configuration
• I have read the Known Issues https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Known-Issues
• This issue is not about a template error (do not report template errors, read https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Template-Design-Notes)

Additional Context

No response

[FrankTub]

More often than not the error in the logs looks like ERROR: request ask for transaction_id=1 but got id=709 .., full log:

ERROR: request ask for transaction_id=1 but got id=709, Skipping. >>>>> recv: 0x2 0xbd 0x0 0x0 0x0 0x53 0x1 0x3 0x50 0x0 0x67 0x0 0x32 0x6 0x7e 0x2 0x2a 0x2 0x29 0x2 0x2a 0xff 0xfe 0x10 0x13 0x10 0x18 0x10 0x24 0x9 0x4a 0x9 0x4f 0x9 0x4a 0xff 0xff 0xf 0x6f 0x0 0x0 0x13 0x86 0xff 0xfe 0xf 0x74 0x0 0x0 0xac 0xbe 0xff 0xfe 0xd8 0xff 0xff 0xfe 0x0 0x88 0xe5 0xa2 0x0 0x0 0x14 0xe4 0xff 0xfd 0x1d 0x4c 0xff 0xff 0xf 0xab 0x0 0x0 0x80 0x0 0x11 0x84 0x80 0x0 0x80 0x0 0xff 0xfe 0x0 0x4 0x0 0x0 extra data: >>>>> send: 0x2 0xbe 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xb1 0x0 0x2 >>>>> recv: 0x2 0xbe 0x0 0x0 0x0 0x7 0x1 0x3 0x4 0x0 0x0 0x0 0x0 extra data: >>>>> send: 0x2 0xbf 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8 >>>>> recv: 0x2 0xbf 0x0 0x0 0x0 0x13 0x1 0x3 0x10 0x30 0x30 0x30 0x34 0x2e 0x30 0x30 0x32 0x31 0x2e 0x30 0x30 0x32 0x33 0x0 0x0 extra data: >>>>> send: 0x2 0xc0 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x85 0x0 0x28 >>>>> recv: 0x2 0xc0 0x0 0x0 0x0 0x53 0x1 0x3 0x50 0x0 0x67 0x0 0x32 0x6 0x80 0x2 0x2d 0x2 0x29 0x2 0x2a 0xff 0xfe 0x10 0x16 0x10 0x17 0x10 0x26 0x9 0x4a 0x9 0x4f 0x9 0x4e 0xff 0xff 0xf 0x73 0x0 0x0 0x13 0x86 0xff 0xfe 0xf 0x79 0x0 0x0 0xac 0x99 0xff 0xfe 0xd8 0xff 0xff 0xfe 0x0 0x88 0xe5 0xa7 0x0 0x0 0x14 0xeb 0xff 0xfd 0x1d 0x4b 0xff 0xff 0xf 0xb0 0x0 0x0 0x80 0x0 0x11 0x84 0x80 0x0 0x80 0x0 0xff 0xfe 0x0 0x4 0x0 0x0 extra data: >>>>> send: 0x2 0xc1 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xb1 0x0 0x2 >>>>> recv: 0x2 0xc1 0x0 0x0 0x0 0x7 0x1 0x3 0x4 0x0 0x0 0x0 0x0 extra data: >>>>> send: 0x2 0xc2 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8 >>>>> recv: 0x2 0xc2 0x0 0x0 0x0 0x13 0x1 0x3 0x10 0x30 0x30 0x30 0x34 0x2e 0x30 0x30 0x32 0x31 0x2e 0x30 0x30 0x32 0x33 0x0 0x0 extra data: >>>>> send: 0x2 0xc3 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x85 0x0 0x28 >>>>> recv: 0x2 0xc3 0x0 0x0 0x0 0x53 0x1 0x3 0x50 0x0 0x67 0x0 0x32 0x6 0x85 0x2 0x2d 0x2 0x2b 0x2 0x2b 0xff 0xfe 0x10 0x16 0x10 0x15 0x10 0x25 0x9 0x4d 0x9 0x4d 0x9 0x4d 0xff 0xff 0xf 0x7b 0x0 0x0 0x13 0x86 0xff 0xfe 0xf 0x81 0x0 0x0 0xab 0x85 0xff 0xfe 0xd8 0xff 0xff 0xfe 0x0 0x88 0xe5 0xad 0x0 0x0 0x14 0xf6 0xff 0xfd 0x1d 0x4a 0xff 0xff 0xf 0xb8 0x0 0x0 0x80 0x0 0x11 0x84 0x80 0x0 0x80 0x0 0xff 0xfe 0x0 0x4 0x0 0x0 extra data: >>>>> send: 0x2 0xc4 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xb1 0x0 0x2 >>>>> recv: 0x2 0xc4 0x0 0x0 0x0 0x7 0x1 0x3 0x4 0x0 0x0 0x0 0x0 extra data: >>>>> send: 0x2 0xc5 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8 >>>>> Repeating.... >>>>> send: 0x2 0xc5 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8 >>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8 >>>>> recv: 0x2 0xc5 0x0 0x0 0x0 0x13 0x1 0x3 0x10 0x30 0x30 0x30 0x34 0x2e 0x30 0x30 0x32 0x31 0x2e 0x30 0x30 0x32 0x33 0x0 0x0 extra data:
ERROR: request ask for transaction_id=1 but got id=709, Skipping. >>>>> recv: 0x2 0xc5 0x0 0x0 0x0 0x13 0x1 0x3 0x10 0x30 0x30 0x30 0x34 0x2e 0x30 0x30 0x32 0x31 0x2e 0x30 0x30 0x32 0x33 0x0 0x0 extra data:

[0BanZai0]

Same here. I've seen a big gap in solar data for the first time today and went to investigate the issue.
That's what I found in the logs:

2025-09-23 06:55:17.279 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.2.12', 502)
2025-09-23 06:55:18.185 WARNING (MainThread) [pymodbus.logging] Repeating....
2025-09-23 06:55:20.688 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.2.12', 502)
2025-09-23 06:55:30.990 WARNING (MainThread) [pymodbus.logging] Failed to connect 
2025-09-23 06:55:52.695 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.2.12', 502)
2025-09-23 06:55:52.796 ERROR (MainThread) [custom_components.solaredge_modbus_multi] Error fetching SolarEdge Coordinator data: Modbus/TCP connect to 192.168.2.12:502 failed.
2025-09-23 06:55:57.279 WARNING (MainThread) [pymodbus.logging] Repeating....
2025-09-23 06:55:58.184 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.2.12', 502)
2025-09-23 06:56:00.687 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.2.12', 502)
2025-09-23 06:56:07.991 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.2.12', 502)
2025-09-23 07:00:37.876 ERROR (MainThread) [pymodbus.logging] ERROR: request ask for transaction_id=1 but got id=12431, Skipping.
>>>>> recv: 0x0 0x1 0x0 0x0 0x0 0x13 0x1 0x3 0x10 0x30 0x30 0x30 0x34 0x2e 0x30 0x30 0x32 0x32 0x2e 0x30 0x30 0x34 0x34 0x0 0x0 extra data: 
>>>>> send: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x85 0x0 0x28
>>>>> recv: 0x0 0x2 0x0 0x0 0x0 0x53 0x1 0x3 0x50 0x0 0x67 0x0 

... it goes on like this for some lines ...

Now it's logging fine as nothing happened.
I have no clue where to look at.
My Home Assistant had no other logs at this time that would lead me to connection issues.

Maybe it is related to my update from 8.1 to 9.4 from two days ago. That's where I first see this happening in my logs!

[haferm]

i am also seeing "Failed to connect" coming from the blue since upgrade to 9.4. Never had before.

2025-09-23 07:05:21.784 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.99.201', 1502)
2025-09-23 07:05:22.686 WARNING (MainThread) [pymodbus.logging] Repeating....
2025-09-23 07:05:25.189 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.99.201', 1502)
2025-09-23 07:05:32.492 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.99.201', 1502)

..

2025-09-23 21:06:38.777 WARNING (MainThread) [pymodbus.logging] Failed to connect 
2025-09-23 21:06:39.681 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.99.201', 1502)
2025-09-23 21:06:42.184 WARNING (MainThread) [pymodbus.logging] Repeating....
2025-09-23 21:06:49.488 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.99.201', 1502)

[WillCodeForCats]

I haven't had this problem personally with modbus, but I have had some add-ons stop communicating and require rebooting my HAOS host with HA 2025.9.x and HAOS 16.2 to restore network.

[0BanZai0]

Some minutes ago I'm getting these errors again. Resulting in huge gaps of my electricity data from the inverter :(

Not all signals are gone.
Some of my calculated ones become null.

[haferm]

in addition to the "Failed to connect [Errno 111] Connect call failed" reported yesterday getting now also ERROR: request ask for transaction_id=2 but got id=1, Skipping.
I have the strong feeling this comes in with one of the latest HA Updates 2025.9.x as i have never seen this before. Also from Release Notes i see a lot of updates for modbus in HA 2025.9.2.
@WillCodeForCats rebootet my Host already also check everthing else, reenabled Modbus on Inverter.

2025-09-25 06:26:31.823 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.99.201', 1502)
2025-09-25 06:26:32.729 WARNING (MainThread) [pymodbus.logging] Repeating....
2025-09-25 06:26:38.799 ERROR (MainThread) [pymodbus.logging] ERROR: request ask for transaction_id=2 but got id=1, Skipping.
>>>>> recv: 0x0 0x3 0x0 0x0 0x0 0x7 0x1 0x3 0x4 0x0 0x0 0x0 0x0 extra data: 
>>>>> send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xfc 0x0 0x6b
>>>>> recv: 0x0 0x4 0x0 0x0 0x0 0xd9 0x1 0x3 0xd6 0x0 0xcb 0x0 0x69 0xb 0xf8 0x6 0xa0 0x2 0xcf 0x2 0x87 0xff 0xfd 0x9 0x1b 0x9 0x1b 0x9 0x15 0x9 0x1f 0x0 0x0 0xf 0xbb 0xf 0xc2 0xf 0xd1 0xff 0xff 0x13 0x85 0xff 0xfe 0xf0 0x9f 0xf4 0x8e 0xfe 0x76 0xfd 0x9b 0xff 0xff 0x16 0x3e 0xd 0xed 0x4 0xd3 0x4 0x49 0xff 0xff 0xef 0xef 0xf8 0x11 0xfb 0x6d 0xfc 0x72 0xff 0xff 0x11 0x26 0x1b 0x6c 0x8 0xfc 0xf 0x9 0xff 0xfe 0x50 0x7b 0x93 0xa0 0x1e 0x6b 0x9b 0x13 0x1c 0x54 0x34 0xd1 0x1f 0x80 0xd1 0xfe 0x3 0x69 0x89 0x0 0x8 0xd8 0xf5 0x1a 0x2 0xb2 0x89 0x9a 0x1 0xa3 0x17 0x1f 0xff 0xfd 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x80 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x80 0x0 0x0 0x0 0x0 0x0 extra data: 
>>>>> send: 0x0 0x5 0x0 0x0 0x0 0x6 0x1 0x3 0xe1 0x44 0x0 0x56
>>>>> recv: 0x0 0x5 0x0 0x0 0x0 0xaf 0x1 0x3 0xac 0x40 0x0 0x45 0x9c 0x40 0x0 0x45 0x9c 0x40 0x0 0x45 0x9c 0x40 0x0 0x45 0x9c 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x41 0xa4 0x0 0x0 0x0 0x0 0x7b 0xa7 0x44 0x42 0x0 0x0 0x80 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x90 0x0 0x46 0x17 0xe5 0x60 0x46 0x14 0x0 0x0 0x42 0xc6 0x31 0x6 0x41 0x19 0x0 0x6 0x0 0x0 0x0 0x3 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 extra data: 
>>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8
>>>>> recv: 0x0 0x1 0x0 0x0 0x0 0x13 0x1 0x3 0x10 0x30 0x30 0x30 0x34 0x2e 0x30 0x30 0x32 0x33 0x2e 0x30 0x30 0x33 0x36 0x0 0x0 extra data: 
>>>>> send: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x85 0x0 0x28
>>>>> recv: 0x0 0x2 0x0 0x0 0x0 0x53 0x1 0x3 0x50 0x0 0x67 0x0 0x32 0x0 0x6f 0x0 0x24 0x0 0x25 0x0 0x26 0xff 0xfe 0xf 0xc0 0xf 0xca 0xf 0xd6 0x9 0x1d 0x9 0x1b 0x9 0x22 0xff 0xff 0xdd 0x70 0xff 0xfe 0x13 0x86 0xff 0xfe 0x65 0xae 0xff 0xfe 0xa0 0x60 0xff 0xfe 0xd 0x39 0xff 0xfe 0x0 0x1c 0x97 0xd3 0x0 0x0 0xd2 0xe3 0xff 0xfb 0x1e 0x62 0xff 0xff 0xdc 0xe9 0xff 0xfe 0x80 0x0 0xf 0xd3 0x80 0x0 0x80 0x0 0xff 0xfe 0x0 0x5 0x0 0x0 extra data: 
>>>>> send: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xb1 0x0 0x2

....

[WillCodeForCats]

I've verified that the pymodbus.logging message No response received after 3 retries are handled correctly, unfortunately they are log clutter because the pymodbus uses error log level which Home Assistant displays unnecessarily. All of the send/recv stuff should probably be debug, but it's not the integration logging those messages.

If you turn on debug logging in Home Assistant you will capture something like this (trimmed for less clutter):

2025-09-26 08:53:20.676 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: AC_Energy_WH 0x3a323f0 <class 'int'>
2025-09-26 08:53:20.676 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: I_Grid_Status 0x0 <class 'int'>
2025-09-26 08:53:20.676 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I2: modbus_read_holding_registers address=40044 count=8
2025-09-26 08:53:32.681 ERROR (MainThread) [pymodbus.logging] No response received after 3 retries, continue with next request
>>>>> send: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xb1 0x0 0x2
>>>>> recv: 0x0 0x3 0x0 0x0 0x0 0x7 0x1 0x3 0x4 0x0 0x0 0x0 0x0 extra data: 
>>>>> send: 0x0 0x4 0x0 0x0 0x0 0x6 0x2 0x3 0x9c 0x6c 0x0 0x8
>>>>> recv: X extra data: 
>>>>> send: 0x0 0x5 0x0 0x0 0x0 0x6 0x2 0x3 0x9c 0x85 0x0 0x28
>>>>> recv: X extra data: 
>>>>> send: 0x0 0x6 0x0 0x0 0x0 0x6 0x2 0x3 0x9c 0xb1 0x0 0x2
>>>>> recv: 0x0 0x6 0x0 0x0 0x0 0x7 0x2 0x3 0x4 0x0 0x0 0x0 0x0 extra data: 
>>>>> send: 0x0 0x7 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xfc 0x0 0x6b
>>>>> recv: X extra data: 
>>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x6c 0x0 0x8
>>>>> recv: X extra data: 
>>>>> send: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0x85 0x0 0x28
>>>>> recv: X extra data: 
>>>>> send: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x3 0x9c 0xb1 0x0 0x2
>>>>> recv: 0x0 0x3 0x0 0x0 0x0 0x7 0x1 0x3 0x4 0x0 0x0 0x0 0x0 extra data: 
>>>>> send: 0x0 0x4 0x0 0x0 0x0 0x6 0x2 0x3 0x9c 0x6c 0x0 0x8
>>>>> Repeating....
>>>>> send: 0x0 0x4 0x0 0x0 0x0 0x6 0x2 0x3 0x9c 0x6c 0x0 0x8
>>>>> send: 0x0 0x4 0x0 0x0 0x0 0x6 0x2 0x3 0x9c 0x6c 0x0 0x8
2025-09-26 08:53:32.681 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Disconnecting from 10.0.0.16:1502 (clear_client=False).
2025-09-26 08:53:32.681 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Failed data refresh attempt 1
2025-09-26 08:53:32.681 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Waiting 800 ms before data refresh attempt 2
2025-09-26 08:53:33.482 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Connecting to 10.0.0.16:1502 ...
2025-09-26 08:53:33.585 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 54.0
2025-09-26 08:53:33.585 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: modbus_read_holding_registers address=40044 count=8
2025-09-26 08:53:33.614 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: result is error: False 

The pymodbus.logging error is handled at Failed data refresh attempt 1 and the integration runs its disconnect, wait, and reconnect logic where it's successful at attempt 2.

[haferm]

Hi @WillCodeForCats thanks for your update, really appriciated. As i am on docker i went back to HA 2025.9.1 yesterday, saw same messages. Down to 2025.8.3 today with your latest version (3.1.7) of solaredge-modbus-multi. Until now i am NOT seeing that kind of events. So if i understand you correctly from your last update more or less everything is fine and the message we are seeing are because wrong type of level (error/debug) is used by pymodbus.logging in 2025.9.x correct?

[0BanZai0]

I'd be really happy to know how I can mitigate this problem. Today the lost connection caused my previously set fixed discharge limit of "0" to be reset back to 5000 W. This unfortunately caused my home battery to charge my car and is now empty :)
@WillCodeForCats do you have any idea what the issue might be?

[WillCodeForCats]

There are some advanced YAML config options you can use to change the retry timing:

https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Configuration#advanced-configuration-with-yaml

But if the inverter is requiring a power cycle before it will accept TCP connections again this probably won't help.

[0BanZai0]

Sorry, seems to be the inverters fault in this case.

I dug a little deeper in the inverter logs. Seems to be another problem here that causes the issue I've seen!

That's in my log right when the reset of my settings happened:

Fehler 1Dx88: Heartbeat abgelaufen

So it might have been a coincidence.

The connection in HA usually n comes back after a while, I don't need a power cycle.

[WillCodeForCats]

You can try making the retry limit longer:

solaredge_modbus_multi:
  retry:
    limit: 7

Losing the connection won't change settings though, the integration always reads the current value. So if the inverter is resetting values you would need an automation that can see it changed and try to reset it to the value you need.

There is a commit command too (button.solaredge_i1_commit_power_settings), but I don't know if that will keep the discharge limit setting across inverter resets. My inverters don't support commands and I don't have batteries so I can't try it personally.