Unable to decode frame Modbus Error

Configuration
1

Yesterday 2 modbus based sensors went crazy, reporting surrealistically hight values of injected and purchased energy

image
image736×631 25.1 KB

In log I found the error reported at that exact moment.

2025-06-03 13:31:47.953 WARNING (MainThread) [pymodbus.logging] Unable to decode frame Modbus Error: [Input/Output] byte_count 4 > length of packet 1
2025-06-03 13:31:47.954 ERROR (MainThread) [homeassistant] Error doing job: Fatal error: protocol.data_received() call failed. (None)

Here is a definition of that sensor:

      - name: Wattsonic Total Energy injected to grid
        unique_id: wattsonic_total_energy_injected_to_grid
        slave: 247
        address: 31102
        scale: 0.1
        precision: 1
        input_type: holding
        unit_of_measurement: kWh
        state_class: total_increasing
        device_class: energy
        data_type: int32
        scan_interval: 600

Do we know how it is possible that it happened? Is it known modbus issue? Is it avoidable?
Is it something that can be set in modbus configuration/communication to prevent such issues?

HA core 2025.5.3

2

Your device screwed up and sent bad values, are you sure that address is an int32?

use min_value and max_value. That doesn’t look like a nan_value for int32, so I don’t think that will help.

3

Thanks for prompt reaction.

our device screwed up and sent bad values

Could be, it’s made in China… Or intermediate communication device screwed that (it’s hardwired to the inverter, then communicates via wifi with HA)

Your device screwed up and sent bad values, are you sure that address is an int32 ?

TBH I don’t know. I use modbus config for Wattsonic Gen3 prepared by someone else.

However, I would expect that an intercepted error results in recording no data, rather than damaged data. I saw this error several times before, but I never noticed that it caused data damage (since the inverter installation 9 months ago)

Granted, it’s possible that the HA recognized an error for some sensors and pick bad data for others at the same time. Unfortunately, the log provides no information about sensors or the Modbus address involved.

4

The error is telling you the value received is over 4 bytes, but you configured it for 4 bytes (int32). So your output comes from the configured 4 bytes. Regardless of that, the value would have been much larger but your configuration stopped that. So add a max_value to remove values larger than what you’d expect.

5

Documentation found on that page mentions 31102 address as U32 datatype, which I assume is an unsigned 4-bytes int. I have no access to official documentation, makingit it possible that something changed since then (there were fw updates)

Thanks for the suggestion. Worth thinking about that. Including the rest of 90 modbus sensors :wink:

6

In32 is signed fyi

7

Yeah… then it should be declared as uint32.
However I doubt it could be the reason. Negative value reported by the inverter (besides it’s not expected in this case) could lead to big numbers, but wouldn’t trigger the error, isn’t it?

8

No, it won’t trigger any errors because it’s just reading and applying the bytes. The bytes don’t actually hold a minus sign, the largest bit (0 or 1) is treated as positive or negative. So you’ll just get a different result

9

I’d suggest to get the modbus tester from this side (in case you have a windows machine at hand)

In case you’re unsure about things such as BE LE, byte-swapped, int, uint since you could try changes smoothly without modifiying YAML code to see the results.

Comes with a bunch of nice features such as live chart.

10

Can you point me to how should I use it to help with my situation, considering that what I exprienced happens very rarelly?
Also, can I connect this tool to the Inverter at the same time HA is connected?

In HA connection is defined as:

pkg_wattsonic:
  modbus:
    - name: wattsonic
      type: tcp
      host: 192.168.107.40
      port: 502
11

Ha… it seems it’s known modbus integration issue, manifesting when communication takes a bit longer. Then modbus reports random/erroneous values to sensors

While one of issues has been reported in Nov’24, other points to Feb’25 release providing graph with timing since when the issues have escalated.

Possible woraround is to extend timout settings

timeout: 9
message_wait_milliseconds: 200

But IMO the current behaviour which records invalid values due to timeout is critical one, although not picked by modbus devs till today.
One of reports is deep enough that proves that the assigned value comes from the other sensor (address). If true it’s really serious issue.

12

In case you read multiple addresses from the very same device, ever tried using
count: + data_type: custom + structure: “><python struct>” ?

It surely frees the modbus since splitting the bunch of received values is done at a later stage where modbus could idle again.

13

Not sure what do you mean and who this message is directed for.
But if you have knowledge maybe you are a proper person to help devs to resolve that.