Levoit Air Purifiers Drivers

I have just finished getting drivers for the Levoit 200S and 400S air purifiers working. My first attempt at coding it up is located at: Hubitat/Drivers/Levoit at master · NiklasGustafsson/Hubitat (github.com).

I don't quite understand how to work with the package manager, so all there is is four files that you can copy into the driver code section and then set up everything. The Readme file will hopefully explain everything you need to know to get it working.

The drivers will only work with the "smart" Levoit purifiers, and they require that they have been set up with the VeSync mobile app, so that they are found in your VeSync account.

Start by copying all four drivers, then add a 'VeSync Integration' virtual device. It will setup a child device for each 400S purifier, and two for each 200S (one for the fan control, one for the night light).

13 Likes

Neat. I just checked the model number on mind. LV-PUR131S so not the right series.

If that model is WiFi-enabled and can be controlled with VeSync, there may be a similar driver that can be written for it.

From what I can tell, that's an older model, but it's WiFi, so it's worth using a tool like Postman to send some HTTP requests using the same logic that my drivers use to it and see what comes back. If you turn on logging in the integration driver, it should find your device in the account and acknowledge it, but then won't create a driver.

If you do try it with Postman, the state variables on the Levoit virtual device will have the informatio you need to authenticate. Once you log in, there will be an account id and a token. You need those in order to get a device list or issue any other requests.

I found Python code for the 131S here: pyvesync_v2/src/pyvesync_v2 at master · webdjoe/pyvesync_v2 (github.com)

It's apparently using the v1 protocol, but that should be compatible with the login and device listing commands, which are also v1.

BTW, I just found and fixed a bug related to coming out of sleep mode.

Thanks. Much appreciated.

Wow. Thanks for looking into this. I only purchased it less than a year ago off amazon. I did not research to see if it was the latest model.

It will be about a week before I try this. I am in the middle of a wiring project.

Wiring projects are the best! :slight_smile: Enjoy!

If you do get it working, please let me know. I'd love to incorporate it, but I don't have one of those units, so I can't test it myself.

1 Like

I just picked a 200S last night and was happy to see this out here. I went ahead and put in the driver codes, created a new virtual device with the VeSync Integration, put in my email address and password, but nothing populates for the 200S I have in VeSync. There is an error of 'Cannot invoke method getBytes() on null object on line 360 (method installed)' in the logs but no other error and looks to go through initializing and "login" in the logs as well. Any thoughts? --EDIT--It looks like that error in the logs occurs as soon as I create the VeSync Integration virtual device.

Hmm... a bug must have snuck in while I was cleaning up the code before putting it up on GH. I'll take a look right away.

EDIT:

I see some oddities in the code. It shouldn't be calling updated() from installed(), because at that point, you haven't put your credentials in yet, so the MD5 fails trying to hash the password.

Further, there should be a resyncEquipment command, but it's gone, I must have accidentally removed it when I was cleaning up the code.

Anyway, I pushed corrected source code to GH -- please overwrite the 'VeSync Integration' driver (the others are unchanged) and try again. You shouldn't have to start over, just provide your credentials again with Save Prefences, and then hit the 'Resync Equipment' button.

After 'Resync...', you should see something like this in the logs:

dev:5362021-10-26 07:32:47.300 debugsendBypassRequest([method:getPurifierStatus, source:APP])
dev:5362021-10-26 07:32:47.297 debugUpdating <<YOUR DEVICE CID>>
dev:5362021-10-26 07:32:46.482 debugsendBypassRequest([method:getPurifierStatus, source:APP])
dev:5362021-10-26 07:32:46.479 debugUpdating <<YOUR DEVICE CID>>
dev:5362021-10-26 07:32:46.473 debugDevice found: Core200S / Master Bedroom Air / <<YOUR MAC ADDRESS>>
dev:5362021-10-26 07:32:46.470 debugDevice found: Core400S / Living Room Air / <<YOUR MAC ADDRESS>>
dev:5362021-10-26 07:32:45.847 debugresyncEquipment()

Let me know if that helps.

I went ahead and threw a log write in there where it is struggling and it shows this for the digest variable: MD5 Message Digest from SUN,

Looks like it is looking for an integer?

Definitely getting closer! I was wondering where that button was :slight_smile: Now, I add the VeSync Integration virtual device and hitting the button I do see:
Device found: LAP-C201S-AUSR / Master Bedroom Air Purifier / DEVICE ID
but no other log and no device added.

Okay, so that device type (LAP-C201S-AUSR) is different from what I get for my 200S, so that's why it's not registering.

On line 238 in the integration driver, there is a line:

if (device.deviceType == "Core200S")

if you change that to:

if (device.deviceType == "Core200S" || device.deviceType == "LAP-C201S-AUSR")

it should at least try to register the device. I haven't been able to test on anything but my own devices, but if it has the same capabilities and service protocol, then it could work...

EDIT:

Seems like they may be the same device, just different versions: D1_01.01_M1_Core200S_Grey_2021-03-25_PRINT_US_en.pdf (accentuate.io)

Usage tip:

If you are automating the purifiers, most things can be handled by treating it as either a switch or a fan control. The one thing that you have to use a Rule Machine rule for is setting it to 'sleep' mode, which is what I do when the hub turns to 'Night' mode.

On the 200S, the night light device is manifested as a dimmer, but there are really only three levels: off, dim, on. If you set it up in a dashboard, or control it with an automation, the 'setLevel()' command will adjust the level to 0, 50, or 100, depending on what you set it to.

Thanks for this! I guess it makes sense that there would be more than one model in the "200s" series and I must have one. But, I went ahead and put that model into the driver and works great! Everything works how I think it should and putting the mode to sleep sends it to sleep and manual and speed work great! I only anticipate using sleep and high and not the light since it is in the master bedroom and I don't care for a shred of light in there. Great work!

Me neither! :slight_smile:

Glad that it works now!

GitHub source code has been updated.

Another usage tip:

The refresh interval controls how often the hub updates based on the actual state. Any state changes initiated from the hub will update immediately.

Thus, if your purifiers are mostly controlled via Hubitat, and not manually or via the VeSync app, the refresh interval can be high.

Nick,
Do you have a driver for the Classic 200S Humidifiers. I'm a newbie with writing drivers so I could use some help.
Thanks

Nope, because I don't have one to test with. My Groovy air purifier code is based on the Python code in https://github.com/webdjoe/pyvesync, which also has support for their humidifiers.

If you are familiar with Postman, that's the tool I used to test out the protocol between the service and the drivers. The login logic should be the same, so it's just the child device driver that should need implementation (except for the code in the parent driver that recognizes the model and creates the child devices).

I have updated the drivers to also recognize the 300S air purifier. I guess there's a 600S now, and it should be straight-forward to add that, too, but I don't have one to test with.

1 Like