Coway Air Purifier Gets a Local Home Assistant Integration, Tested on One Model

Scott J. Goldman published a teardown on November 11 that moves a Coway Airmega IconS air purifier off Coway's cloud and onto a broker running in his own Home Assistant. The code he built from it is MIT-licensed, experimental, and confirmed on one model.

Goldman wrote that the existing Home Assistant integration depended on Coway's cloud, which broke often and left him "at the mercy (or lack thereof) of the Coway cloud service." That older integration is home-assistant-iocare, which his post names.

How the fan talks to the cloud

In normal operation the purifier speaks MQTT over TLS on port 8883 to AWS IoT. Setup happens over Bluetooth: the fan exposes readable and writable characteristics, and the Wi-Fi details travel in an encrypted payload. During setup it fetches a root certificate authority file over plain HTTP, then asks for a device certificate and its MQTT configuration over HTTPS.

Two details made the bypass possible, according to Goldman's post. The CA download is unencrypted, so it can be intercepted without exploiting the eMudhra certificate issue he mentions in the post. And the Bluetooth payload carries the URLs of the certificate server, which the person doing the setup supplies. Point those at a local server, run a local MQTT broker, and the cloud is no longer part of daily operation.

The Terminal has reported on certificate trouble involving eMudhra in Samsung's Smart Hub, a different product, and the post does not link the two cases.

What the repository does and does not support

The repo's README is blunt about scope. Only the Coway AP-1022K has been tested, on a single unit with particular microcontroller and Wi-Fi firmware. Other models may pass Bluetooth discovery but are not known to work. The post names the IconS and the README names the AP-1022K, and neither page says whether they are the same unit.

Requirement	What the README says
Home Assistant	Core 2026.10.2 or newer
Setup browser	Chrome on macOS or Android; not Safari or iPhone browsers
Wi-Fi band	2.4 GHz
Default ports	8080, 9443 and 9883

Supported controls include power, three manual speeds, smart and sleep modes, lighting, the timer and the pre-filter cleaning cycle, plus PM2.5, ambient light and filter-remaining sensors. It lacks PM10, filter notification flags and firmware updates. The light sensor scaling is uncalibrated, and filter percentages have not been compared with Coway's app.

The friction, and the security notes

Setup is the sticking point. A static page on GitHub Pages uses Web Bluetooth to send the Wi-Fi details and the Home Assistant address to the fan, which is why Safari is out. The README says the Wi-Fi password goes from the browser to the fan and is never received or stored by Home Assistant, and that setup links expire after 15 minutes and work for one fan only.

Using it also ends the Coway app: the README says the integration "disconnects your fan from the Coway cloud," so the app stops controlling that fan. Changing the Home Assistant address or ports means setting up each fan again.

The README's own security notes list the costs. Home Assistant's traffic here stays on plain HTTP, the fan downloads the CA certificate over plain HTTP, and the MQTT link requires TLS 1.2 with AES128-SHA256, which the README calls a fairly dated cipher suite. Certificates and private keys sit in /config/.storage/coway_local/, so backups of that folder are sensitive, and the three ports should never be forwarded from the internet.

Goldman also wrote that an AI assistant helped analyse captures, decompile the Android app and write the provisioning script, and that Claude declined one networking request in the "cyber" category while ChatGPT completed it. Agent-assisted tooling is drawing attention elsewhere on GitHub too, as with Chrome's Modern Web Guidance skills. The coway-local repo had 9 stars, no forks and 30 commits when The Terminal read it on November 13, and the README says the project is not affiliated with Coway or Home Assistant.