I might have found a solution for my issue. It seems like the temporary polling fix for the firmware issue with the ITC sensors (see below) is causing the unresponsiveness in systems without any ITC sensors.
After disabling line 167 in airtouch4.py the Airtouch integration seems to be working as expected. Luckily Marian has documented this fix clearly in the code, otherwise I wouldn’t never thought about disabling the line.
165 ### workaround for group messages not being received ###
166 ### TODO: remove this after issues is fixed by Polyaire ###
167 ### await self.request_group_status
I’m currently testing the stability of the integration but there haven’t been any lockups so far. Changes to the AC settings and dampers are now immediately processed and also reflected in the official Airtouch app. My guess is that the integration was trying to poll data from the generated ITC binary sensors that actually didn’t exist in my Airtouch system, which could explain the unresponsiveness / lockup and the message with the unknown type “0x2f”.
Hopefully this fix isn’t required anymore after Polyaire has updated the Airtouch firmware, so I’ll try running the original integration again after the update is released.
I managed to get the temperatures to stay updated all night with a NodeRed flow that every 15 minutes switches the damper in one zone from ITC to Damper, waits 20 seconds, then switches it back again. That shouldn’t make the damper actually do anything so shouldn’t cause any wear and tear on the hardware.
Yeah it seems like it’s not an issue when there are ITC sensors available. Without the ITC sensors the integration and the official Airtouch app actually get in a completely locked/ unresponsive state, so it’s more than a slowdown. All the “Connection error in receiver!” messages have disappeared from my log after removing the polling feature as a side effect.
No i do not think it is just an ITC issue - as i reported a couple of days ago on here - my whole system went unresponsive with the latest version (and i have ITCs in each room) - disabling the integration and rebooting HA, then powering off the whole of the AC (mains power breaker) was required to get it all back and running
This weekend i plan on re-enabling the integration and see if the same issues reapper after a couple of days again - will report back
I’m getting a LOT of disconnects, every 2-6 hours on average, whenever HA tries to interact with the Airtouch. The commands don’t seem to retry, so my action that has five steps might miss running a couple of the steps in the actions. For example earlier today the action that changes the Airtouch from heating to ventilation and damper percentage control did change it to vent, but it missed the steps that change the change it to damper percentages instead of ITC.
[custom_components.polyaire.airtouch4] Connection error in receiver!
[custom_components.polyaire.airtouch4] Message receiver lost connection, trying to reconnect...
[custom_components.polyaire.airtouch4] (Re)connecting...
[custom_components.polyaire.airtouch4] (Re)connected!
[custom_components.polyaire.airtouch4] Message receiver task (re)started...
The disconnects might be my bad patch code I did not test it properly (I am not using it, since I am also using the homekit plugin which does its own polling).
Thank you Marian, I’ve installed it just now and I’ll report back in a day or two how it goes. I’ve bought you a beer as a small token to say thanks for your work
Usually I could freeze the integration within 5 minutes and this hasn’t happened so far with version 1.4.4, so the update also fixes the issues for systems without any ITC sensors. The fix of not adding the low battery sensors was also implemented correctly, they do not show up anymore in Home Assistant if there aren’t any ITC sensors available. Thanks for the quick fix!
Has anyone else had as much of a problem with disconnects as me? I’m starting to wonder if my Airtouch unit is faulty.
I noticed that sometimes I can’t log into the Airtouch4 with the Airtouch app, when I look on the tablet the WiFi isn’t connected. We have a good quality router and everything else on WiFi is solid.
When I ping from my PC / R.Pi4 I get a lot of packet loss
Packets: Sent = 226, Received = 205, Lost = 21 (9% loss),
Minimum = 1ms, Maximum = 1298ms, Average = 57ms
322 packets transmitted, 230 received, +51 errors, 28.5714% packet loss, time 323565ms
rtt min/avg/max/mdev = 1.881/61.480/2142.546/217.934 ms, pipe 4
Whereas when I ping from any machine to any other wired or WiFi device I get 0% packet loss. I’ll email Polyaire, but I’d like to hear if anyone else gets packet loss pinging their Airtouch4.
Just tried pinging the Airtouch 200 times and had 0% package loss with an average round trip time of 9 ms. Do these values change for you if you disable the Airtouch integration and is the Airtouch connected to a 2.4 GHz or 5GHz band?
Packets: Sent = 200, Received = 200, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 104ms, Average = 9ms
I don’t use the AirTouch app at all but I did notice a problem overnight. I had switched the AC off overnight then a NodeRed flow kicked off this morning to warm the house up. All the nodes in the flow said they fired without problems but the AC stubbornly stayed switched off. There was a familiar error message in the log:
2022-07-16 06:04:29 ERROR (MainThread) [custom_components.polyaire.airtouch4] Connection error in receiver!
I’m going to test it again overnight with a changed startup time because it coincided with an auto backup and I’ve noticed other integrations sometimes timing out when those backups are running.
Thanks @tamorix . Depending on when I measure I get between 3% and 10% packet loss to the AirTouch4. I get no packet loss to other wireless devices. I installed a network monitoring solution which will ping everything every 10 seconds to gather info I can pass on to Polyaire.
I have a backup setting on the Airtouch to start heating in the morning. I leave the system on all night in winter for bedrooms, I just want to warm up zones that are off at night.
Same thing happened again overnight. NodeRed flow showed all nodes had fired but the HA logbook showed no entries for AirTouch. I’ll try something different again tonight but otherwise maybe I’ll have to leave the ac on 24/7.
It’s worth a shot. Given some devices have no packet loss and the Airtouch has a lot of packet loss I suspect it’s more about the device than the channel. A WiFi site survey says the channel I was using was ok, but I’ve moved to a slightly better one.
I’m having a heck of a problem with updates to HA / Airtouch not appearing, and a lot of connection resets, but I think the WiFi is probably the major cause of it.
I did not test it properly (I am not using it, since I am also using the homekit plugin which does its own polling).
