Add support for Levoit Eleva 300X Smart Air Purifier

[jordanenglish]

Device

• Product: Levoit Eleva 300X Smart Air Purifier
• Internal VeSync model code: unknown — happy to provide redacted API diagnostics if a maintainer specifies what's needed
• Region: US
• Product page: https://levoit.com/pages/eleva-300x
• VeSync store listing: https://us.vesync.com/product-detail/levoit-eleva-300x-smart-air-purifier-696

Current behavior

The Eleva 300X can be added to and controlled from the VeSync mobile app. However, pyvesync does not discover it, so Home Assistant's built-in VeSync integration creates no entities for it (no errors logged — the device is just silently absent). A second, older Levoit purifier (Vital 200S) on the same VeSync account is discovered and works correctly, confirming the account/integration setup itself is fine.

Expected behavior

pyvesync should discover the Eleva 300X and expose its supported air purifier features.

Notably, this model has a dual-filter design — a main HEPA filter and a separately replaceable Activated Carbon filter — with each filter's remaining life tracked independently in the VeSync app. Worth keeping in mind for the device implementation, since it differs from single-filter models like the Vital 200S.

I searched open and closed issues for "Eleva", "300X", and "Eleva 300X" and found no existing report.

I can provide redacted diagnostics or API responses if the maintainers specify what is needed.

[michaelkahn]

I have the same device and can add a model code plus some diagnostics from a second installation.

Retail model: LAP-C341S-WUSZ — read directly off the label on the base of my unit, not from
marketing copy. The same label carries FCC ID 2AB22-LAPC341S, which independently confirms the
LAPC341S model designator.

Levoit's own product page does not publish the model number; their launch release of 2026-08-28 gives
the same string ("The Levoit Eleva 300X Air Purifier (model LAP-C341S-WUSZ)…"), so the press release
and the hardware agree.

One caveat that still stands. This is the retail SKU, and a retail SKU is not necessarily the
internal deviceType string that device_map.py matches on. This library already carries a case in
point — the Core 600S is registered under both 'Core600S' and 'LAP-C601S-WUS', which is only
necessary because the API returns one form and the box says another. So LAP-C341S-WUSZ is now a
confirmed hardware model number, but whether it is the exact map key still wants checking against
the API. If it would help, I can pull the raw deviceType off my account and post it.

My unit:

• VeSync app device name: "Eleva 300X Office"
• Firmware: 1.0.21(1.0.34)
• Region: US
• Installed 2026-09-06, nine days after the model launched

What Home Assistant does with it — the device is dropped silently, with no log line.

Verified rather than inferred, on HA Core 2026.9.0 and re-checked on 2026.9.1. I reloaded the VeSync
config entry with pyvesync forced to debug, and:

• the config entry comes back "state": "loaded" — no error surfaces to the user
• the device registry still holds exactly one VeSync device, the Core 600S (LAP-C601S-WUS)
• integration_entities('vesync') returns the same 7 entities, all Core 600S
• system_log carries zero vesync entries

So from the user's side it looks like a successful setup that simply forgot one device. That silence
is arguably worth a log line on its own — an unrecognized deviceType reaching device_map could
warn rather than pass through quietly, which would have saved me the diagnosis.

(Aside for anyone reproducing this on HA 2026.9: /api/error_log is a 404 on that release, and the
404 body reads like an empty log. Use the websocket system_log/list instead. My first pass was
fooled by it.)

A hypothesis about the fix, offered as a hypothesis.

LAP-C341S-WUSZ is a LAP-C3xxS code, which puts it in the Core 300S family — already driven here
by VeSyncAirBypass for ['Core300S', 'LAP-C301S-WJP', 'LAP-C302S-WUSB', 'LAP-C301S-WAAA', 'LAP-C302S-WGC']. Adding the dev_type to that list would likely be enough to get the device
discovered.

I doubt it would be correct, though. The Eleva 300X has a dual-filter design — a main HEPA filter
and a separately replaceable carbon filter, and the VeSync app tracks their lifetimes independently.
A single filter_life sensor cannot represent that, so a one-line addition would probably produce a
device that appears to work while reporting one filter's life for two. I mention it in case the
discovery half is useful as a stopgap, not as a finished patch.

Happy to run whatever diagnostics would help — I have the hardware, and I can get at the raw API
responses.

---

Drafted with Claude Code, working against this Home Assistant instance's REST and websocket APIs — /api/states, /api/template, /api/config/config_entries/entry, and the websocket system_log/list.