That’s the answer, set_percentage, thanks! The label in the GUI for that method is “set speed” so I’ve always overlooked it. The percentage setting for fan on should work, but this seems to be more reliable.
I have a delay between all calls to the Airtouch as well, usually 500ms to 2s, depending on what I feel like adding. I started doing it early on because it seemed to improve reliability.
I didn’t know about the repeat command you used below either, that’s handy for when I send commands that go out via an IR blaster to an old heat pump.
Hey Tom, me again. All has been running well since your last bit of wisdom. However, now I’m getting an “Unknown error occurred” message when I enter the IP address for my controller. I think what I could possibly be doing wrong.
Where are you typing the IP address of your controller in? in home assistant, Airtouch extension settings? Why does it need to be typed in again? Where are you seeing the error message? Can you see anything in the home assistant log?
I probably won’t reply quickly, but the rest of the community will help.
Some new information on recent connection issues is contained in this post on Whirlpool but I don’t know enough to fix it. If correct it seems to me it would affect both the AirTouch integrations that are available:
@spry-salt I’ve still got contact with a service tech who is playing middleman to an engineer at Polyaire.
I’ve had my AT4 app on the wall panel crashing/closing whenever the app gets backgrounded which when using th 1.4.4 update would stop communication with the AT4 app on my phone. Rolled back to 1.4.3 which now seems to have connectivity back between the two official apps.
Wall tablet started reporting not enough memory even though nothing was using it all. Engineer came back with “1.4.4 only extends the heartbeat packet time based on 1.4.3, and theoretically will not cause such a problem.”
I’ve been using the custom AT4 integration for months and not had this level of disconnection before. The october security update must have been the beginning of something in the backend which has progressed to where we are now.
Official Airtouch integration does successfully connect and reports information but has sadly, no options for systems without ITCs which means no temperature automations.
I’m 20 years past my programming days and my knowledge of linux, c and java is well outdated so I’d be poking around pretty blindly to try make the integration @mihailescu2m work again.
Will see what todays back and forth to the service tech brings and move on from there.
I’ve been working on a new AirTouch 5 integration for the past several months and because the APIs are so similar I have added AirTouch 4 support as well.
The integration is set up for installation via HACS (needs to be added as a custom repository at the moment).
The integration has been built from the ground up, and includes support for manipulating zones as both temperature controlled (via climate entities) and dampers (via cover entities). I’ve tried to improve the reliability of sending commands to the AirTouch, so if there’s any errors the command will be automatically retried (if it’s safe to do so).
One unique feature of this integration is auto-discovery of the AirTouch IP address. There is no need to manually set the AirTouch IP address (although I intend to add optional support for manually setting the IP address in a future update).
Special thanks to @spry-salt for helping with testing for the AirTouch 4.
Ben has gone above and beyond by extending his integration to include the AirTouch 4 as well as the newer model.
Having previously used both the official and other HACS integrations, for my installation this one is far and away more reliable and flexible because Ben has taken the time to add a lot of code to check for connectivity issues and improve the responsiveness of the device. I highly recommend this integration.
Is it likely to work if we switch from the integration on this thread to that one? I don’t need to, this one is working perfectly for me, but it sounds like it could be very useful for the people having connectivity issues.
Yes, it should be easy to switch. This integration uses the domain “airtouch” which is different to the two existing AirTouch 4 integrations, so they can actually run side-by-side if you just want to trial the new one. If any of the entity names have already been used Home Assistant will automatically add a numerical suffix to make them unique. You can see which entities are managed by this integration from the integration’s settings page.
Migrating automations and dashboards may take a little bit of effort since the entity model has changed in my integration, e.g. using cover entities instead of fan entities to represent the dampers. I’ve provided a description of all entities in the README.
Thanks so much for this update. I am keen to test this out; however, unfortunately, the integration is unable to automatically detect my AirTouch 4 instance.
Is there any workaround for me to be able to add my instance manually, or is an update to the integration required?
I found it easy to switch over. I was also able to remove some old yaml that I had for sensors that the new integration provides. And there’s new functionality that’s rather nice, such as an indicator for firmware updates. The biggest plus for me is that it stays connected, corrects for any errors in sending commands (that used to be a big problem for me - sending a command was very hit and miss as to whether it got executed by the AT4) and it keeps the temperature sensors up to date all the time instead of going into long periods of no updates. I don’t think you’ve got anything to lose by giving it a try.
Interesting. I have so many automations, including integrations with AppDaemon, changing over would be extremely time consuming. I might give it a shot some time to see how it is though.
One thing that I would find invaluable is an indicator for when the system is actively heating / cooling, or idle. I’m not sure that’s possible. If I really wanted it I might have to do it based on power draw or something similar.
Discovery uses UDP broadcast to port 49004, so if it’s just a firewall issue you could try opening up that port for UDP (send and receive).
Unfortunately, there’s no work-around at the moment if the network configuration doesn’t allow UDP broadcast.
Manual configuration of the IP address is the next feature I’m planning. Hopefully I’ll have an update next weekend.
The API doesn’t include any indication of idle state as far as I have seen (neither the AirTouch 4 or AirTouch 5).
My integration will show an indication of whether the system is cooling or heating if you are running in auto mode though. Auto mode is called “Heat/Cool” in Home Assistant to align with the descriptions of the HVAC modes in the Home Assistant documentation.
Unfortunately, I haven’t been able to see any broadcast packets on that port within my LAN from my AirTouch 4 controller - I have double-checked my firewall, but it looks like my unit may just not be broadcasting. I also have not updated to the latest firmware, so that may be part of it.
Thank you so much for your work - if you do get around to doing this, I am definitely keen to try it out!
