AirTouch integration becomes unavailable

[randellmatt]

(Posted previously in incorrect airtouch2 integration - moving to here)

No sure if others are getting this issue, but my AirTouch integration becomes unavailable almost daily and requires manual reload.

These are the logs from the latest unavailable event. I have version 0.2.6.

Logger: homeassistant.components.climate
Source: components/climate/init.py:367
integration: Climate (documentation, issues)
First occurred: April 17, 2024 at 7:57:04 PM (7 occurrences)
Last logged: 7:13:47 AM

Entity None (<class 'custom_components.airtouch2plus.Airtouch2PlusClimateEntity.Airtouch2PlusClimateEntity'>) does not set ClimateEntityFeature.TURN_OFF but implements the turn_off method. Please create a bug report at https://github.com/nathanvdh/homeassistant-airtouch2/issues
Entity None (<class 'custom_components.airtouch2plus.Airtouch2PlusClimateEntity.Airtouch2PlusClimateEntity'>) does not set ClimateEntityFeature.TURN_ON but implements the turn_on method. Please create a bug report at https://github.com/nathanvdh/homeassistant-airtouch2/issues
Entity None (<class 'custom_components.airtouch2plus.Airtouch2PlusClimateEntity.Airtouch2PlusClimateEntity'>) implements HVACMode(s): off, heat_cool, heat, dry, fan_only, cool and therefore implicitly supports the turn_on/turn_off methods without setting the proper ClimateEntityFeature. Please create a bug report at https://github.com/nathanvdh/homeassistant-airtouch2/issues

[nathanvdh]

Hey, sorry there should have been a 0.2.7 release with a networking fix I made to the underlying airtouch2 library - but I forgot to come to github and hit the magic 'create new release' button. I've released a 0.2.8 version that also fixes this complaint about TURN_ON and TURN_OFF supported features. Close this issue if it fixes your problems :)

[randellmatt]

I have installed the latest version and giving it a test run. Looks better so far and will close this issue after 24 hours.

Thanks for all of your effort!

[randellmatt]

Looks like this did not fix the issue unfortunately.

I have a lot of these messages in the log now - however they don't seem to be relaited to the time that it stops responding. I'll reload and try again.

2024-04-29 09:41:38.771 WARNING (MainThread) [airtouch2.protocol.at2plus.control_status_common] Unknown message type in header (0x2b)
File "/usr/local/lib/python3.12/site-packages/airtouch2/protocol/at2plus/control_status_common.py", line 74, in from_bytes
2024-04-29 09:41:38.771 WARNING (MainThread) [airtouch2.at2plus.At2PlusClient] Unknown status message type: subtype=0, data=2b:00:00:00:00:04:00:06:80:80:07:ff:81:81:07:ff:82:82:07:ff:83:83:07:ff:90:ff:02:bf:91:ff:07:ff

[nathanvdh]

Can you add this to your configuration to enable debug logging, reboot HA and send me the logs after it stops responding please.

# Logging setup
logger:
  default: warning
  logs:
    custom_components.airtouch2plus: debug
    airtouch2.at2plus.At2PlusClient: debug
    airtouch2.common.NetClient: debug

[randellmatt]

Will do. Sorry for the late response :)

[randellmatt]

Hi Nathan,

This is the results from the log around the time it stopped responding. Hopefully this helps:

2024-05-10 15:53:27.741 DEBUG (MainThread) [airtouch2.common.NetClient] Read payload of size 1: 55
2024-05-10 15:53:27.742 DEBUG (MainThread) [airtouch2.common.NetClient] Read payload of size 1: 55
2024-05-10 15:53:27.742 DEBUG (MainThread) [airtouch2.common.NetClient] Read payload of size 6: 9f:80:43:c0:00:20
2024-05-10 15:53:27.742 DEBUG (MainThread) [airtouch2.common.NetClient] Read payload of size 32: 2b:00:00:00:00:04:00:06:80:80:07:ff:81:81:07:ff:82:82:07:ff:83:83:07:ff:90:ff:02:d1:91:ff:07:ff
2024-05-10 15:53:27.742 DEBUG (MainThread) [airtouch2.common.NetClient] Read payload of size 2: ff:26
2024-05-10 15:53:27.742 WARNING (MainThread) [airtouch2.protocol.at2plus.control_status_common] Unknown message type in header (0x2b)
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/airtouch2/protocol/at2plus/control_status_common.py", line 74, in from_bytes
subtype = ControlStatusSubType(subheader_bytes[0])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/enum.py", line 744, in call
return cls.new(cls, value)
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/enum.py", line 1158, in new
raise ve_exc
ValueError: 43 is not a valid ControlStatusSubType

[nathanvdh]

Sorry I never responded - this log is just the integration trying to handle a message type it doesn't know about. It will just get ignored but I log a warning anyway so it doesn't go unnoticed. This isn't related to any kind of disconnection and shouldn't cause the integration to stop working. There is something else going going wrong and I don't really have anything to go on to help you.

[bigjezza]

I'm seeing this too, as a work around I thought maybe I could monitor states.climate.at2plus_ac_0.last_updated but seems to only update when there is an actual change. Is there a way the integration can update the last_updated every minute or something even when nothing has changed, so that I can build an automation to reload if the last_updated exceeds 90 seconds/integration stops? Or is there a better way to automate reloading the integration? All the values stay at their last value rather than change to unknown so its hard to figure out that its not responding.

[gavintweedie]

Also been getting this the last couple of months. I've tried upgrading the software on the android panel, and tried different WIFI settings on my AP (WPA2 vs WPA3, 2G only, 5G only etc) but it persists regardless.

I thought it might have just been when the AC went to idle/turned off, but sometimes it stays connected for 12hrs.. other times 2 minutes.

[gavintweedie]

As this appears to happen around the time of "Unknown message type in header (0x2b)" I'm going to suggest that this is related to #3

[bigjezza]

AirTouch 2+ Communication Protocol V1.1.pdf

I requested a copy of the API over a year ago, it is updated compared to the home assistant link, not sure if it helps?

[gavintweedie]

Built a workaround for myself, and in the process found something that might help move this along.

I found that communication would re-establish if you tried to change a setting. Say turn on heat. Or adjust temp. It'd trigger it to notice the disconnect and reconnect would happen.

My workaround: if last_updated for the panel room temp is greater than 10 mins, set temp to current set temp + 0.1 degree. 0.1 is perfect because the panel only supports 1 degree increments. So for example 20.1c triggers a reconnect, but no actual change happens. It goes to 20.1, and immediately goes back to 20c. Graphing works again etc.

I noticed on my graph that the small changes in set temp line up with as it's getting to temp either on the climb, or the fall back. I think what this shows is that the connection between panel and plugin drops out when its idle. It never becomes unavailable when temp is rapidly increasing or decreasing. Maybe one of these unknown updates actually means "no change" or is a keepalive or similar?

My fixup automation in case anyone wants to use something similar for a while:

alias: Airtouch Keepalive Check
description: ""
triggers:
  - trigger: time_pattern
    minutes: /5
conditions:
  - condition: template
    value_template: >-
      {{ ( as_timestamp(now()) - as_timestamp(states.sensor.ac_panel_temp.last_updated)) | int >  650}}
actions:
  - action: climate.set_temperature
    metadata: {}
    data:
      temperature: >
        {% set temp = (state_attr('climate.at2plus_ac_0','temperature')|float + 0.1) %} {{ temp }}
    target:
      device_id: 3e6178bf141ddbd44a3eb968182f7d25
  - action: logbook.log
    metadata: {}
    data:
      entity_id: climate.at2plus_ac_0
      message: Airtouch Keepalive Failed. Fixed.
      name: AC MHI Keepalive
mode: single

[gavintweedie]

I wonder if this is a NAT timeout from the TCP connection being completely idle for several minutes (no temp change to report). I'm going to change my automation to change the temp setting by +0.1c every 5 minutes for the next 24hrs, and see if I see anymore timeouts.

If not, then this is some kind of timeout issue. Maybe we can find a better command to send every few minutes as a pseudo keepalive instead of changing the temp to resolve this issue?

Will report back.

[gavintweedie]

First night I can remember where integration didn't become unavailable, left it as above adjusting set temp + 0.1c every 3 minutes.

You can see from this image the last two nights the current temp flatlines when no updates received, however last night the temperature fell as expected.

Next I'll change this from a temp based protocol keepalive to a ping for the next 24hrs. Keen to know if this is the TCP session between integration <> Airtouch timing out (perhaps due to nat from the docker container), or if its a lower level like arp or wifi timeout of an idle client (the airtouch display).