VeSync / Levoit Binding Help Testing Requested

Hi all,

For any current readers:

Version 4 now has this merged to the main repo so it will be included in the snapshot builds, or builds after Milestone 1 I guess. Currently 3.4.x appears to be only accepting bug fixes. For those like me who need some time to migrate to v4 while testing everything, I have uploaded the source and build against the 3.4.x snapshots here in my github repo.

Anyone using the VeSync binding. After seeing a comment raised against the original repo, I can see that it needed updates to compensate for the new way some devices are presented, and the reference library I was working from has also been updated. The code base has been adjusted to identify devices into groupings called families. I am looking for assistance from anyone using if you could spare a few mins and install v4 and try the test build here please linked removed.

The Air Purifiers I believe are fine as everything maps directly over nicely, and it should just add support for new models.

On porting the humidifiers, there are a few minor differences. So anyone using humidifiers if you could connect a v4 install using this build and verify everything that worked before still works as expected that would be great thanks.

Any thing verified if you could report it back to this thread please, or observations that would be great thanks. I’ll be hoping to use this for the MR for evidence the build has been verified.

(Note I’ll update the documentation files as a last step - to save multiple rework efforts on them).

Thanks to all and anyone who can assist with verifying the build.

(P.S Once the build is verified, and merged I’ll try to get a backport in of the changes).

Thanks again

  • I have tested and confirmed the Air Purifier Core 400S with the DeviceType from the devices properties of: Core400S (along with upgrade of snapshot 4.0 setup / then upgrade to use new build, and removal of snapshot build - no issues).
  • Rich Koshak has tested and confirmed the Air Humidifier 600S with the DeviceType from the devices properties of: LUH-A602S-WUS (Many thanks!)
  • Patrick has tested and confirmed on a 3.4 build the Air Humidifier 200S with the DeviceType from the properties of: Dual200S
  • Patrick has tested and confirmed on a 3.4 build the Air Humidifier Oasis Mist with the DeviceType from the properties of: LUH-O451S-WUS

For reference the MR currently open and awaiting review is: [veSync] Updates to improve recognition and support of devices by dag81 · Pull Request #14354 · openhab/openhab-addons · GitHub

I have a Levoit LV600S humidifier.

Do I need to delete the old Things and recreate them after removing the add-on and dropping the jar file into add-ons or do the Things remain the same? I’m already running on OH 4 snapshots.

1 Like

Apologies for the delay, works been manic. In term’s of the changes, they don’t change channels and a new property against the devices should be added automatically called device family from memory. Therefore it should be fine with an existing installation. If pos, I’d suggest testing on a separate OpenHab install first for safety if pos (just as thats what I would do), as a quick validation prior to using with an existing setup to ensure all the channels you use are reading and writing as expected.

Many thanks for helping - it’s hard coding just agains the spec’s with only one of the many devices available :slight_smile:

No it’s my turn to apologize for the delay. Most of my OH time has been spent testing other snapshot issues.

Anyway, I installed the add-on and preliminary set of tests appear to work. I can change the setpoint, mode, heating, screen, etc. I’d say it works for my device at least.

The only think that I’ve not seen come across yet is a new humidity reading. I’ll come and update if that never happens. :wink: I just got a reading. All the stuff I’m using at least is working.

Many thanks for verifying @rlkoshak. Can you just confirm for my reference what the devices properties gives for the DeviceType as this confirms the precise model the binding has re-cognised. I would expect :crossed_fingers: that its one of these:
‘LUH-A602S-WUSR’, ‘LUH-A602S-WUS’, ‘LUH-A602S-WEUR’, ‘LUH-A602S-WEU’, ‘LUH-A602S-WJP’.Thanks again! :+1:

Hi @lyo125, I hope you don’t mind the directed message. Any chance you could please help to validate the changes to the Levoit / VeSync binding against your Humidifier 300s please? If there’s any chance you could install the openhab snapshot 4 and use the binding in the link above, to confirm it works as expected it would really help. Just trying to gather evidence, the PR is ready to go. (Your active installation doesn’t need to be used - just a check everything you use is running as previously). Hopefully that’s ok many thanks in advance.

HI @nexuswave, I’m looking to get test coverage on changes for v4 of OpenHab that will be back-ported for the Levoit / VeSync binding. Is there any chance you could download the v4 snapshot of openhab, (on a separate system), and just check the linked build please, works as previously / expected for your 200S Humidifier. Just trying to get test coverage for the PR. Hopefully that’s ok - many thanks in advance.

1 Like


1 Like

Just linking to other post with test results in of Oasis Mist and Dual 200S: Levoit Binding - #67 by phui

1 Like

For any readers thanks for all the testing, and the team reviewing the GitHub OpenHab Addon’s.The version 4 branch has the changes merged in so I would imagine will be included with the next builds. I’ll start on the 3.4.x back-port now and post again once that PR has been processed through.


@dagoodyear Well I’ve been out of commission for a couple of months as well, guess everyone was pretty busy this year :slight_smile: (and I have a couple hundred of messages to read on this community alone! Wow!) nice to make your acquaintance though :slight_smile:

I’ve been playing with a levoit 400s on an openHAB 3.3 installation. Is there anything I can help test on my setup?
The binding install and the bridge config was flawless and channels auto discovered. The basic working functions are working fine (on/off, change mode, sensors reporting correctly.)

Related to the fan speed:
I added a stand-alone widget to that “manual fan speed”, defined the values 1,2,3,4 and now I can easily control the fan speed directly from the item - but I’m wondering if it would be possible to be set automatically so that when we create the item, since we already know that it needs a widget to be controlled, to have it done so at the creation of the item? - maybe not but figured I could ask.

(Removed the part about the google home integration because I found a fix.)

About the sensors, the binding is reporting both the quantity and the aqi value. It’s really great to convert them to whatever we need.

About the auto off, my channel is stuck in null. I set a bunch of 10 minute timers, but the channel didn’t update ever. I’ll do some more tests to see if i missed something however, perhaps it needs bigger timers…?

Let me know if I can test anything in particular, I’d be happy to help.

Confirmed, the auto off time is stuck on null, as well as the config: room size.

Small update, I don’t think the channel “air quality” is receiving data properly. I have one data point there. Meanwhile the air quality ppm2.5 has several hours of data points.

This is becoming more interesting by the day, I might have to experiment a bit more. So long story short, I’m no longer getting any aqi data. But, my overall air quality is changing between 1 and 6. I wonder if no data is being sent because the aqi is stable? Anyone has any hints?
Figured that maybe my pihole was blocking stuff but no, all of Vesync communication is going through. I might put the air purifier behind an exhaust to see whether I get data :smiley:

Used an aerosol can to decrease the quality of the air around the air purifier. Set the Vesync gateway to sync data every 30 seconds. Spent about 3 minutes fuming the bedroom with the crappy aerosol can (WAF out the window). Can now confirm that even when the air quality is shot (over 100 aqi) that no data is sent to the binding. @dagoodyear im now wondering if this is because I’m using the 3.3 build??
And overall that’s it. Was an exciting week. If there’s anything else with which I may help just ping me or tag me and I’ll happily assist.

Hi @Pedro_Liberal, I was just reading through your comments. Ironically the 400S Air Purifier is the only device I do have out of all of them. I’m running the latest 3.X build of the binding thats on my github repo, as I couldn’t get the PR through to backport the v4.0 additions.

So regarding auto off time. I guess you mean the channel: timerRemain. This was actually superseded by timerExpiry. The timerExpiry should give the scheduled date / time that the unit will shutdown when you set a timer in the VeSync app. When no timer is active it will be null to indicate no timer is active, should be the expected behaviour and what I can see. The only references I can see to it are in the protocol handlers and doc’s, it should therefore be removed from the doc’s as you should see it as an invalid channel.

Originally that protocol field was mapping through however as some UI bits don’t auto update, and due to lag’s etc, it was confusing. Hence the system calculated the expected expiry time of the timer from the protocol and displays that. Users can then calculate the delta if needed from now using rules, etc…

That’s a really good catch thank you. I have noted to remove timerRemain from the doc’s, I even have it on my system I took the doc’s examples from, and it states invalid channel! :frowning:

Still reading through the rest.

1 Like

Hi @Pedro_Liberal, okay I had a look at the room size setting. In the app if I set in Auto Mode Settings a size there, it does appear to be polling and reading it. I cant see any code changes that would affect this since the initial addition of the binding. It does seem to show that setting once the next request for an update is done from OpenHab. Moving on to the Air Quality bit, (bear with me please long explanation here). I only use the ppm25 as that’s reflective of the units display, however I do remember seeing the value change when my wife made the house fog like when cooking and the unit went red with a 7000 approx ppm25 one time it did actually go up by 2. I don’t remember the limit’s of what increase that basic range - but the ppm ranges were large from memory and I hadn’t seen it change in normal use until then. (I’m not suggesting to put the unit next to a bonfire to determine how they map ppm to the air quality range :slight_smile: ).

Given the basic polling behaviours have not changed in the binding since its initial release, here’s the bits I’ve seen before (slightly long story - sorry). OpenHab interacts in our house with our POE switches using a binding I wrote (but have not published because it screen scrapes the ssh login of the switch and I have not had time to tune its threading up). Its use actually highlight’s two possible causes to me if your not seeing data updates:

First try setting in the openhab console:

log:set TRACE org.openhab.binding.vesync

This will enable trace output (but don’t post with the token on forums - the protocol’s not the best).

What you can see is the data then openhab is reading via the binding from the VeSync cloud servers, which their units talk to. An example response from their cloud servers would be:

01:50:25.241 [DEBUG] [vesync.internal.api.VeSyncV2ApiHelper] - Got OK response {“traceId”:“1685148624848”,“code”:0,“msg”:“request success”,“module”:null,“stacktrace”:null,“result”:{“traceId”:“1685148624848”,“code”:0,“result”:{“enabled”:true,“filter_life”:80,“mode”:“manual”,“level”:2,“air_quality”:1,“air_quality_value”:5,“display”:true,“child_lock”:false,“configuration”:{“display”:true,“display_forever”:true,“auto_preference”:{“type”:“efficient”,“room_size”:452}},“extension”:{“schedule_count”:0,“timer_remain”:0},“device_error_code”:0}}}

The reason I go to this depth is because:

  1. I have seen this system when the POE switches binding I mention, starts up it blocks threads for a while until it finds its position in reading and interpretation the data. So when something else is blocking the binding from working I would not see the trace output like above. As something is taking all the resources, in my case during the start-up for a min or so for this binding completely irrelevant to the VeSync one, which can stop it doing anything. So is it trying to get the information would be the first bit to check.(If it doesn’t appear to be requesting data try disabling bindings one by one may indicate which one is behaving less than ideally).

  2. If you can see it requesting fresh responses, then the issue will be between vesync’s cloud servers and the devices. (If the app is showing correct data - that’s a whole new bag of worm’s as it means there must be something else going on like proxy caching). However when our POE switch shuts down some of our WiFi units the Air filters never used to reconnect to a different unit with the same SSID that remained on for IOT gear. A quick way to test is whether the app is reflective and openhab is not of the current state, and whether you can still control the devices from the app.If they are not then it maybe a wifi issue, keeping the link to the units.

I suspect however from what you have described the its air quality is the natural ranging applied by vesync, and room sizing could be firmware related possibly to the device? Going forward’s:

I’d suggest:

  1. Check the traces from the binding
    A) Is it polling at the intervals set - if not what binding when turned off allows it to poll in a timely manner
    B) If you look at the channels for the air quality and room size should mirror those responses from VeSync’s servers. If they don’t there is a binding issue, but I suspect they are not giving the data from test’s here.
    C) If the device shows different values from the responses from VeSync’s server’s then its likely some WiFi issue, but you would likely notice that on the app.

Hopefully that will narrow it down. P.S your best leaving the poll rates at the defaults set - just in case you have changed them. The device’s still have a lag on pushing their data to VeSync, and air quality shouldn’t change that much at speed :crossed_fingers:

Hopefully the above helps, thanks for the good spot with the timerRemain channel! I’ve got a draft MR for that one - on hold pending further reading on the last bits on this thread tomorrow, and any other bits that may need looking at.

Thanks again

1 Like

I have a newly purchased LV-PUR131S.
Can assist with testing if needed.
What I’ve done so far:

  • Unit added to VeSync app on my phone
  • Unit added to WiFi in the VeSync app.
  • Added VeSync Bridge to openHAB with my mobile Vesync credentials.
  • Scanned in openHAB against the VeSync bridge

Scan does not see the purifier.

Hi @xanderphillips,

Technically that one isn’t supported because it uses a non v2 protocol unlike all of the other air filters. I did a V2 version so could only verify the port of its behaviors, if you have the time to support testing, alongside capturing some logs I can probably figure out along with the pyvesync source code what we need to patch it in.

Assuming that’s ok.

Can you first confirm which version of the binding are you using and with which version of OpenHab?

If you can set this log (org.openhab.binding.vesync) to TRACE level, we can get an idea then what the device is reporting itself as. However if you could confirm version of OpenHab first and the version of the binding that would be great thanks, and we can go from there.

Hi @xanderphillips

If you have the device and are happy to test on a 3.4.X installation. I have a build here, based on simulations of pyvesync. I believe this should work for the models that report as: “LV-PUR131S”, “LV-RH131S”.

If you are able to confirm it works hopefully, then I can start raising the PR’s and update the documentation for it, in relation to the 4.X branches.

Many thanks - fingers cross you can help with testing in a 3.4 version of openhab, and it does kick in as I expect.


Hi all,

In case any one has (Air Purifiers) the 131 series purifiers or new Vital units, any chance you could give this a spin on OH4? I have a pull request currently queued: [veSync] 131 and Vital Purifiers base support by dag81 · Pull Request #15296 · openhab/openhab-addons · GitHub

Its tested against simulations based on the interactions of pyvesync and the binding, so it should be good. However a real life confirmation would be good if anyone can.

This is the PR build:

Thanks in advance, if anyone can validate any of the 131 units, or Vital units on OH4

In addition I just saw the controls modes have been renamed from auto to humidity for the humidifiers (2 models), I was going to look at the code base for updates next for those. Could anyone confirm if the auto mode is not working as expected for the 600S Humidifier or the Oasis Mist please?

Just to update: This has been put to back to draft, as found some packet captures which meant a few bits needed updating. The build has been updated - doc updates pending for Oasis Mist 1000, but above applies :slight_smile: