Thanks for giving us a heads up and attaching logs to the GitHub issue. I’ll take a look at this over the next few days and let you know once there’s an update to test.
@smitcoracing any chance you could get an updated copy of the API docs from Polyaire? I can probably reverse engineer something from the logs, but it’s always easier with a proper specification 
No problems. Happy to do testing with my setup should you need any more logs.
Hopefully official docs come through.
I suspect it is because the new update adds input/output features that may have changed the api slightly.
Weirdly enough, the integrations consistently find the Airtouch 5 through local discovery, can see it is configured as a spill and can see the 4 zones and their names. Just can’t do anything further.
Thanks for taking a look.
I have update versions ahead of public release ones and have no issues. Have you tried power cycling your whole ac system, not just the tablet?
@TheNoctambulist i did ask again last week about the api incase it had something for the new aux module and they confirmed the api hasn’t changed, IA I’ve had since the AT5 was released and that was always in the api
I updated too and my integration also stopped working …
I updated last night. The integration communicates with the console and reports temperatures correctly. I can control zones as well.
However, the AC units are reported as “Off” and do not reflect the state of the AC. I have not touched those settings, and so far the zone temperatures are still reporting.
@smitcoracing It’s busted on console version 1.2.0.
I’ll have a poke around when I have some time, if you can please ask airtouch what they’ve changed and let me know so I can fix it. 
Will see what the engineer says and get back to you.
Please confirm you have cycled power from mains
These are the errors I was getting related to the AC units:
Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:283
integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 8:51:00 AM (1 occurrences)
Last logged: 8:51:00 AM
[140273793315696] Fan mode is not valid. Valid fan modes are: low, high, auto
Note that these are indeed the fan speeds I have configured in my Airtouch console.
Bad news, after a reboot of the main Airtouch module in the ceiling, the integration will no longer load at all. Log below:
Source: config_entries.py:594
First occurred: 9:12:02 AM (1 occurrences)
Last logged: 9:12:02 AM
Error setting up entry 192.168.0.87 for airtouch5
Traceback (most recent call last):
File "/usr/local/lib/python3.12/asyncio/tasks.py", line 520, in wait_for
return await fut
^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/airtouch5py/airtouch5_simple_client.py", line 142, in _read_packets_until_match
packet = await self._client.packets_received.get()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/asyncio/queues.py", line 158, in get
await getter
asyncio.exceptions.CancelledError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 594, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/airtouch5/__init__.py", line 25, in async_setup_entry
await client.connect_and_stay_connected()
File "/usr/local/lib/python3.12/site-packages/airtouch5py/airtouch5_simple_client.py", line 129, in connect_and_stay_connected
for ac in (await self._wait_for_packet_or_throw(AcStatusData)).ac_status
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/airtouch5py/airtouch5_simple_client.py", line 150, in _wait_for_packet_or_throw
return await asyncio.wait_for(_read_packets_until_match(), 5)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/asyncio/tasks.py", line 519, in wait_for
async with timeouts.timeout(timeout):
File "/usr/local/lib/python3.12/asyncio/timeouts.py", line 115, in __aexit__
raise TimeoutError from exc_val
TimeoutError
All good, engineer is looking at this for us.
I have a Wireshark PCAP of the reload attempt if so desired. TCP connection to the console is succeeding, and I see some data about the zone names in the data returned from the console, so it’s not something low level. It has to be related to something related to the API.
Link to PCAP: Airtouch5-integration-reload.pcapng
The length of one of the packets has changed, I can work around it (it would be good to know what the new bytes mean though).
Will push some test code in ~2hrs hopefully, gotta head out.
New commit pushed here, but haven’t done a release yet GitHub - danzel/airtouch5py: Python client for the airtouch 5
i have the apk of the airtouch software so if you looking to roll back you can
Can I get a copy please ?
Engineer is still looking to all but had mentioned to me
“The only difference might be the ac data set but the api should not have used it”
This probably all in the console but I wouldn’t be messing with it
As a temporary workaround I mounted the updated packet_decoder.py file in docker compose and it works perfectly
The update has been paused as control 4 also has issues with the API