Levoit Binding

Add-ons Bindings
, , ,
42

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

43

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
Polling

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

44

@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.

45

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

Screenshot_20220223-204833 - Copy
Screenshot_20220223-204833 - Copy1080×2400 61.7 KB

46

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

47

Sounds great ! I’m on openhab 3.2

48

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? )

49

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

Thank you !!

50

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
51

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:

52

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:

53

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.

54

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.

1 Like
55

I purchased a humidifier with an IR remote so that I could control it with my Harmony Hub, but came across the Vesync binding and decided to try a Levoit 600S instead. Everything works perfectly on it. The Levoit cost more than the other humidifier, but it’s worth it for the WiFi control.

The only downside is the delay in sending commands, but I’m guessing that’s a limitation of pyvesync.

Thanks to @dagoodyear and everyone else who contributed to this project!

56

Posting for everyone in this thread if anyone can help verify that would be great thanks (especially those with humidifiers).

57

@rpwong You’re welcome glad to see it’s being used. Normally sending commands is instant - at least on our connection. It does use threading based on the model’s expected, so possibly something else could be hogging the threads. May be worth bumping them up - if you search on the forums there will be links somewhere. Read-back can be delayed, to show the new state to ensure reasonable interactions with their server’s but if it is sending commands its likely the thread pool’s loaded up or maybe devices other than the Air Purifiers I have are slower although I would have thought it would all have common H/W.

58

I actually ended up returning the Levoit, or else I would have tested your update. The humidity sensor was flaky, but that’s been the case with every humidifier I’ve tried.

The bigger factor was that an Amazon seller refunded me for another humidifier I had purchased (after reading my Amazon review), without requiring me to return it. Even though the Levoit is better, I couldn’t justify keeping it after that.

59

Hi there,

Thanks a for the binding.
I have a Levoit 200S and it works well.
Currently purchased a 450S from Amazon, connect successful from the app, but can’t be discover from openhab.
Anyone have any idea?
Thanks.

Patrick

60

Hi @phui, which version of openhab are you using. There’s a PR open for a set of changes to improve the support of device detection after I saw a message on my old github repo, but currently its built against version 4.0. If possible could you try manually installing this in a version 4 install if your not running it, to see if it works as expected. If not could you install v4 separately and test? (Im guessing this device is on the same account as the 200S). (Really we need test evidence to push the PR through). The link to the testing thread for that version is: VeSync / Levoit Binding Help Testing Requested. To install remove the binding downloaded normally and then install the jar from that thread. I was looking at the pyvesync code I cant see a 450S model there. From a quick search it looks like its the Oasis Mist, the build linked has potentially the correct identification code, to find that device, although not verified at the moment. I would hope it finds it - if not we can figure it out from traces I would expect, and get it going and added to that PR.

61

My openhab version is 3.4.1.
Tried the v4 on 3.4.1 and it has the following error and can’t go live:

361 │ Installed │ 80 │ 4.0.0.202302062148 │ openHAB Add-ons :: Bundles :: VeSync Binding
openhab> bundle:start 361
Error executing command: Error executing command on bundles:
Error starting bundle 361: Could not resolve module: org.openhab.binding.vesync [361]
Unresolved requirement: Import-Package: com.google.gson; version=“[2.9.0,3.0.0)”

if it can’t work on 3.4.1, I need to find a spare machine or config a VM to test the v4 as I’m afraid that if anything goes wrong, I can’t go back if I just upgrade my production machine.
Thanks.