Constant HA requested an update from HVAC 192.168.178.41 but no data was received

[nzlrhyz]

Hey, I constantly get

Logger: custom_components.mitsubishi.sensor
Source: custom_components/mitsubishi/sensor.py:89
Integration: mitsubishi (documentation)
First occurred: 6:26:02 PM (48 occurrences)
Last logged: 6:38:09 PM
HA requested an update from HVAC 192.168.178.41 but no data was received

I can hange the modes/temps by using the climate controls but it will never update on the climate card.

By running the python only script I get no such disconnections ever even if spammed

Group: Air conditioner-related device group
Code: Home air conditioner
Instance: 1
ECHONET lite node discovered at 192.168.178.41 - Home air conditioner class
{'status': 'On'}
19
heat
medium-high
19
{'identification_number': '000006010458d50afffeab687f013001'}

Also is there a way to change the min/max temps you can set? As my units minimum is 19c and the entity customization doesn't save since it doesn't have a unique id I believe

Heatpump model: PEAD - M71JAA(D) ducted ac Wifi card: mac568 Echonetlite: On

[JodiTheTigger]

I have the same issue. However I reverted to commit 2ad566c7283f09df8f3ffb6d42b4e987b6c089a3 (version 2.0.1) and it works fine. So the regression was introduced after that commit.

[nzlrhyz]

I can confirm that rolling back to version 2.0.1 worked for me too

[AaronMountford]

Also experiencing the same issue, and also fixed by rollback to 2.0.1

[scottyphillips]

What versions of Home Assistant is everyone running?

[scottyphillips]

@nzlrhyz are you running a fork of the Echonet library, because I haven’t committed the identification API pull request yet….

[JodiTheTigger]

What versions of Home Assistant is everyone running?

I installed the latest (2.1.0), when I had this issue.

[scottyphillips]

No, I mean what version of Home Assistant are you running?

Also, are you installing this component manually or via HACS?

Scott

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Jodi the Tigger @.> Sent: Saturday, June 12, 2021 7:09:27 AM To: scottyphillips/mitsubishi_hass @.> Cc: Scott Phillips @.>; Comment @.> Subject: Re: [scottyphillips/mitsubishi_hass] Constant HA requested an update from HVAC 192.168.178.41 but no data was received (#23)

What versions of Home Assistant is everyone running?

I installed the latest (2.1.0), when I had this issue.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/scottyphillips/mitsubishi_hass/issues/23#issuecomment-859912360, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHQNDAWAE236ZPQTL45BV3TSJ3QPANCNFSM452IJ7HA.

[scottyphillips]

I have a possible theory it’s related to the ‘mitsubishi_echonet’ 0.4.1 code. There is a pull request over there to fix up some behaviour some people are seeing related to the outdoor temperature sensors.

[nzlrhyz]

@scottyphillips On my pc yes I was running a fork, However my home assistant is running the HACS install, I have also tried a manual install with no luck.

Core: core-2021.5.5 OS: 5.13

I'm now updating to try your fix. V2.1.1 seems to have fixed my issues! Thanks! Quick question, anyway to change how fast it updates HA? if I change the temp/mode via my wall panel HA has about a 30s lag

[scottyphillips]

thats the polling interval that is baked into home assistant. its better that way because it is giving you an accurate reading rather then trying to update the panel asynchronously...

also, i had to release a 2.1.2 version because 2.1.1 (mitsubishi_echonet 0.5) broke outdoor sensors

[scottyphillips]

@AaronMountford @JodiTheTigger can you please test 2.1.2 and verify it has fixed the issue...

[JodiTheTigger]

I can't work on my PC till tomorrow, so I'll try 2.1.2 then

homeassistant version:

Version | core-2021.6.2
-- | --
Installation Type | Home Assistant Container
Development | false
Supervisor | false
Docker | true
Virtual Environment | false
Python Version | 3.8.9
Operating System Family | Linux
Operating System Version | 5.12.9-arch1-1
CPU Architecture | x86_64

[unit299queenstreet]

@AaronMountford @JodiTheTigger can you please test 2.1.2 and verify it has fixed the issue...

I tried the 2.1.2 and yes i get no errors , but it doesn't actually work, i turned on the air con via the wifi app, and then when I attempted to turn it off in HA it wouldn't. no errors in logs. i reverted back to 2.0.1 and all is working, HA 2021.6.4

[scottyphillips]

Can you try to run some debug logs thanks. Have you tried to do other things like change the temperature settings. Have you also waited for the polling to catch up and the screen to update after issuing the off command.

Are you watching the actual unit LCD screen when you switch the unit off or are you checking against the wi-fi app. There is a delay between issuing the command using echonet, the unit switching off and then the mitsubishi app updating.

What sort of system are you running. what features does it have.

logger:
  default: warning
  logs:
    custom_components.mitsubishi: debug

[unit299queenstreet]

attempting it again Question why your on my Outside Temp is N/A, but i think the unit doesn't have one maybe Why don't i have any Zone information ?

[scottyphillips]

because the integration doesn't support zones and never will because the echonet standard doesn't support it. you could use ask the melview integration maintainer to look into it if you want to use a cloud based approach.

[unit299queenstreet]

I get this the first time as well taking long to setup Logger: homeassistant.components.sensor Source: /usr/local/lib/python3.8/asyncio/events.py:81 Integration: Sensor (documentation, issues) First occurred: 1:50:25 PM (4 occurrences) Last logged: 1:50:25 PM

Setup of sensor platform mitsubishi is taking over 10 seconds. Setup of sensor platform moon is taking over 10 seconds. Setup of sensor platform hassio is taking over 10 seconds. Setup of sensor platform bureau_of_meteorology is taking over 10 seconds.

[scottyphillips]

can you disable the sensor thanks and focus on the climate integration first... its possibly a seperate issue

[scottyphillips]

this outdoor sensor has caused me nothing but grief lol...

[unit299queenstreet]

All okay i could turn it on and turn it off and that showed in the wifi app

2021-06-15 13:50:13 DEBUG (MainThread) [custom_components.mitsubishi.climate] ECHONET lite HVAC 192.168.3.108 component added to HA 2021-06-15 13:50:13 DEBUG (MainThread) [custom_components.mitsubishi.climate] HVAC has the following get properties: 2021-06-15 13:50:13 DEBUG (MainThread) [custom_components.mitsubishi.climate] {'Operation status': 128, 'Air flow rate setting': 160, 'Operation mode setting': 176, 'Installation location': 129, 'Standard version information': 130, 'Identification number': 131, 'Set temperature value': 179, 'Manufacturers fault code': 134, 'Fault status': 136, 'Fault description': 137, 'Manufacturer code': 138, 'Measured value of room temperature': 187, 'Status change announcement property map': 157, 'Set property map': 158, 'Operation power-saving': 143, 'Get property map': 159} 2021-06-15 13:50:13 DEBUG (MainThread) [custom_components.mitsubishi.climate] HVAC has the following set properties: 2021-06-15 13:50:13 DEBUG (MainThread) [custom_components.mitsubishi.climate] {'Operation status': 128, 'Installation location': 129, 'Operation power-saving': 143, 'Air flow rate setting': 160, 'Operation mode setting': 176, 'Set temperature value': 179}

[unit299queenstreet]

i

this outdoor sensor has caused me nothing but grief lol...

don't you just love home automation. i don't think it actually exists on my system,

[scottyphillips]

Not it doesn't exist on your system which is the problem, the system was trying to initialise a sensor that didn't exist and things broke. I have just pushed an update 2.1.3 which i am hoping will fix the issue for people who are using the sensor.

[unit299queenstreet]

Can confirm 2.1.3 eliminates the outdoor sensor for me Apart from specifying the fan modes its all working on HA 2021.6.4

[scottyphillips]

Cant help with fan modes sorry, thats very much trial and error at the moment as per the instructions. There is probably some ugly ass way of cycling through each setting with ECHONET to see which ones work and which ones dont but thats a story for another day

[unit299queenstreet]

its fine, i only have low, medium, high and auto, that a simple workout from the wall panel and the wifi app.

[khcnz]

Hey @scottyphillips I'm 99% sure this relates to multiple concurrent requests to the same controller at the same time. HA tries to update both the climate and 2xsensor component at the same time which doesn't work. With the async calls in HA all the sensors and climate endpoints are hit at the exact same instant.

If this is the case people should only be seeing this issue when they have the climate component and one or more sensors for the same ip address (so you end up with 3x concurrent requests to the same endpoint)

You can replicate this exact behavior by opening two windows that loop on update() to the same endpoint every second using the econet library directly.

I had been playing with a couple of solutions to fix this before I'd seen this thread 1) You can set the PARALLEL_UPDATES flag to 1 2) Change the component into a platform with multiple subcomponents so you can share the one update call 3) Store the api object into the hass object and share that (and tell HA to only poll one of them) hass.data[DOMAIN][ip] = mit.HomeAirConditioner(ip) 4) Use the DataUpdateCoordinator class https://developers.home-assistant.io/docs/integration_fetching_data/ 5) Add the additional sensor to the state attributes then create template sensors

I think this only just became an issue for others, as before you merged the async update code recently, each update was actually running in sequence...

With some of these changes I only see the occasional no data received message, I was also wondering if the timeout at 500ms is a bit fast with the extra data being returned (outdoor temp, swing mode etc). I haven't yet tried playing with the timeout.

[scottyphillips]

I would be more then happy to approve a PR

[khcnz]

PR here - https://github.com/scottyphillips/mitsubishi_hass/pull/28

[cdouet]

Hello,

First of all, thank you for the integration! Now, I get regular issues such as the following:

This happens several times a day.

My setup is as follow:

I am using the version 2.2.0 of your integration and my AC is a Mitsubishi MSZ-AP25VG.

I would appreciate any help to remove those warnings.

Thanks!

[scottyphillips]

The warnings are there to advise if there is a systematic problem with the system. If you are only getting the occasional warning then it is likely a case that your HVAC is missing the odd update message or two which is no cause for concern. The issue is being looked at to see whether or not timings need to change at all, but I have no plans of switching off the warning messages. If the messages bother you then you can customise your logging settings..

[scottyphillips]

@khcnz the 'pychonet' branch has a brand new 'echonetlite' custom component. This centralises the API calls at a platform level. No more flooding API calls. As added bonuses it now uses config entries to configure - no more YAML - and provides select entities for horizontal and vertical swing modes! Give it a try!

[khcnz]

Nice work - will give it a spin today!

[scottyphillips]

Ive also been playing around with a highly experimental asyncio version of my library. I have a working theory that many of the request failures in the original code are related to the crude nature of the UDP communication in the original code using the generic socket library.

Basically in the original code it goes like this: request -> open UDP port -> fire message -> wait 1 second (while keeping port 3610 locked up) -> did message come back? if yes pass if no fail. This is all done synchronously which requires us to wrap it around the various Home assistant asyncio helpers.

There is a contention problem with the current approach if we start adding more devices to the mix because we must listen on UDP 3610 for responses. If we are trying to poll multiple devices at once then there is a likelihood the port will not be open for when a message comes back. At that point then the message is lost.

So what my hastily written branch does is that it uses asyncio to create a listener on UDP 3610 - which is always running in the event loop - and also provides centralised management over packets being transmitted as well. So what happens now is based around two seperate streams both using an asyncio UDP helper.

1. request -> fire message to UDP worker class -> UDP worker fires message. We wait to see if the TID comes back.
2. response -> comes in via the listener. Listener processes packet against a dict containing all our known endpoints.

Its not perfect as I am seeing situations where the listener seems to stop working altogether and I am trying to determine the reason why, which I am looking into.

[scottyphillips]

im closing this issue as the 'pychonet-2.0' branch should resolve the majority of these performance issues..