Philips compatibility

[ciotorcristian]

Hi,

Could you please confirm if this would be compatible with AC3059/51. I believe the insights are not so different that the ones you mentioned.

Thanks

[tuct]

Hi,
Most likely they use a very similar protocol, but based on the images, those devices have more buttons and LEDs on the device.
Tldr: We would first need to open the device and simply sniff uart protocol between mcu and esp32 and create a dump.
This would allow me to check a) if it works or b) if it needs adoption.

I have a section on how to sniff create a uart dump.

[tuct]

Here is the UART dump info: https://github.com/tuct/levoit/blob/main/README.md#capturing-a-uart-dump

Main issue is that I expect those devices to have a different mainboard, so it would be required to first identify the UART pins and also how to pull en to gnd for the existing esp32 (I usually don't flash the original ESP, but add a new one, so I can easy revert if i want).

This is the "Philips Dual Scan Series 3000i", right?

Could you share some images of the PCB for the 3000i?

[tuct]

https://www.sparemaster.in/product-page/philips-air-purifier-pcba-mars-ac3059-65
PCB for the india version,... issue is that it seems they do not use an esp32, but i also don't see another wifi antenna /chip... so not 100% sure if this is the wifi versionof india.

[tuct]

Bad news:
According to hardware teardowns and MAC address logs analyzed on the Home Assistant Community, Philips smart air purifiers—including the AC3059 3000i Series—utilize a Wi-Fi IoT module manufactured by MXCHIP. [1] (https://community.home-assistant.io/t/philips-air-purifier/53030/315), [2] (https://github.com/kongo09/philips-airpurifier-coap)The Chip Vendor: Devices in this family feature network hostnames reporting as mxchip and MAC address blocks starting with B0:F8:93, which maps directly to Shanghai MXCHIP Information Technology. [1] (https://community.home-assistant.io/t/philips-air-purifier/53030?page=15)The Architecture: Instead of using Espressif's ESP32 Xtensa framework, MXCHIP modules typically run on ARM Cortex-M microcontrollers (like STMicroelectronics STM32 or Cypress architectures) running MiCO OS or custom firmware.Firmware Protocol: The Wi-Fi subsystem on the AC3059 runs an encrypted local CoAP (Constrained Application Protocol) layer, with internal software signatures reporting to network brokers under strings like AWS_Philips_AIR@62.1. [1] (https://github.com/ruaan-deysel/ha-philips-airpurifier), [2] (https://github.com/kongo09/philips-airpurifier-coap)Because it lacks an ESP32 (or similar ESP8266), it cannot be flashed directly with ESPHome or Tasmota firmware via standard means. However, because it exposes local CoAP communication over port 5683, you don't actually need to replace the chip or modify the PCB to take local control of it. You can seamlessly integrate it into open-source smart home setups using the custom

Good news, there seems to be a project already here:
https://github.com/ruaan-deysel/ha-philips-airpurifier
not fully stable as it seems, but working.

P.S: it looks like we might still be able to esp32ify those, if the MXCHIP also just communicates via uart with another MCU.

Would need to check this and then figure out how to safely disable the MXCHIP...

[tuct]

added info about other project here:
https://github.com/tuct/levoit#cloud-free-without-esphome--philips--versuni-over-local-coap

[tuct]

and maybe this could work:
Open question — can the MXCHIP models run ESPHome after all?

[tuct]

Not done, but i got an AC951 (Series 900) and it also uses a MXCHIP,
Working on replacing this with an ESP32, and it looks very good so far!, see: https://github.com/tuct/levoit/tree/main/devices/philips-900-series

I could access the PCB only by turning the round top part firmly to the left (counterclockwise).
Maybe it is the same for the higher series, if you could try. it requires quite some force but DON'T break it´, not too much!