Levoit 6000s - How can I help?

[Jyers]

First off thanks for putting this together, I use it on my vital 200s and it's amazing.

I have a levoit 6000s humidifier coming in the next two weeks. I have a feeling it's running an esp32 / similar protocol to their air-purifiers. I'm comfortable opening it up and doing some uart sleuthing to see what we're working with.

I have two questions:

1. If I can get you the uart info would you be able to implement it here or at least give me a bit of guidance. I'm fine working in c, but I haven't dealt with esphome components before.
2. What exactly would we need? Just monitor and record the uart signals sent to / from the esp chip when settings are changes from the app / from the display?

[tuct]

Hi,
A core6000s humidifier ;) or

I would need dumps from the communication, do you know how you can in archive this?
Record the UART communication between the esp and the MCU?

Best would be dumps with info on what you did (at least roughly).
set mode to auto (from app or device)
0x00 0x63 .... dumps of communication after this

Especially for the humidifer, as i don't know it at all!

[Jyers]

Sounds good! I'm plenty comfortable with recording the communication between the esp and the MCU. Once I get the humidifier (assuming FedEx didn't drop it off a cliff somewhere in the midwest) I'll gather a table as such trying to be as verbose as I can in what exactly I did:

Action	Dump
Set fan mode high from device	0x00 0x63 ...
Set fan mode high from app	0x00 0x65 ...
Set target humidity to 45% from app	0x00 0x68 ...
...	...

I checked the manual and it only has a couple extra functions on top of what you might see on the air purifiers (set humidity and dry mode).

I also assume there is some repeated status message that gets sent between the two devices? For the air purifiers this would contain things like the PM2.5 sensor readings, I'm assuming the humidifier will have something similar for humidity / water level. Is this something they typically send at intervals or would I need to trigger it in some way?

Thanks for being willing to help! I'll be excited to be the first person the cloud-cut the 6000s if we get it working😁

[Jyers]

The humidifier has arrived! I wasted no time getting it opened up. Long story short it's a pain in the neck compared to the air purifiers, but doable without any damage. As suspected it is ESP32 based (an ESP32-c3-Solo-1) I'll probably do a write up on how to get into it when I open it back up to flash it later.

One complication is the fact that in order for it to operate, it needs to be closed due to the water tank and pump being a separate unit. Plus with water being involved at all, probably safer to have all the electronics sealed up (although I'll note they took the time to coat the circuit board in a thin layer of clear coat to help protect from water exposure) Because of this, I opted to install an additional esp32 dev board into the unit to act as my sleuthing device. That way, I could just close the whole thing up and monitor the UART over wifi.

Luckily there was just enough room in the mainboard compartment to fit the dev board.

Now that it's all set and I can read the output I'll start putting together the table of commands!

[Jyers]

Here are my findings:
Levoit 6000s UART Protocol.xlsx

I'm fairly confident that encompasses all possible commands that can be triggered from the app.
I also believe I was able to determine all of the essential bits and their meanings from the status messages.

The one thing I failed to figure out was how the ESP device gets information on the timer status (ie time remaining, etc)? I assume it would be fairly similar to the air purifiers. Do you know if that is something the ESP handles internally or if I maybe missed an additional status message from the MCU? Let me know your thoughts and if there is anything else you'd like me to parse out from my device.

[Jyers]

After a little more checking it seems like the ESP chip does handle the timer. Every 30 seconds or so it sends a the same command as the initial timer-set command to the MCU with an updated time remaining. @tuct let me know if this seems consistent with how the other devices handle timers.

Update: Funnily enough, after a little more testing, I've found that when setting the timer from the display, the MCU sends one of the old timer status updates (same as the vital series it seems) to set the time on the ESP. From there the esp just sends its status updates at an interval. I've updated the commands spreadsheet to include these findings.

[Jyers]

I got a little excited and had a go at getting this working. I ended up doing some other refactoring / modification to get both my vital 200s and superior 6000s working just the way I wanted. If you want to have a look at the way I implemented anything it's all here: Jyers/levoit-esphome

Overall, I'm quite happy with how it turned out. It surprised me to find that the vital seems to have had the filter managed by the ESP (hence your custom filter life implementation) while the superior has the MCU to track it. The last thing I would really like for the vital is to figure out what command is needed to turn on the "filter needs changing" light, as that is really the only thing that doesn't get handled right now. That command is annoying though since you would have to let the filter run all the way out on the stock firmware and be logging right as it runs out.

Anyway, for now I have the internal ESP on the 6000s disabled and my dev board acting as the main ESP control. I'll leave it like that for a while in case either of us think of any additional details worth getting off the stock firmware. Otherwise, I'll probably open it up again in a week or two and flash the real chip ( after backing up the stock firmware of course :) )

[tuct]

Cool,
Will check out in Detail soon.
Do you remember what you changed for the vital200s?

[Jyers]

For the vital I mostly changed QoL things:

• Made sure everything had default icons
• Set the state class to make sure statistics worked
• Changed around some device classes to make binary sensor outputs more meaningful (For example making filter low into type "problem" so instead of being ON or OFF, it's PROBLEM or OK.

The only functionality change I made was that I noticed the wifi LED command weren't implemented so I grabbed the ones from https://github.com/targor/levoit_vital/ and now that is working properly.