'ModbusHub' object has no attribute 'async_pymodbus_call' 2023.9 #80
Comments
|
I can not fix this issue fully right now. We will have to wait for an update for HA. The pymodbus wrapper in HA is broken. If this is not fixed I will have to make my own, but not looking forward to that. Will push my progress to dev, so you can try it yourself. |
veista
changed the title
|
@veista - thank you! 🍺 |
|
hi, Is the problem not related to a name-change in the ha-modbus wrapper-lib? I've replaced it locally in device.py No exceptions in the HA Logs either so far |
Concider reading the issue and responses. Yes that is one problem. You can download the fix for that from dev. Even though I implemented that change, it does not work. I spent a couple of hours debugging and figured that the new pymodbus version is not fully compatible with the wrapper used in HA. |
Than you for your continuing support! |
Are you running with Modbus tcp or serial? |
|
Modbus Serial I'll monitor it for some time if it stops working and maybe add the suggested error-handling arguments @veista - great job btw. I love this integration 🍺 |
OK and thanks. Then it seems to me that only the TCP side is broken or it depends also on the bridge device. |
|
Can you test the dev branch if it works for you? |
|
"dev" branch did not work unfortunately master branch with replacement of method-name (async_pymodbus_call -> async_pb_call) worked though |
|
Well that seems fairly odd since there should be no difference (I get this error too almost always, sometimes it works for a minute). From manifest.json could you change the minimum requirement for pymodbus to 2.4.1 and try again? |
|
wasn't the issue but rather: diff --git a/custom_components/nilan/device.py b/custom_components/nilan/device.py
index 95a28fd..c8d6946 100644
--- a/custom_components/nilan/device.py
+++ b/custom_components/nilan/device.py
@@ -38,7 +38,7 @@ class Device:
"name": self._device_name,
"type": self._com_type,
"method": "rtu",
- "delay": 1,
+ "delay": 0,
"port": self._host_port,
"timeout": 1,
"close_comm_on_error": "false", |
That is funny. On my setup I cannot even connect with delay 0 on 2023.9. The wrapper seems to be completely broken to me. |
|
HA 2023.9.1 has updated pymodbus to 3.5.1 have you tried that already? |
|
Yeah although I'm not smart enough to help fix anything I did update to 2023.9.1 last night - both this Nilan modbus integration and the one I use for my Solax inverter are still having issues. 😥 |
Noticed this morning that they pushed a new update. Will try today... I'm leaving on a trip again tomorrow so lets hope it works. Will anyway push a beta release so if it gets fixed on HA you can get this integration working again. |
I had to also go back to 2023.8.4 since the new update broke also z-wave and other stuff... I recommend going back and skipping this months release. I suspect it will take time untill all of the problems get fixed. |
|
Also I suspect the issue #76 already had symptoms of something not working right with modbus. Though it has nothing to do with the root cause of that. |
Tried the latest versions. Still the issues remain unfortunately. Released the partial fix as beta and reverted delay to 0. |
|
Hi, |
|
Resolved with 2023.09.2 and 1.2.5B |
|
Having a similar issue. Updated to 1.2.5B but still "Failed to connect" when I try to re-install the integration. To the log it gives the following error: This error originated from a custom integration. Logger: pymodbus.logging Failed to connect [Errno 111] Connect call failed ('192.168.0.111', 502) I restored an older full backup, and the integration works ok again on that so I assume that the bridge device is working OK. I have a RP4 and usb to rs485 adapter. |
Had a similar issue on my dev environment. Could not replicate once is magically started working. Try the new release 1.2.6. If the issue remains just keep trying to install it again. The issue is somehow in the config flow, but cannot pinpoint the cause. |
|
Bumped to 1.2.6 with a HA restart after installing the HACS module. Still unable to install the integration: Logger: pymodbus.logging Connection to (192.168.0.111, 502) failed: [Errno 111] Connection refused |
|
It seems to me that for some reason the usb adaptor is busy. I will try and simulate this issue in my dev environment when I have time. Have you tried to do a Full reboot of your system? Power off and power on. |
|
Ok. So I think I misunderstood your setup. You have made your own bridge device with a RPi and an USB adaptor? The newer pymodbus is at the moment much less forgiving than the old one, so it might be an issue in both ends. I'll read the documentation again and try to figure out if I'm missing something in the update. |
|
Just to inform, the setup with 1.2.6 works ok now. I just restarted all, including the bridge device also. Did not need to manually touch anything, and the integration is now up and running ok. Thanks for the great piece of code 💪🏻 |
Hello, just updated to 2023.09.b0 to test and got the below error. I am unable to clearly determine what the core issue is, but perhaps you can ?
Logger: homeassistant.config_entries
Source: custom_components/nilan/device.py:120
Integration: Nilan (documentation, issues)
First occurred: 10:50:22 (1 occurrences)
Last logged: 10:50:22
Error setting up entry Nilan for nilan
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 387, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/nilan/init.py", line 41, in async_setup_entry
await device.setup()
File "/config/custom_components/nilan/device.py", line 61, in setup
hw_type = await self.get_machine_type()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/nilan/device.py", line 120, in get_machine_type
result = await self._modbus.async_pymodbus_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'ModbusHub' object has no attribute 'async_pymodbus_call'
The text was updated successfully, but these errors were encountered: