Philips Air Purifier

I previously tried installing pycrypto:

$ pip install pycrypto
Looking in indexes:,
Requirement already satisfied: pycrypto in ./lib/python3.7/site-packages (2.6.1)

but when starting homeassistant it reports

2019-12-15 18:05:28 ERROR (MainThread) [homeassistant.components.homeassistant] Platform error - No module named 'Crypto.Util.Padding

Perhaps you have not installed it in the right environment, as in my case I had to switch to the homeassistent user and the virtual environment /srv/homeassistant

What distribution do you have? Docker / Hassio / Raspbian?

originally had the following error but can recreate by going into the virtual environment and use pip uninstall pycrpto

2019-12-15 18:23:37 ERROR (SyncWorker_17) [homeassistant.util.package] Unable to install package pycrypto: ERROR: Could not find a version that satisfies the requirement pycrypto==1000000000.0.0 (from -c /srv/ha/lib/python3.7/site-packages/homeassistant/package_constraints.txt (line 36)) (from versions: 2.0.1, 2.1.0, 2.2, 2.3, 2.4, 2.4.1, 2.5, 2.6, 2.6.1)
ERROR: No matching distribution found for pycrypto==1000000000.0.0 (from -c /srv/ha/lib/python3.7/site-packages/homeassistant/package_constraints.txt (line 36))
2019-12-15 18:23:40 ERROR (MainThread) [homeassistant.components.homeassistant] Platform error - Requirements for philips-airpurifier not found: ['pycrypto'].

if I do re-run the pip install pycrpto it returns with the Module error.

I’m using Raspbian buster

1 Like

I got it to work! :grinning:

I uninstalled pycrypto and then edited the requirements to be pycryptodome (which is a more up to date forked version of pycrypto that appears to include the Crypto.Util.Padding module) in the philips_airpurifier/manifest.json file (see below), When the home assistant is stopped I deleted the philips_airpurifier/__pycache__ directory too. When restarted I now have access to the air purifier!

  "domain": "philips-airpurifier",
  "name": "Philips AirPurifier",
  "documentation": "",
  "dependencies": [],
  "codeowners": ["@xMrVizzy"],
  "requirements": ["pycryptodome"]
1 Like

I have mostly the same stacktace but “ConnectionRefusedError: [Errno 61] Connection refused” in the end.
And yes, I had issues with crypto but solved it as described by @alander.
It sound to me that my version of device (3829/50 purifier + humidifier) has ports closed. attempts to send something like from Postman gets responds as “Could not get any response”… rechecked correctness of ip triple time. its ping-able as well.
Side notes - i have it fully functional in Air Matters app on iOS. So my question is: should I remove it from Air Matters app to be able to use it with hass? Or probably the heaven is over and dark side swallowed Philips and they closed access to hw?

Only guessing here :slight_smile: but have you tried viewing on another device/pc/mac/mobile via browser, assuming there is no outbound firewall/antivirus web scanning preventing connection?

Are you sure you have the right IP there? If the app can communicate with it, it must be listening on port 80. The app doesn’t work via the cloud, it has to be on the same network as the device. I can definitely use both the app and the hass integration to control the device at the same time, so no uninstallation needed.

well - just tried this url from my iphone from regular safari browser- just nothing… ( bummer.

@inso22 thanks for point. rechecked ip. its correct (. as for port 80 - i would not be so sure about it - there is no any “must” on port to use - vendor can use any port for communication…

Yes, I know that. But in this case Philips is clearly using port 80 as it works for everybody else.

out of interest how did you verify the IP address the purifier had? I reserved the only device that had a Philips manufacturer MAC address in the DHCP setup of the router/service (not the purifier) to ensure it always got that address.

possibly it is not the case anymore (availability of port 80) with recent hw/sw iteration of Philips purifier (mine is very fresh - just unboxed several days ago). Per this the guy who has initially discovered the hack, participates in Philips coordinated vulnerability disclosure program, so he sends any his new findings to them first… And per my paranoia :wink: Philips treated such usage of theirs device as “vulnerability” and just “fixed” it…

well - maybe my method of ip identification is relic and kinda not fancy but i have UniFi Nano as access point, so have a lot of information about each device in my wifi network. this one is the only new with hostname “MiCO” and if i unplug Philips physically from power, MiCO disappears from list of wifi devices in UniFi Network…

strange, on mine it registers with no name, not sure where the MiCO hostname comes from?

actually I would be happy to know the way to identify its mac address ) - then I would be 100% sure i use correct ip )))

are you able to see the DHCP leases with their IP addresses and MAC addresses? Then it’s the first 3 sets in the MAC address that show the manufacturer. Mine also has a network overview that does this decoding automatically

My AC3829/60 purifier show as : e8:c1:d7

Also on the android version of AirMatters app there is an email diagnostics option (you don’t have to send the email to read the output) and the line EUI64 has the MAC address sets (but additional bits) but check the first 6 digits with the last 6 digits against yours. I don’t know whether this is consistent everywhere but it’s worth a try.

Ditto, same MAC prefix. I just port scanned mine, and port 80 is the only one shown as open. Maybe with newer firmwares they changed this – @sergeymaysak could you run a port scan against yours?

Btw I have a similar issue but on an AC1214. I have a slightly different mac address prefix though (B0:F8:93) but MiCO hostname matches for me as well. I did a quick capture in the android app and it is communicating towards the MiCO ip address but in my case it is only communicating via udp on port 5683. All TCP ports seems to be closed when I try scanning all 65535 port with nmap. Also from what I can see from udp scanning with nmap only 5683 gives an “open” result, everything else gives state “open|filtered”. Unfortunately I can’t really say anything else so far, the captured data is just empty udp messages it seems so not sure how the communication works.

Edit: After some more packet capturing it seems 5683 is the coap protocal and it seems like it is communicating using coap also. Specifically when I first log on it requests the url coap://IPADDR/sys/dev/status. I tried some different coap clients ( but I cannot get an answer when I try manually it seems.

Hello! I just bought an air purifier too, sadly not the mentioned ones but an AC3858/50. Of course it doesn’t work with the hassio module I found here. In the log it said to me connection refused too, so I hoped it will be enough to change the port and it will work, but no. Here’s the result of a nmap:

Nmap scan report for 192.168.x.x
Host is up (0.0013s latency).
Not shown: 65526 closed ports
2578/tcp  filtered unknown
10837/tcp filtered unknown
12353/tcp filtered unknown
21612/tcp filtered unknown
41165/tcp filtered unknown
47619/tcp filtered unknown
53972/tcp filtered unknown
54541/tcp filtered unknown
58090/tcp filtered unknown
MAC Address: B0:F8:93:xx:xx:xx (Unknown)

There’s no TCP port open. I hoped they just changed to UDP so I’ve tried to disable internet access of the purifier, then restart it. It connected back to my wifi but the app doesn’t see it anymore. It makes me sad, Philips has done a bad work. It’s not enough I can’t set a static IP for it only DHCP, I can’t use it over LAN, only with the cloud. I’m really disappointed. I’ve tried to contact the local philips before I bought it but they didn’t even answer yet, they wrote an automatic message they will in 2 working days and it was a week ago.

so looks like that it has to be the right model number as each purifier by Philips uses a different interface :frowning: hopefully someone can write an integration for those