Anyone else having MODBUS issues?

Configuration
1

Hey Guys, having a strange issue with MODBUS data points.

I have recently migrated a water management system across from Mango Automation, which I was happy with until they sold to another business who ended up not having as good support and the newer versions of the software were very buggy and unusable for my application. Anyways…

Most of the sensors in my setup use MODBUS over TCP. I have successfully got these to come in to HA without issue.
I have 2 tank sensors that are ultrasonic style and their data is available via RS485 MODBUS. I’ve got a pair of simple RTU’s at each of the tanks converting MODBUS TCP to Serial RS485 MODBUS. These work in the old system no worries, however when I try to retrieve data from them in HA, I get all kinds of timeout errors as you’ll see below…

I’m trying to work out the difference in the MODBUS config between tcp and rtuovertcp and which one I should be using for these 2 sensors, there isn’t much explanation of what the two config options do.

Here is some snippets of my config, some working screenshots of data coming back with a MODBUS test tool, and some error logs. I’m hoping someone is out there with some more MODBUS skills than myself and they can see the error of my ways…

  - name: "Solar Tank"
    type: tcp
    host: 10.42.0.13
    port: 502
    close_comm_on_error: true
    delay: 5
    timeout: 5
    retry_on_empty: true
    retries: 10
    sensors:
      - name: "Solar Tank Level Raw"
        address: 521
        input_type: holding
        #unit_of_measurement: in
        count: 1
        offset: 0
        data_type: uint16
        #scan_interval: 10
        scale: 0.003384

The log seems to have entries relating to timeouts, however there doesn’t seem to be any sort of network outages. The other entries relate to unexpected close of comms. Is it maybe timing out after 5 seconds due to my timeout setting? I wouldn’t think it would take more than a couple of ms to read a single holding register :confused:

2023-02-14 06:42:30.820 ERROR (SyncWorker_8) [homeassistant.components.modbus.modbus] Pymodbus: Top Tank: Modbus Error: [Connection] ModbusTcpClient(10.42.0.16:502): Connection unexpectedly closed 1.2159347534179688e-05 seconds into read of 8 bytes without response from unit before it closed connection


2023-02-14 06:42:31.082 ERROR (SyncWorker_3) [homeassistant.components.modbus.modbus] Pymodbus: Solar Tank: Exception Response(131, 3, GatewayNoResponse)

image

I am only reading the first value 0x0208 or 520 in decimal, although I have to add 1 because MODBUS

1 Like
2

image

3

Exception Response

Try decimal address with +1 or -1

My normal configs:

    delay: 1
    timeout: 3
    retries: 3
    retry_on_empty: true
    message_wait_milliseconds: 250
4

Hey, thanks for that. I’ll give that a go.

Cheers

5

Hmm, that didn’t seem to make much difference, it’s strange, because with a basic test tool app I can get the result back I want.
Anyone know what the difference between tcp and rtuovertcp is in the scheme of things?

Cheers

6

I can read a single register with a MODBUS poll application, every time I click read registers I get a new value, as soon as I try put the config back into HA, it just times out and doesn’t read it :frowning:

Screen Shot 2023-02-21 at 10.18.30 am
Screen Shot 2023-02-21 at 10.18.30 am1028×402 32.3 KB

Another snippet of the code, it just doesn’t seem to work, I tried a few variations of timing options etc.

  - name: "Solar Tank"
    type: tcp
    host: 10.42.0.13
    port: 502
    close_comm_on_error: true
    delay: 1
    timeout: 3
    retry_on_empty: true
    retries: 3
    sensors:
      - name: "Solar Tank Level Raw"
        address: 520
        input_type: holding
        #unit_of_measurement: in
        count: 1
        offset: 0
        data_type: uint16
        #scan_interval: 10
        scale: 0.003384

And the log entry that comes up …


2023-02-21 10:21:54.762 ERROR (SyncWorker_4) [homeassistant.components.modbus.modbus] Pymodbus: Solar Tank: Modbus Error: [Connection] Failed to connect[ModbusTcpClient(10.42.0.13:502)]
2023-02-21 10:22:08.773 ERROR (SyncWorker_6) [pymodbus.client.tcp] Connection to (10.42.0.13, 502) failed: [Errno 111] Connection refused
2023-02-21 10:22:23.769 ERROR (SyncWorker_6) [pymodbus.client.tcp] Connection to (10.42.0.13, 502) failed: [Errno 111] Connection refused

Other MODBUS clients work fine, it’s weird.
The only difference between these sensors and the ones that are working is there is a MODBUS TCP to RS485 converter in there. The others are just MODBUS TCP RTU’s with direct analog inputs or digital inputs.

Cheers
Dan

7

:frowning:

BUMP?

Anyone else using MODBUS out there successfully or otherwise?

8

I’m using Modbus over TCP for a while now. Until recently without much issues. But since about 2 month I get frequent timeouts and I can’t figure out what’s wrong. Unfortunataly both units (HA and Victron device) got updates in the meantime, so it would be difficult to reestablish a previous working state.

Logger: pymodbus.logging
Source: components/modbus/modbus.py:398
First occurred: 11:50:40 (441 occurrences)
Last logged: 15:41:39
Connection to (192.168.1.7, 502) failed: timed out

Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:403
Integration: Modbus (documentation, issues)
First occurred: 11:50:37 (325 occurrences)
Last logged: 15:41:36

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

9

Maybe related to this: Modbus RTU does not seem to retry - Pymodbus: hub1: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 4 bytes (0 received) · Issue #88800 · home-assistant/core · GitHub

10

same problems here, until this release I’ve had no issues even tho the log spammed errors even now and then, but this time the modbus stops receiving. Weird thing is that I have 2 identical modbus gat3eways and only one of them is stopping communication:

 Modbus Error: [Invalid Message] No response received, expected at least 4 bytes

I can get past this by setting close_comm_on_error: false BUT when I do the modbus gets hickups in the sensors for some reason… giving me very weird values

1 Like
11

Tried a full OS restart?

I had similar issues after the update, but it disappeared after a full restart :thinking:

12

this is my charging modbus-sensor after the latest upgrade. Something has happened…

image

notice the few previous drops that did correct themselves compared to the weird graph afterwards

13

I’ll give it a go

14

I think it’s still the same… the log keeps spitting out this, Im guessing that the split sensor is the new problem after the update, the other error I had before and didnt do anythiong to the values except restarting communication I guess

image
image1226×154 16.5 KB

15

There was a change in modbus implementation in 2023.8.3. See here: https://github.com/home-assistant/core/issues/98692

16

yes but judging by the discussion that should have been solved by now, the fix was in 2023.8.4. I guess I need help with the config firstly, do we have any modbus gurus here? :slight_smile:

For further investigation:

image
image1223×229 51.3 KB 

Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:401
Integration: Modbus (documentation, issues)
First occurred: 09:01:11 (176 occurrences)
Last logged: 09:27:51

Pymodbus: modbus_tcp: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 4 bytes (0 received)
Pymodbus: modbus_tcp: Modbus Error: [Input/Output] No Response received from the remote slave/Unable to decode response
Pymodbus: modbus_tcp: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] Incomplete message received, expected at least 4 bytes (1 received)

here is my config, I guess it’s messed up somewhere

modbus:


#    SRNE HYBRID - 1600W
#############################################
    
  - type: rtuovertcp
    host: 192.168.1.30
    port: 8888
    name: modbus_tcp
    close_comm_on_error: false
#    message_wait_milliseconds: 30
#    retries: 3
#    retry_on_empty: false
#    timeout: 5
    
    sensors:
      - name: "Main Battery"
        address: 256
        slave: 1
        count: 3
        scan_interval: 10
        data_type: custom
        structure: ">3H"
      - name: "Main Panel"
        address: 263
        slave: 1
        count: 3
        scan_interval: 11
        data_type: custom
        structure: ">3H"
      - name: "Main Usage"
        address: 61487
        slave: 1
        count: 2
        scan_interval: 12
        data_type: custom
        structure: ">2H"
      - name: "Main Info"
        address: 540
        slave: 1
        count: 10
        scan_interval: 63
        data_type: custom
        structure: ">10h"
    
#Load active power phase A
      - name: Modbus_Inverter_Power
        unique_id: Modbus_Inverter_Power
        scan_interval: 11
        unit_of_measurement: W
        scale: 1
        slave: 1
        address: 539
        input_type: holding

#Battery current
      - name: Modbus_Inverter_BatteryA
        unique_id: Modbus_Inverter_BatteryA
        scan_interval: 13
        unit_of_measurement: A
        scale: 0.1
        precision: 1
        slave: 1
        address: 258
        input_type: holding

#Total charge power, include charge power by mains and pv
      - name: Modbus_Inverter_Charge_power
        unique_id: Modbus_Inverter_Charge_power
        scan_interval: 94
        unit_of_measurement: W
        scale: 1
        slave: 1
        address: 270
        input_type: holding
        
#Charge state
      - name: Modbus_Inverter_battery_chargestate
        unique_id: Modbus_Inverter_battery_chargestate
        scan_interval: 95
        unit_of_measurement: state
        scale: 1
        slave: 1
        address: 267
        input_type: holding

#Current state of the machine
      - name: Modbus_Inverter_Operation
        unique_id: Modbus_Inverter_Operation
        scan_interval: 90
        scale: 1
        slave: 1
        address: 528
        input_type: holding

#Battery side current by PV charging
      - name: Modbus_Inverter_PV_charge_current
        unique_id: Modbus_Inverter_PV_charge_current
        scan_interval: 93
        unit_of_measurement: A
        scale: 0.1
        precision: 1
        slave: 1
        address: 548
        input_type: holding
        
        
#
#   RÄKNARE       
##############################

#Accumulated PV power generation
      - name: Modbus_Inverter_PV_Generated
        unique_id: Modbus_Inverter_PV_Generated
        scan_interval: 240
        unit_of_measurement: kWh
        state_class: total_increasing
        device_class: energy
        scale: 0.1
        precision: 1
        slave: 1
        address: 61496
        input_type: holding
        
#Accumulated battery charge AH
      - name: Modbus_Inverter_battery_charge
        unique_id: Modbus_Inverter_battery_charge
        scan_interval: 245
        unit_of_measurement: ah
        state_class: total_increasing
        device_class: power
        scale: 1
        precision: 1
        slave: 1
        address: 61492
        input_type: holding
        
#Accumulated battery discharge AH
      - name: Modbus_Inverter_battery_discharge
        unique_id: Modbus_Inverter_battery_discharge
        scan_interval: 260
        unit_of_measurement: ah
        state_class: total_increasing
        device_class: power
        scale: 1
        precision: 1
        slave: 1
        address: 61494
        input_type: holding
        
        
#Power consumption by load from mains of today
      - name: Modbus_Inverter_Main_load_power_daily
        unique_id: Modbus_Inverter_Main_load_power_daily
        scan_interval: 280
        unit_of_measurement: kWh
        scale: 0.1
        precision: 1
        slave: 1
        address: 61501
        input_type: holding

#Output Priority
      - name: Modbus_Inverter_output_priority
        unique_id: Modbus_Inverter_output_priority
        scan_interval: 34
        scale: 1
        slave: 1
        address: 57860
        input_type: holding 
        
#Charge Priority
      - name: Modbus_Inverter_charge_priority
        unique_id: Modbus_Inverter_charge_priority
        scan_interval: 35
        scale: 1
        slave: 1
        address: 57871
        input_type: holding  
     
#Mains Charge Limit
      - name: Modbus_Inverter_mains_charge_limit
        unique_id: Modbus_Inverter_mains_charge_limit
        scan_interval: 30
        unit_of_measurement: 'A'
        scale: 0.1
        slave: 1
        address: 57861
        input_type: holding

for reference:

Modbus addresses for inverter

17

I’m also running into the issue where Modbus TCP has timed out, but this only happened after we did a massive upgrade of Home Assistant.
We were previously running on OS 8.4. We have upgraded to OS 10.5.
Since that time it will occasionally have this error:

2023-09-12 01:41:46.368 ERROR (SyncWorker_13) [pymodbus.logging] Connection to (10.0.20.33, 502) failed: timed out
2023-09-12 01:41:51.377 ERROR (SyncWorker_13) [pymodbus.logging] Connection to (10.0.20.33, 502) failed: timed out
2023-09-12 01:41:51.380 ERROR (SyncWorker_13) [homeassistant.components.modbus.modbus] Pymodbus: ca_dpf02_daq: Modbus Error: [Connection] ModbusTcpClient(10.0.20.33:502)

After that error Home Assistant stops collecting data from the node.
We’ve also noticed that in the Overview screen the sensor says it’s Unavailable.

Has anyone encountered this issue or know what to do about it?

18

I’ve always had the unavailable state on every modbus sensor about 100 times a day. I’ve solved it with a template that discards those values so that was never a problem. Now however the modbus integration stops communicating completely after an error wich is a new “feature” as I understand it… I’ve reverted back to version 2023.8.4 to solve this, there it is working as before.

19

I encountered exactly this issue after upgrading to HA Core 2023.9.
The sensor with Modbus TCP Data stops geting data and shows “unavailable” state.
After reverting back to 2023.8.1 everything works as expected.
I hope there is a possibility to fix this issue.

20

Ug that’s really frustrating. Does anyone have an idea about where the code might be where this happens so we can file it as a bug in github?