IntesisHome / AC Cloud Control: push socket server down while the HTTPS API stays up — anyone else since 15 Aug 2026?

Third party integrations
1

Since around 11:45 CEST today my Intesis-based ducted AC has been unavailable in Home Assistant, while I can still control it perfectly from the Intesis web portal. I isolated which part of their cloud is broken and thought it was worth sharing, because the logs on their own are misleading.

Setup: HA 2026.8.1, jnimmo/hass-intesishome 2.2.0, Mitsubishi Heavy Industries VRF with an AC Cloud Control gateway.

The log just repeats this every ~7 minutes:

[pyintesishome] Connection to 212.92.41.143:5210 failed: [Errno 110]
  Connect call failed ('212.92.41.143', 5210); auto-reconnect will retry
[custom_components.intesishome] Setup of config entry ... cancelled

Which looks like a local network or firewall problem. It isn’t. I probed the endpoints from my LAN and from a cloud host on a completely different ISP, same result both times:

Endpoint Result
user.intesishome.com:443 → 212.92.41.142 connects in 0.27 s
accloud.intesis.com:443 → same IP connects
212.92.41.143:5210 (push socket) timeout
212.92.41.143:5209 timeout

Both hostnames resolve to the same server, and that server is fine — which is why the portal and the mobile app keep working. What’s down is the persistent TCP socket on .143:5210, and that is the only thing the integration uses for state and commands. Hence: portal fine, Home Assistant dead.

Two things that made it worse for me:

  1. The config entry ends up in setup_error, not setup_retry. Home Assistant never retries that state, so the integration will stay dead even after Intesis comes back, until you reload the entry or restart HA. I worked around it with an automation that reloads the config entry every 15 min while the entity is unavailable, and notifies me when it recovers.

  2. Two days earlier, a partial handshake left the entity registered but with hvac_modes: ["off"] and no TARGET_TEMPERATURE — so every automation touching it threw Entity ... does not support action climate.set_temperature. Reloading the integration fixed it.

There’s an open request to poll poll_status() over HTTPS instead of depending on the push socket — jnimmo/hass-intesishome#50. Today is a good argument for it: the HTTP path was healthy the whole time.

Anyone else seeing this since 15 August? If you are, it would help to know your region and gateway type (IntesisHome vs AC Cloud Control) — that would tell us whether it’s a global outage or one server in the pool.

2

Thanks for posting this! Just adding that I am seeing the same issue and thank you for the suggestion to set up an automation to check if it has come back.

3

Second data point, from Italy — plus a timeline detail that may explain why some
people still seem fine.

Setup: HA 2026.8.2, jnimmo/hass-intesishome 2.2.0 + pyintesishome 2.2.0,
Mitsubishi Heavy Industries split with an IS-RC-WIFI-1-V2 (MH-RC-WIFI-1B)
gateway on the IntesisHome portal, integration device type IntesisHome (not AC
Cloud Control). Open Fiber FTTH, Italy.

The interesting part: my AC ran normally all through 15 and 16 August. I have
InfluxDB state writes from it up to ~03:00 CEST on 17 August — overnight cooling
cycles, setpoint changes, acks, no errors. My HA container was then restarted at
04:04 CEST, and the first reconnect after that boot failed at 04:06:37. It has
failed every ~7 minutes since, 165 times so far, always identical:

Connection to 212.92.41.143:5210 failed: [Errno 110] Connect call failed
  ('212.92.41.143', 5210); auto-reconnect will retry

So my established socket survived roughly 40 hours after your outage started,
and only died once the client had to open a new one. If that generalises, their
push server stopped accepting connections around 15 August while existing
sessions kept flowing — meaning everyone on that host is affected, but only
notices at their next HA restart, integration reload or transient reconnect.
Easy check: if your Intesis entity still works and you have not restarted HA
since 15 August, that’s the evidence. Corollary while this lasts: don’t reload
the entry or restart HA if your entity is still alive — that live socket may be
the only control path you have.

Also, Errno 110 is a timeout rather than a refusal, so the SYNs are being
blackholed, not rejected. Probing from my LAN just now:

Endpoint Result
user.intesishome.com:443 → 212.92.41.142 connects, 0.04 s
accloud.intesis.com:443 → 212.92.41.142 connects, 0.43 s
212.92.41.143:5210 timeout
212.92.41.143:5209 timeout
212.92.41.142:5210 timeout

Same host behind both brand hostnames, so this won’t be IntesisHome-vs-AC Cloud
Control specific.

One difference from your report: my config entry did not end up in
setup_error. Setup completed — the entity kept its full hvac_modes and
supported_features 425 — and only the socket layer is retrying, so it should
heal by itself with no reload. Same versions as you, so I’d guess that’s
timing-dependent during startup; your reload automation is the safer bet anyway.

Last thing: nobody should wait for an official acknowledgement. HMS’s own status
page (Support → Cloud server status → Intesis) still reports AC Cloud:
OPERATIONAL with an empty incident history, 2.5 days in. It evidently tracks
the HTTPS portal, which is up, so a push-socket-only failure will never turn it
red. Which is a further argument for #50 — the HTTP path has been healthy
throughout.

4

I’m seeing the same thing and I have also logged a ticket. They replied yesterday saying that they had fixed the issue but unfortunately they hadn’t. You also mentioned:

But the mobile app isn’t working: it also relies on this same API path that is broken (at least on iOS).

Cheers,
Dom.

5

Still down :cry:

6

for me also

7

Seeing the same thing, the AC Cloud app (iPhone) is not able to control the unit nor my home assistant integration.
The Intesis web interface does still work for me, the AC Cloud will show updates made in the web interface or the local control terminal but is unable to make any changes itself.

The worst and most unreliable piece of technology in my house!

8

the new intesis update made the device available again but still I can’t issue any command…

9

Same issue here since a week. BTW: which new intesis update?

10
11

Any update on the effectiveness of 2.3.0 to solve this problem? I’ve installed it and the error from the Intesis integration ("Can’t connect to the server, or timeout, or something like that) goes away. But I can’t control any of the thermostats - the error is “Failed to perform the action climate/set_hvac_mode. IntesisHome did not acknowledge power on”.

Thanks in advance for any help …

12

it seems to be working now.. but going local is the permanent solution.
Does anyone now if switching to local mode is now fixed and does not wedge itself after a while?

13

The AC Cloud system works correctly via the PC/web interface: I can control the air conditioner normally.

However, the mobile app behaves differently. It receives and displays changes from the air conditioner (temperature, fan speed, operating mode, etc.), but I cannot actually control the unit from the app. The app appears to accept the command, but nothing happens on the air conditioner.

Home Assistant also cannot control the unit. The IntesisHome integration reports the following error:

Connection to 212.92.41.143:5210 failed: [Errno 110] Connect call failed ('212.92.41.143', 5210); auto-reconnect will retry

So, at the moment, control via the AC Cloud web interface works, the mobile app receives status updates but cannot send commands, and Home Assistant cannot connect to the IntesisHome push server. The 5210 connection issue is also currently being reported by other Home Assistant users.

14

the mobile app works on my side correctly. It didn’t work for 4 days but today it started working again

15

For me the AC Cloud app is still not able to control the unit, just showing status changes.
Home Assistant still dead in the water.
Only the web interface works.

16

I’ve read that their web API is read-only, but then I have to ask my silly question: how is it possible, then, if their web API is read-only that in fact I can exercise control to my AC unit using their website? Isn’t it my web browser, by loading a bunch of HTMLs, JavaScripts, CSS, etc that sends HTTPS traffic to their web server and this causes a control operation to my AC unit?
Couldn’t this be “simulated” using a Python script? Maybe capturing what does a web browser when sending a command would reveal what can be the correct way of exercising control via their web-based interface.

17

Here’s the login capture, removed my personal data for obvious reasons:

image
image606×135 11.1 KB

The received token is used in cookies afterwards thoughout all the session for all web requests.

And setting a temperature looks like this, from my web browser:

image
image686×481 22.8 KB

I think that completely avoiding the push socket is doable. I don’t say it’s easy, but should be doable, as a web browser ran locally on my computer is capable of doing. We should be able to make the same requests and use their web path. This will avoid future issues with their push socket and permanent connections, which for sure was not their intended use.

EDIT: I just tried a little bit more to understand what my browser does, and I find how my userId is determined, which is a parameter for setting values to my AC unit:

image
image967×515 52 KB

When loading the control panel after clicking “Control” on the main page after login, it shows the list of devices in my account and one of them with all its status is displayed. In vista we can find a set of JS functions, one of which is setUID. I think this is the gold we were looking for.

What’s your opinion? Is it something doable, are there any technical issue I didn’t found that makes the web interface read-only for PyIntesisHome?

18

Thanks jnimmo for pushing out a new version for IntesisHome (Config flow) on HACS.
This solved all the issues for me.

19

Just wanted to add something for other “noobs” like me who found this thread confusing.

I have Toshiba units, controlled through an IR transmitter (Intesis AC Cloud Control).

What wasn’t clear to me from this thread: the official/built-in IntesisHome integration in Home Assistant is the one that’s broken. What did work for me is a different, community-made version called jnimmo/hass-intesishome, which you install via HACS as a custom repository (GitHub - jnimmo/hass-intesishome: Experimental fork of the IntesisHome integration for Home Assistant · GitHub). After switching to that, my AC started working again through Home Assistant.

One thing to know if you also use an IR transmitter like me: it now beeps more often than before when sending commands — sounds like it’s sending the command more than once. It still works fine, the AC does what you ask, just don’t be alarmed by the extra beeping.

For reference, the official AC Cloud iOS app still doesn’t work for me either — it shows status updates but commands don’t get through.

Short version: official HA integration = still broken for me, official iOS app = still broken for me. The HACS fork by jnimmo = works, just beeps a bit more if you’re on IR hardware.

Thanks to @halbstill for the tip that got me looking in the right direction.