Levoit Binding

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.

1 Like

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!

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

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

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.

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

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.

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.

Hi @phui, Over the weekend I’ll try to get a build against 3.4.1 and upload a separate jar for it. Please snapshot your system / back it up if its a live system before installing! :slight_smile: As I would if testing on our primary system. In this case I will before posting to ensure the 3.4.X upgrade path is checked prior to pushing the jar out.I’ll send a message once I’ve build and confirmed the 3.4.X version.

@dagoodyear Thank you very much !!!

HI @phui, I managed to get it done while on lunch and tested here - had to download 3.4.1 to mirror your one. First I installed the normal one to setup the devices. Then download this one and added it to my addin’s directory and remove the installed binding form openhab official binding installs. Reboot and when it boots backup you should see a new device family under the device properties if it’s using the new version.

If you need to roll back I’d suggest restore the backup, otherwise what I did on this install was install the new binding. Shutdown openhab - delete from the addin’s folder and cleared the tmp and cache directories. On restarting it ran with the original binding (although you’ll still have that extra prop left against the devices).

P.S if pos could you confirm the current 200 one you have as well please.

@dagoodyear
Tried your new binding.
Remove the system binding, install and restart your new one via console.
The L450S was discovered immediately.

Thanks again for your great effort !!! :slight_smile:

Patrick

Hi @phui, Great thanks for the confirmation :slight_smile: Could you do me favor and confirm what that device reports under its things Properties for Device Name and Device Family. Additionally if at all pos could you confirm the same for the 200S, and that everything is working as expected for both that would be great evidence for the PR of the changes. Hopefully you don’t mind helping. Thanks in advance.

@dagoodyear
Here you go:

450S

  • Device Type: LUH-O451S-WUS
  • Device Family: Oasis Mist

200S

  • Device Type: Dual200S
  • Device Family: Dual 200S

Thank you @phui! :slight_smile:

I was assuming based on the above posts that the Oasis Mist would be supported, but it doesn’t look like mine works, likely because the device type is slightly different because of my location: LUH-O451S-WEU

So I’m getting “Device Model or Type not supported by this thing” unfortunately.

I also have a Cosori Air Fryer which is supported by pyvesync but not by the OpenHAB binding, any chance of getting that one supported as well?

Thanks!

Hi @sid3windr,

Regarding the Oasis Mist, I did some additions to add support for that. However I could only get the PR added to the 4.X builds, as only bug fixes go in older releases. In theory the 4.X snapshots or maybe even more now should support it based on the additions here:

The matching at the same point was updated to ensure that region code’s shouldn’t cause an issue. So in theory if you have a 4.X build the Mist :crossed_fingers: should work. That being said I also did do a build for the older 3.4x releases as I have not migrated myself from 3.4 so figured others may also still be on it. Details are in this thread, and somewhere a link to the 3.4X build in my repo that should include the mist support:

Please let me know if the 4.X build works for you or the custom build linked to on my github for the Mist - in theory it should. You may need to clear caches, and other-bits likely mentioned in this thread for it to pick up the custom module.

In theory it could support the other devices types, but I don’t have any of those to test with and am short of time currently. I will keep it in mind once I know I have a reasonable window of time to extend it, if no one else does first in the public repos.

Hopefully that helps - fingers crossed either the 4.X build kicks in with the mist, or the re-build of the same code against 3.4 I think it was linked to on my repo.