prj
February 10, 2025, 1:52am
1
When did they do large breaking changes to modbus?
2025.2.1 definitely does not work. “Upgraded” from 2023.3 and modbus is dead on this version. Works for 1-2 hours, after that get spam of the following messages in log:
Feb 08 20:12:22 ubuntu-phablet hass[18271]: 2025-02-08 20:12:22.591 ERROR (MainThread) [pymodbus.logging] Exception response 131 / 0
Feb 08 20:12:22 ubuntu-phablet hass[18271]: 2025-02-08 20:12:22.594 ERROR (MainThread) [pymodbus.logging] Exception response 131 / 0
Feb 08 20:12:22 ubuntu-phablet hass[18271]: 2025-02-08 20:12:22.597 ERROR (MainThread) [pymodbus.logging] Exception response 131 / 0
Feb 08 20:12:22 ubuntu-phablet hass[18271]: 2025-02-08 20:12:22.604 ERROR (MainThread) [pymodbus.logging] Exception response 131 / 0
Feb 08 20:12:22 ubuntu-phablet hass[18271]: 2025-02-08 20:12:22.607 ERROR (MainThread) [pymodbus.logging] Exception response 131 / 0
Feb 08 20:12:22 ubuntu-phablet hass[18271]: 2025-02-08 20:12:22.609 ERROR (MainThread) [pymodbus.logging] Exception response 131 / 0
Feb 08 20:12:22 ubuntu-phablet hass[18271]: 2025-02-08 20:12:22.612 ERROR (MainThread) [pymodbus.logging] Exception response 131 / 0
And of course all the modbus entities go to “unknown”. Real fun.
Restart, and everything okay again for 2 hours or so. Then just blows up again.
While I could schedule a restart job for HA to restart every couple hours, I’d rather find a version that works. I used this software to automate a bunch of my climate controls at home, and I don’t want to move it anywhere.
I use a venv, so no issues with any auto upgrade shenanigans - can deploy any version.
Do I just go back to 2023.3 or is there something newer where they didn’t blow up modbus support?
pcwii
(Pcwii)
February 10, 2025, 2:36am
2
Looks like modus is still supported. When was it working for you? When did it break?
Well you cant expect two years of updates to be not breaking anything. You should revisit the modbus integration page and check if your code is still syntactically correct or you can use the modbus proxy addon.
2 Likes
prj
February 10, 2025, 10:11am
5
There is absolutely nothing wrong with my configuration.
I checked the logs and it’s about 3-4 hours that something happens to the modbus component and it crashes so that it only gives “Exception response 131 / 0” to every query.
A problem with the configuration will not make it work fine for 3-4 hours and then die, and a restart would not fix it every time in that case.
Only thing that changed was that slave is now default 1 instead of 0, and I updated that, but no difference.
And hey, I do expect every update to break everything! That’s why I am running a VENV. Because even if you do not update in docker, they push you random updates from their server to the supervisor, that you can not opt out of, which is not only a huge security risk, but it also eventually bricks your install completely.
But the fact that you should expect the very core components (modbus is one) to break every time you update says quite a bit about this project.
Oh btw, tell all those people here:
opened 02:50PM - 09 Feb 25 UTC
integration: modbus
### The problem
Hello,
I updated my HA last week (from 2025.1.x to 2025.2.1) an… d since then I have issue with my Modbus sensor which record erroneous spikes.
It matches the update of the pyModbus library as well.
It used to work flawlessly but now I have regular issues.
What I noticed is that I am getting erroneous value, for example room temperature jumping multiple degrees or flowsensor jumping from 0 to a value for just 1 frame.
It looks like this value is the answer from another request.
**This only happens when the Modbus telegram is sent again after 3sec (probably due to timeout).**
Is there a way to avoid sending this new telegram after timeout ? (I am polling values each 10s anyway)
Before / after HA update:
<img width="948" alt="Image" src="https://github.com/user-attachments/assets/f2958fc5-189e-4ebd-a34d-0a34fab6bf04" />
Errors over 2h:
<img width="948" alt="Image" src="https://github.com/user-attachments/assets/82f9eb8a-97de-4d35-b475-5ddbebb30008" />
Now the interesting part: this spikes are only generated when the request is repeated.
Here are 2 examples:
* 30°C could well be the temperature from the "Retour condensateur"
<img width="1913" alt="Image" src="https://github.com/user-attachments/assets/41dd3a32-0936-42f3-a8a2-0e381f7316d7" />
* 32°C could well be the temperature from the "Ballon"
<img width="1911" alt="Image" src="https://github.com/user-attachments/assets/49f7bb52-d0a5-473e-9319-d7de6384a9b4" />
A few other examples:
<img width="747" alt="Image" src="https://github.com/user-attachments/assets/bd6b7983-65e9-43f9-bbf3-985f9d304a9c" />
<img width="748" alt="Image" src="https://github.com/user-attachments/assets/b7224127-415a-4786-9551-d530951f565f" />
<img width="748" alt="Image" src="https://github.com/user-attachments/assets/7ddb0347-0557-47a4-ae31-fcbecf19c479" />
### What version of Home Assistant Core has the issue?
core-2025.2.1
### What was the last working version of Home Assistant Core?
core-2025.1.x
### 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
It looks like as soon as a Modbus frame is repeated (due to timeout), the next Modbus telegram is taken as answer.
This leads to value mixing between MB sensors.
The sequence of Modbus frame seems to be off.
A first approach would be to disable the Modbus timeout and wait for the next polling.
### Example YAML snippet
```yaml
"""yaml
# Read info from PAC
modbus:
- name: PAC
type: tcp
host: 192.168.1.23
port: 502
sensors:
- name: Température extérieure
slave: 1
address: 1003
input_type: holding
unit_of_measurement: °C
state_class: measurement
scale: 0.1
offset: 0
precision: 1
scan_interval: 10
- name: Température départ condensateur
slave: 1
address: 1004
input_type: holding
unit_of_measurement: °C
state_class: measurement
scale: 0.1
offset: 0
precision: 1
scan_interval: 10
- name: Température retour condensateur
slave: 1
address: 1005
input_type: holding
unit_of_measurement: °C
state_class: measurement
scale: 0.1
offset: 0
precision: 1
scan_interval: 10
- name: Débit capteur
slave: 1
address: 1020
input_type: holding
unit_of_measurement: l/min
state_class: measurement
scale: 0.1
offset: 0
precision: 1
scan_interval: 10
- name: Température ballon
slave: 1
address: 1100
input_type: holding
unit_of_measurement: °C
state_class: measurement
scale: 0.1
offset: 0
precision: 1
scan_interval: 10
- name: PAC Temp Z1 appartement
slave: 1
address: 1111
input_type: holding
unit_of_measurement: °C
state_class: measurement
scale: 0.1
offset: 0
precision: 1
scan_interval: 10
- name: PAC Temp Z2 Culte RdC
slave: 1
address: 1121
input_type: holding
unit_of_measurement: °C
state_class: measurement
scale: 0.1
offset: 0
precision: 1
scan_interval: 10
- name: PAC Temp Z3 Culte sous-sol 1er
slave: 1
address: 1131
input_type: holding
unit_of_measurement: °C
state_class: measurement
scale: 0.1
offset: 0
precision: 1
scan_interval: 10
- name: PAC Temp Z4 salle fête
slave: 1
address: 1141
input_type: holding
unit_of_measurement: °C
state_class: measurement
scale: 0.1
offset: 0
precision: 1
scan_interval: 10
- name: PAC état
slave: 1
address: 102
input_type: holding
state_class: measurement
scale: 1
offset: 0
precision: 0
scan_interval: 10
switches:
- name: Appartement
slave: 1
address: 6011
command_on: 1
command_off: 4
write_type: holding
verify:
- name: Salle culte
slave: 1
address: 6012
command_on: 1
command_off: 4
write_type: holding
verify:
- name: Sous-sol
slave: 1
address: 6013
command_on: 1
command_off: 4
write_type: holding
verify:
- name: Salle fête
slave: 1
address: 6014
command_on: 1
command_off: 4
write_type: holding
verify:"""
```
### Anything in the logs that might be useful for us?
```txt
Log covering both event (14:48:15 and 14:50:27):
2025-02-09 14:48:10.910 DEBUG (MainThread) [pymodbus.logging] Frame advanced, resetting header!!
2025-02-09 14:48:10.910 DEBUG (MainThread) [pymodbus.logging] send: 0x1d 0xf 0x0 0x0 0x0 0x6 0x1 0x3 0x4 0x4c 0x0 0x1
2025-02-09 14:48:13.911 DEBUG (MainThread) [pymodbus.logging] send: 0x1d 0xf 0x0 0x0 0x0 0x6 0x1 0x3 0x4 0x4c 0x0 0x1
2025-02-09 14:48:14.377 DEBUG (MainThread) [pymodbus.logging] recv: 0x1d 0xf 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x1 0x40 old_data: addr=None
2025-02-09 14:48:14.378 DEBUG (MainThread) [pymodbus.logging] Processing: 0x1d 0xf 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x1 0x40
2025-02-09 14:48:14.378 DEBUG (MainThread) [pymodbus.logging] decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[320], status=1)
2025-02-09 14:50:22.693 DEBUG (MainThread) [pymodbus.logging] Frame advanced, resetting header!!
2025-02-09 14:50:22.693 DEBUG (MainThread) [pymodbus.logging] send: 0x1d 0xb0 0x0 0x0 0x0 0x6 0x1 0x3 0x3 0xed 0x0 0x1
2025-02-09 14:50:25.695 DEBUG (MainThread) [pymodbus.logging] send: 0x1d 0xb0 0x0 0x0 0x0 0x6 0x1 0x3 0x3 0xed 0x0 0x1
2025-02-09 14:50:26.708 DEBUG (MainThread) [pymodbus.logging] recv: 0x1d 0xb0 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x1 0x2c old_data: addr=None
2025-02-09 14:50:26.708 DEBUG (MainThread) [pymodbus.logging] Processing: 0x1d 0xb0 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x1 0x2c
2025-02-09 14:50:26.708 DEBUG (MainThread) [pymodbus.logging] decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[300], status=1)
```
### Additional information
Full log attached covering both events:
[home-assistant_modbus_2025-02-09T14-25-35.079Z.log](https://github.com/user-attachments/files/18724847/home-assistant_modbus_2025-02-09T14-25-35.079Z.log)
That their configuration is wrong and they should expect modbus to be completely messed up.
At least I now know that it should work in 2024.12.5, and that’s what I will be installing and keeping for the next few years.
prj
February 10, 2025, 12:59pm
6
Tried 2024.12.5, it’s also broken there, and breaks even faster.