Talking to a Philips Air Performer 7000 over local CoAP, and why it keeps going quiet

The Philips Air Performer 7000 (model AMF765/30) is a combined air purifier and fan. Out of the box it is controlled by the Air+ app and an infrared remote. We wanted to control it from Home Assistant and from scripts without going through Philips’ cloud. It works, but the device has habits that cost us an evening. Here is what we learned so you can skip that evening.

What the device exposes

• One open port: UDP 5683, CoAP. Every TCP port is closed. If your scanner reports the device as a “Shanghai MXCHIP” host, that is the Wi-Fi module vendor, not Philips. It is the same box.
• The protocol is encrypted CoAP, the same scheme the older Philips purifiers use. The aioairctrl package on PyPI implements it, and the kongo09/philips-airpurifier-coap Home Assistant integration builds on that. AMF765 is on the supported list.

The handshake

1. POST /sys/dev/sync with four random bytes as uppercase hex in the body. The device replies with a counter string.
2. Key and IV are derived from MD5("JiangPan" + counter), hex uppercased, split in half. AES-CBC.
3. GET /sys/dev/status returns the encrypted state document, about 63 fields.
4. POST /sys/dev/control with an encrypted {"state": {"desired": {...}}} body changes state.

We ended up using aioairctrl only for its EncryptionContext and doing the CoAP framing by hand in a short script, because the library’s own client hung against this device.

Quirk one: the status read needs the Observe option

A plain GET on /sys/dev/status is silently dropped. Not rejected, just no reply. We measured 0 replies out of 8 without the Observe option set, and 7 out of 8 with it. /sys/dev/info does not need Observe and is a good liveness check.

We initially blamed the CoAP token length and thought zero-length tokens were required. That was wrong, an artefact of the intermittency described next. Token length 0, 1, 2, 4 and 8 all behave the same.

Quirk two: it goes quiet, and polling makes it worse

Replies are intermittent even when your packets are perfect, and it gets worse the more you poll. Each Observe registration seems to stay live on the device and is never cancelled, so repeated polling saturates it. After heavy testing we had five consecutive failures that then recovered on their own. Sometimes it needs a power cycle.

This is a known Philips firmware bug, not a client bug. The kongo09 README says plainly that the integration “is rather instable” and “might stop working after a while” because of it. Do not spend your evening chasing it. Practical rules:

• Always retry. Never conclude the device is offline from a single timeout.
• Poll rarely. Once a minute is plenty.
• Use /sys/dev/info to check liveness, not the status endpoint.

The useful finding: writes still work when reads are stuck

The status and control endpoints are independent. With /sys/dev/status in its stuck state, POST /sys/dev/control still answered {"status": "success"}. So you can command the fan even while it refuses to report state. A control POST with an empty desired document is a valid no-op and a safe way to test the whole encrypt-and-send path without changing anything.

Field codes

These come from the integration’s const.py, cross-checked against a live dump from this unit.

Code	Meaning	Notes
D03102	power	0/1
D0310C	fan speed / preset	0 to 10, 17 = sleep, 18 = turbo
D0320F	oscillation	0/1
D03103	child lock	0/1
D03224	temperature	tenths of a degree C, so 215 is 21.5
D0310E	target temperature	not the measured reading
D03125	humidity	percent
D03221	PM2.5	micrograms per cubic metre
D0520D	prefilter life	hours
D0540E	NanoProtect filter life	hours

The trap is D0310E. It shows a plausible-looking “25” and is the target temperature, not the room temperature. The measured value is D03224.

Getting it into Home Assistant

Three routes, in order of how much we trust them:

1. kongo09/philips-airpurifier-coap via HACS. Fully local. Inherits the flakiness above, so expect the entity to go unavailable now and then.
2. The Air+ cloud path over MQTT, which is what the app uses. Far more reliable in our reading, but cloud-bound.
3. An IR blaster. The fan already has an IR remote, so a Broadlink or SwitchBot gives rock-solid one-way local control with no state feedback.

We are running option one and living with the gaps.