Echonet Lite disconnecting sporadically until restart #181
Comments
|
I'm getting a similar issue. I've been trying to isolate the issue and found this issue. All of my heat pumps have the same issue, like the orig poster, the Mitsubishi app still works fine. |
|
This integration may be the cause, but we were unable to determine the problem from the log file.
Continue to observe after taking the above measures. |
|
I've had to rollback as I can't have my home as a test environment overnight sorry. I can say that I'm a network engineer and it wasn't a network issue cause such significant delays observed over days. I also have 3 Mistsubishi heatpumps (2 x AP25 and 1 AP35) and they all had the issue at the same time, so I think that eliminates the heat pump being the issue. I notice the orig poster has the same model heatpumps. I'll try and roll forward during the day but not sure if it will be long enough to trigger it. Are there some manual debug commands I can run to figure out what is causing the issue when it happens? |
|
@16thompn So if I understand this correctly - this issue started in March, but at the time you had not performed any sort of update of either home assistant or this component, having not updated in 6 months? Has anything else in your environment possibly changed? Do you add the devices manually using their IP address, or do you use the auto discover function (which relies heavily on multicast?) Perhaps try enabling the force polling option too to see if that helps? |
|
I would be adding the devices manually using their IP address rather then auto discover if that is what is being used at this point. It could possibly be some issue with IGMP snooping killing off multicast queries after a certain period of time? I have had no end of dramas with IGMP snooping for similar integrations which rely on multicast? |
|
@jacobw as you are a network engineer, fire up Wireshark on a spare laptop and monitor the traffic over a period of time to see if you can identify what is going on? |
|
Does the autodiscover process not just get the ip and save it? |
Apologies for the delay in getting back! That's correct. The HomeAssistant version had not been touched for over 6 months (including not updating) and I also had not installed any new software or integrations or even added any new devices. Everything was working so didn't touch it! We have not changed routers or anything to do with the internet set up. I manually locked the IP address of my HVAC systems in my router settings and then manually added the IP addresses to the EchoNet integration. This worked rather flawlessly for about 18 months. Since this I have tried restarting the router and lan hub, HA, power cycles the aircons and readd them again. It works for several days but still disconnects shortly after. I have actually added a restart HA button to my interface as a temporary measure and this works a treat as they will always be reconnected when the system reboots
Let me know if I can provide any more information or if there are any other debugging logs that I could access to shed more light on the issue. Cheers |
|
@16thompn To be frank it is difficult for me to attribute your issues to any fault in the custom component. As you said - you hadn't updated anything, it worked flawlessly for 6 months and then you started encountering issues. Your issue cannot have been caused by some issue with the custom component since it was working for 6 months. 6 months of issue free performance is hardly indicative of any undetected defect in the code. If you had said you updated to version X of either Home assistant and/or the custom component, and then the issues started there would be a clear causality and we could look at what changed in the code or not. But in your case we cannot. How exactly are you running Home Assistant? Unfortunately I do not have the time available to work on this. The only thing I suggest at this stage is to roll back to version 1.7.9 as there have been some significant updates in 1.8.0. |
|
I am running HA on a Raspberry Pi 4. The integration has now been working without issue for 72 hours since the last restart. I appreciate your feedback and if I continue to have it drop out I will try rolling back. It does make sense that something else might be going wrong given that it worked without issue for so long. I just can't work out what that might be given the lack of any changes to the system! I will update if I find any more useful info. My only thought is that if the request is timing out, is there a way to increase this? Can I do this manually anywhere? Thanks again |
|
I thought mine was dropping randomly too but turns out it wasn't random - it was the microwave! Interestingly all of my other 2.4ghz devices stay online and the Mitsubishi app shows it online but anything done in the app doesn't control the AC. I'm using a MAC-588IF, maybe they don't handle interference very well. I haven't tried changing 2.4ghz channel yet. |
Oh that's an interesting thought. We use our microwave very frequently so will have to do some testing to see if that's what is causing it. It could explain why it only began recently when we got a new microwave. Not sure if they are correlated as I can't remember exact dates. I'm away for a couple of weeks now but will see when I get back if this causes the issue! Thanks for your input :) |
|
FYI - I've switched from channel 11 to channel 1 on my 2.4ghz network and so far so good for me. |
Thanks so much for the info again. I am home next week so will switch everything over and report back. Hopefully this is the issue 😊 |
|
Hi, |
I went to go change the channel on my router but am using a Deco mesh wifi and they don't let you adjust your routers channel number. I have noted as well that it does not disconnect from the Mitsubishi wifi app despite being disconnected from HA. |
|
When an issue occurs, does an integrated device reload resolve the issue rather than an HA restart? If a device reload resolves it, you can use automation to fix it. |
|
I tried to do a device reload but it doesn’t connect. I can ping the device
so the IP hasn’t changed and the Mitsubishi app still works.
It seems like the full HA restart is required. Is there something more
hardcore than a device reload but less hardcore than a HA restart?
…On Sun, 15 Sep 2024 at 18:30, Naoki Sawada ***@***.***> wrote:
When an issue occurs, does an integrated device reload resolve the issue
rather than an HA restart?
If a device reload resolves it, you can use automation to fix it.
—
Reply to this email directly, view it on GitHub
<#181 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHJQ7EF5MV2ES2V4GMMGWB3ZWVASPAVCNFSM6AAAAABHBDHHEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJRGQ3DGMZYGY>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
|
It is likely that the pychonet UDP server is experiencing some communication problems, but I have not experienced any problems in either my production or test environments, so I am still unable to speculate on what to do about it. |
|
I've been seeing this recently as well. I have changed a fair bit on my end so I'm debugging bits as I go along and I am currently looking at pychonet to track down the behavior in pychonet currently so will open up an issue there to see if we can get to the bottom of it |
|
Thanks so much for checking this out Josh. |
|
After debugging for a week or so to try get to the bottom of this, I think I found my issue though I'm not 100% certain of the cause yet. Setup: MAC-568-IF-E - wifi interface lives on IOT_VLAN I did a reset on the MAC-568-IF-E wifi interface and made it connect to LAN_VLAN so it had access to the internet and set it up again and that so far (12 hours) has not had any errors/warning from home assistant and it appears to be back to solidly reliable I'm not sure what the exact cause is as the IOT wifi network does have some custom settings and is blocked from internet access compared to the LAN_VLAN network At this stage it appears the network setup or the reset has solved the issue. I will give it a week and attempt to put it back on the IOT network and see what happens.
@IsaacInsoll do you happen to see any ocasional packet loss when pinging, mine was happening on the first ping and it would randomly be dropped |
|
I've just done a ping from local machine and it seems like there is no dropouts at the moment. A few notes on my setup if it helps at all
I'm super happy to do any other troubleshooting that can help either now (while it's working) or if you want to give me some testing procedures to isolate the issue next time it dies. Thanks again! |
|
Can you post the docker inspect output for your container, is it on host network or mapped ports? Also another thing to try, this script will use the underlying library to poll you aircon machine for its on/off status Only tested on linux, windows was going on about not being able to create a non blocking socket I think python -m venv venv
source venv/bin/activate
pip install pychonet
python aircon_test.py "192.168.0.126" |
|
I'm running this in Container Manager on synology and can't see a way to do a docker inspect. Here's the compose file which I presume answers the question? version: "3"
services:
homeassistant:
container_name: homeassistant
image: homeassistant/home-assistant:latest
network_mode: "host"
environment:
WHEELS_LINKS: https://wheels.home-assistant.io/musllinux/
TZ: 'Australia/Brisbane'
volumes:
- './homeassistant/config:/config'
restart: unless-stoppedI'll test out that script on WSL2 tonight and see if I can get it working (while aircon is in running state so we have a baseline). I've got linux boxes at work but not at home |
|
Sorry for the insane delay on responding to this. I finally ran the task you provided and this is the output |
|
The Air Con is currently in "unavailable" state for the last few days. I haven't done a HA restart yet to fix it, but here's something that might help with troubleshooting the issue: Whenever we use the physical remote to change settings: HA picks it up immediately and the device is temporarily online for a minute before reverting to unavailable state. As previously discussed: it's still controllable from the factory Mitsubishi app as well. I'm not sure what else I can to do help test it but please let me know if there is something I can do. |
|
Host mode so is directly on the nas network interface so udp will work
Looking at the timing here that's 30 seconds and it fails to discover hence the error thrown below it
I'm leaning towards something wrong in your network, like what was causing my issue. You might need to break out wireshark and monitor the traffic to see whats happening |
|
Thanks for your help so far. I was running this in WSL2 on Windows 11 which can do some weird stuff with docker networking so I thought I'd run the same steps via SSH to my NAS which is literally the machine running home assistant. I'm a python noob and not sure how I've messed this up Isaac@NAS:/volumeUSB1/usbshare$ cd test
Isaac@NAS:/volumeUSB1/usbshare/test$ python -m venv venv
Isaac@NAS:/volumeUSB1/usbshare/test$ source venv/bin/activate
(venv) Isaac@NAS:/volumeUSB1/usbshare/test$ pip install pychonet
WARNING: The directory '/volume1/@fake_home_link/Isaac/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you should use sudo's -H flag.
Collecting pychonet
Downloading pychonet-2.6.13-py3-none-any.whl (83 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 83.1/83.1 KB 2.8 MB/s eta 0:00:00
Collecting deprecated
Downloading Deprecated-1.2.15-py2.py3-none-any.whl (9.9 kB)
Collecting wrapt<2,>=1.10
Downloading wrapt-1.17.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (85 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 85.6/85.6 KB 69.2 MB/s eta 0:00:00
Installing collected packages: wrapt, deprecated, pychonet
Successfully installed deprecated-1.2.15 pychonet-2.6.13 wrapt-1.17.0
WARNING: You are using pip version 22.0.4; however, version 24.3.1 is available.
You should consider upgrading via the '/volumeUSB1/usbshare/test/venv/bin/python -m pip install --upgrade pip' command.
(venv) Isaac@NAS:/volumeUSB1/usbshare/test$ python aircon_test.py "192.168.0.126"
Traceback (most recent call last):
File "aircon_test.py", line 5, in <module>
from pychonet.lib.udpserver import UDPServer
File "/volumeUSB1/usbshare/test/venv/lib/python3.8/site-packages/pychonet/__init__.py", line 1, in <module>
from pychonet.echonetapiclient import ECHONETAPIClient # noqa
File "/volumeUSB1/usbshare/test/venv/lib/python3.8/site-packages/pychonet/echonetapiclient.py", line 25, in <module>
from pychonet.lib.epc_functions import EPC_SUPER_FUNCTIONS
File "/volumeUSB1/usbshare/test/venv/lib/python3.8/site-packages/pychonet/lib/epc_functions.py", line 89, in <module>
def _call_int(data: bytes | list):
TypeError: unsupported operand type(s) for |: 'type' and 'type'
|
I wouldnt run it on WSL as I'm sure it will have the same issue as docker and udp packets not being able to be routed correctly It's throwing errors as your python version on the nas does not support the union operator You will want to test on a newer distro, download something easy like ubuntu or linux mint, in windows download the LTS iso and use rufus to burn it to a usb stick and run it live from usb on your pc/laptop |
|
Thanks heaps, will test it out and get back to you :) |
Good morning
I have been having this issue with my Mistsubishi Electric MSZ AP25/70 Aircon units since March and have tried numerous things to solve the problem.
After restarting home assistant, the aircons connect successfully and will maintain a connection anywhere from a few hours to several days before they become unavailable in home assistant and will not reconnect until the home assistant system is restarted. They still remain connected through the Mitsubishi App as well as through Google Home. They were running without issue for about 18 months before this issue began. I had not updated or changed anything on my homeassistant OS in about 6 months. Since then, I have updated to the latest version of echonet as well as updated the homeassistant core and homeassistant OS.
I have ensured that my router keeps these aircons on a static IP so that should not be the issue. I have enabled the debug log and posted the results below. You can see it is working normally before it seemingly begins timing out and will not reconnect. I'm not sure if this is an issue with the integration or my own personal setup. I have tried deleting and re-adding the devices since updating to the latest version of echonet. Any help would be greatly appreciated as I love the integration and use it everyday.
Please let me know if you need any more info. The debug log was 40mb as I enabled it immediately after restarting and it took three days before the latest disconnection issue so have included just the snippet below.
Cheers
Nick
The text was updated successfully, but these errors were encountered: