Airtouch 4 integration (AUS)

Feature Requests
608

I also have the AT5 tablet connected to a 5 GHz network and also saw an increase in connection errors. It was around the same time I moved an access point and I figured network interference caused the connection errors. My closest access point is 2 meters from the Airtouch and that access point didn’t move, so the connection errors were still unexpected. After optimizing the network environment my connection errors disappeared, but it does seem like the latest Airtouch update causes a more unstable connection.

The Github issue you linked to now also includes a comment how to downgrade the Airtouch console version (at your own risk).

609

In the past I’ve had issues with the API not always responding so I created a script to set the damper percentage which might be useful in this case. This script tries to set the damper percentage a total of 4 times in case it doesn’t work initially and uses both the fan.turn_on and fan.set_percentage service. I’m not using this script anymore but after a quick test is still seems to work, so I thought it might be useful to someone else.

Brief description of the script:

  1. Check if the damper is off or if the current damper percentage is unequal to the new damper percentage (to prevent unnecessary API calls). If none of these conditions are true, stop the loop.
  2. Turn on the damper and immediately set the desired damper percentage in the data field with fan.turn_on.
  3. Wait 10 seconds for the API call to be processed and the damper to physically move in the desired position.
  4. Check if the damper percentage is indeed set to the new value.
  5. If not, use the fan.set_percentage service to set the correct damper percentage and wait 10 seconds again.
  6. Go back to step 1 (with a maximum of 4 loops).

As you could potentially call this script for multiple dampers the script is in queued mode (parallel is also an option).

alias: Set Damper Percentage (Loop)
sequence:
  - variables:
      damper_target_percentage: "{{ damper_target_percentage | default(0) | int }}"
  - repeat:
      count: "4"
      sequence:
        - if:
            - condition: template
              value_template: >-
                {{ state_attr(damper,'percentage') | int !=
                damper_target_percentage or states(damper) == 'off' }}
          then:
            - service: fan.turn_on
              data:
                percentage: "{{ damper_target_percentage }} "
              target:
                entity_id: "{{ damper }}"
            - delay:
                hours: 0
                minutes: 0
                seconds: 10
                milliseconds: 0
            - if:
                - condition: template
                  value_template: >-
                    {{ state_attr(damper,'percentage') | int !=
                    damper_target_percentage }}
              then:
                - service: fan.set_percentage
                  data:
                    percentage: "{{ damper_target_percentage }} "
                    entity_id: "{{ damper }}"
                - delay:
                    hours: 0
                    minutes: 0
                    seconds: 10
                    milliseconds: 0
          else:
            - stop: Damper is set to the correct percentage
description: Set Damper Percentage (Loop)
fields:
  damper:
    name: Damper
    required: true
    description: Entity_id of damper.
    selector:
      entity:
        domain: fan
    example: fan.damper_living
  damper_target_percentage:
    name: Damper Target Percentage
    required: true
    description: Damper Target Percentage
    selector:
      number:
        min: 0
        max: 100
        step: 5
        mode: slider
    default: 0
    example: 80
mode: queued
max: 50
610

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.

1 Like
611

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.

612

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.

613

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:

https://forums.whirlpool.net.au/thread/3qqplnz3?p=16#r73690731

614

@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.

615

Hi everyone,

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.

3 Likes
616

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.

617

Nice work @TheNoctambulist :slight_smile:

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.

618

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.

619

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?

620

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.

621

And it automatically recovers if the AirTouch tablet reboots…

622

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.

623

You could always set it up in parallel to your existing one without compromising anything.

624

I might try it some time. Main advantage seems to be for people with comms problems, which fortunately right now I don’t have.

625

Possibly more longevity. The other integrations seem to be no longer in active development or support.

626

It’s also a dead simple instal, zero config required.

627

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.