Levoit Binding

Hi David, thanks for this binding.
I have a Levoit 200S. Have binding installed and working but having some trouble setting mist level. 200S has only auto(and manual) + low and high modes. Watching log, when changing mode from app, low mode sets mist level to ‘1’ and high mode sets mist level to ‘2’.
When I send command through openhab ui widget to change mist level to 2, command seems to change itself back to 1 almost straight away and no change of speed on humidifier itself.

Maybe I am doing something wrong here, can you advise? log: ==> /var/log/openhab/events.log <==2022-02-22 19:24:43.780 [INFO ] [openhab.ev - Pastebin.com

Thank you

Hi @nexuswave,

There’s a few key’s bits that would be great to speed up cross referencing the other codebase.

There are three key bits to the binding:

Device Identification
Sending Commands

Firstly this is for a 200S humidifier - is that correct? - just to make sure as I thought I saw D301S in your traces but maybe they re-use the modules or something.

Then in this pastebin, are example messages for each of the three key bits for our air filters.

Could you provide most importantly from the logs the Device Identification related bits. It’s really key for me to cross check the codes.

Next when you send a command hopefully :crossed_fingers: you should see a command being sent as given in the example - note is very similar to the polling. If you do please also show that and the response code.

From your pastebin and info it look’s like polling is working.

At the moment I have a slight issue that my son has my primary computer (to keep him entertained) while isolating with Covid :frowning:, but I’ll try to use it remotely once he’s hopefully asleep to look through. If you can provide the device identification traces like in my pastebin that would be great, and if you do get anything from sending commands those would be useful see.

Many thanks in advance

@nexuswave, Sorry I read read now after reading through the code.

P.S I don’t think anyone has tried that model until now - so it likely need’s a few bits of tuning.

(The device discovery information would be good to know - so I can pin down which precise model this is just in case its different to what I suspect).

So for our air purifiers we have a fan level and the modes auto, manual, and sleep.

In the app it shows → auto,1,2,3,4,sleep (from memory).

I’m guessing in for your air humidifiers it possibly shows as auto → low → high in the app?

If I set the fan speed on a air purifier when the mode is not manual it does not change. The mode has to be set to manual first then the fan speed changes (the binding does it for the air purifiers).

Could you please change the device to manual mode in the app, then first select mist level one and capture the poll response, and then do the same for the other mist-level’s, so the mappings can be confirmed please*

Also what is the name of the channel you are using mistLevel?

Based on your poll captures, this will confirm the mist-level mappings, and if they possibly vary for that device, in which case I can remap it for that model.

I’m assuming power on / off and other commands are working when you attempt to set them?

The reason it switches back like you have seen, is because its tried to send the command, then it checks to confirm the value changed, and as it hasn’t it will flip back.

Sure, thanks for the help. It was listed as Dual 200S model on Amazon when I purchased https://www.amazon.co.uk/LEVOIT-Humidifiers-Humidifier-Operation-Essential/dp/B09KT9ZK7Q/ , but checking the model sticker on the device itself, it does list it as a 301S.

And yes all other functions are working from open hab, power on/off, switching auto / manual mode etc.

Just not mist level as you mentioned. (And yes using mistLevel as channel. )

And yes options in my phone app are auto → low → high

New pastebin linked. I have logging set to trace, but could not see any additional info on methods as in example. 2022-02-23 20:13:36.225 [TRACE] [nternal.handlers.VeSyncBridgeHandler] - Scannin - Pastebin.com

Thanks @nexuswave, Okay so its technically a Dual200S reporting as LUH-D301S-WEU (that’s good to know thanks :slight_smile: I wouldn’t have guessed that mapping).

Okay so from the log’s I’ll adjust:

  1. The binding to switch to manual mode first, then set the mist level. (As obviously it needs manual mode prior to commanding the mist level - the screenshot really helps context thanks).

I’ll do another build for you to use, with a bit more debug, so we can try all values between 1-9 (I would guess the value 1 represents Low, the question is which number when entered switches it to High in the app).

Once we know I can remap the value 2 to it, for that model.

Can you advise which version of OpenHab your on please - 3.2 or 3.3?

Thanks again

Sounds great ! I’m on openhab 3.2

Hi @nexuswave,

I’ve temporary pushed a build here for 3.2, so now you can try setting the mist level between 1-9. After you set each one, it will bounce back to the current value, then try the next. When you find one that changes the app to high, the mistLevel should bounce to the value 2.

If its running this new version when you set the mist level there should be some debug messages, with the text CROSS-CHECK: . If they don’t appear and on windows you may need to stop openhab / clear the cache and restart. (I haven’t seen Linux have the same need).

I suspect have it will be either 2 / 5 / 9, but :crossed_fingers: one of the numbers between 1-9 toggle it.

Please let me know hopefully the magic number for the High Speed :slight_smile:

Thanks again.

(P.S I crossed checked to make sure - it looks like pyvesync is using that same command, so hopefully one of those numbers does work :crossed_fingers: ). Alternatively if you have an android phone I think you can pull the log’s from the app, and if you can find the setVirtualLevel command when you set it to high we can use that to provide the mapping? )

2 is the magic number :grinning: It sets the device to high and the app reports high also.

Thank you !!

Okay great thanks :slight_smile: I’ll map in a different mapping for that device, I never got why all the other models
used took a weird bitwise style number instead of 1,2,3. Or more simply remove the remapping for that one :slight_smile: Hopefully newer models with the LUH model prefix all work like this :crossed_fingers: Thanks for testing :+1: I’ll ping you a link with the final build if you wouldn’t mind giving it a shot before I push in into the PR, and my copy of the code?

1 Like

Hi @nexuswave,

If you could just cross check this one it should only allow the numbers 1 and 2 to be sent for that device, and obviously still work unless I made a silly mistake. If you could :+1: its all good that would be great and then I’ll quickly put the modifications in to the PR, and source code copies.

Thanks for the help - another device I can add to the tested list :slight_smile:

Tried this build and works as expected, tried sending some random values for mistLevel greater than 2 and some less than 1 and it gave warning in log e.g ‘adjusting to 2 as the valid API value’ and adjusted to either high or low mode depending. :+1:

HI @nexuswave,

That’s great - thanks so much for cross checking. I did cross check the code quite a few times and pushed in it the expectation / hope that you give that answer :slight_smile: Many thanks for the time / help getting that one tuned up and confirmed :+1: One more model in the confirmed list now.

This binding is now in the openhab addon’s so should appear soon as part of the normal distributions. Please use the official version now, rather than anything linked in the previous posts. Many thanks in advance.