[vesync] Levoit Vital 100s Air Purifier support

[m0rgano]

I have a Levoit Vital 100s air purifier.

I'm currently running OH 4.2.2 on a Linux box (Ubuntu), Java 17.

When creating a Thing for this device using the VeSync Binding (4.2.2), I get the following error:

2024-11-23 14:03:34.031 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'vesync:airPurifier:fbcc735784' changed from INITIALIZING to UNKNOWN

2024-11-23 14:03:34.044 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'vesync:airPurifier:fbcc735784' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Device Model or Type not supported by this thing

The VeSync bridge appears to be working OK. I believe the issue is just regarding support for the 100s device.

[lsiepel]

If I’m not mistaken this support is about to get added by this pr : #15296

[dag81]

Thank you for raising @m0rgano, apologies for the misdirection by using the old repo as a file share. Also your really on it @lsiepel thank you for tagging up, and spotting so quickly :) m0rgano has been really helpful in testing with a real device, there is 1 bit we are trying to narrow down, as the simulations align on the core bits against the software stack that has historically been key and where this code is ported from generally, but fan speed is uncontrollable. Results currently from m0rgana are:

Summary of tests on the channels:

enabled: OK (reading & writing)
display: OK (reading & writing)
childLock: OK (reading & writing)
filterLifePercentage: OK (reading, writing N/A)
fanMode: OK (reading & writing)
airQuality: OK (reading, writing N/A)
airQualityPM25: OK (reading, writing N/A)
manualFanSpeed: OK reading, but changes from OH not reflected on device

Hopefully we can narrow down quickly, otherwise would prefer to add a known limitations section to the readme if all else fail's on this, and raise a new bug for the specific manualFanSpeed issue - in the worst case, if we cant pin it down in time. Only as there's so many other key updates in that PR that should make it to 4.3 that will allow much better interoperability for other users of the currently tested devices, in other regions.

[m0rgano]

@dag81 No worries re: repo confusion :-)

I enabled DEBUG logging for the vesync binding and did some more testing this morning.

It appears that there is no attempt to send a POST request when attempting a Manual Fan speed change, so maybe this is a blockage around the logic that decides to send a command, rather than a problem with the command contents itself.

Hopefully this might indicate a simpler fix?

I'm happy to load in another snapshot if you'd like to tweak anything, add more logging etc.

[dag81]

@m0rgano So I was testing on our main server with 4.2.2 its commanding fine with the fan speed. Also 4.3 M4 has no issues with sending the command. I don't believe there's a issue with the actual command handling. The one thing that could block it is if your thing is missing the device family property. Do you have all the fields shown in this screen shot (I've erased a few bits of the actual data from mine), and importantly what is the Device Family and Device Type reported as for the Vital 100 in your things prosperities?

I presume when you are changing the fan speed you do see something like this showing the change has been requested:

15:48:41.840 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Lounge_Air_Purifier_Fan_Speed' received command 4
15:48:41.840 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Lounge_Air_Purifier_Fan_Speed' predicted to become 4
15:48:41.842 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Lounge_Air_Purifier_Fan_Speed' changed from 2 % to 4 %

[m0rgano]

@dag81
Here are my device settings:

When I perform a Manual speed change I see the Item update messages similar to yours in the log but, unlike the other commands that are working, there is no corresponding HTTPS POST message.

2024-11-24 16:20:25.083 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'BedroomAirPurifierFanSpeed' received command 4

2024-11-24 16:20:25.092 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'BedroomAirPurifierFanSpeed' predicted to become 4

2024-11-24 16:20:25.094 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'BedroomAirPurifierFanSpeed' changed from 2 to 4

Here is an example of what I get in the log when changing the Display lights:

2024-11-24 16:21:44.643 [DEBUG] [esync.internal.api.VeSyncV2ApiHelper] - POST @ https://smartapi.vesync.com/cloud/v2/deviceManaged/bypassV2 with content

{

  "deviceRegion": "EU",

  "debugMode": false,

  "cid": "<obfuscated>",

  "configModule": "VS_WFON_APR_LAP-V102S-WEU_EU",

  "payload": {

    "method": "setDisplay",

    "source": "APP",

    "data": {

      "screenSwitch": 0

    }

  },

  "accountID": "<obfuscated>",

  "token": "<obfuscated>",

  "timeZone": "America/New_York",

  "acceptLanguage": "en",

  "appVersion": "2.5.1",

  "phoneBrand": "SM N9005",

  "phoneOS": "Android",

  "traceId": "<obfuscated>",

  "method": "bypassV2"

}

[dag81]

@m0rgano

I think I've spotted it now on one of the other thread's you posted your items file.

You posted this:

`Switch BedroomAirPurifierPower "Bedroom air purifier" (InternalState) {channel="vesync:airPurifier:6a341b2eef:6625fd1c-197a-442d-8c21-e9bbd5d1820f:enabled"}

Switch BedroomAirPurifierDisplay "Bedroom air purifier display" (InternalState) {channel="vesync:airPurifier:6a341b2eef:6625fd1c-197a-442d-8c21-e9bbd5d1820f:display"}

Switch BedroomAirPurifierChildLock "Bedroom air purifier child lock" (InternalState) {channel="vesync:airPurifier:6a341b2eef:6625fd1c-197a-442d-8c21-e9bbd5d1820f:childLock"}

Number BedroomAirPurifierFilterLifePercentage "Bedroom air purifier filter life %" (InternalState) {channel="vesync:airPurifier:6a341b2eef:6625fd1c-197a-442d-8c21-e9bbd5d1820f:filterLifePercentage"}

String BedroomAirPurifierOperationMode "Bedroom air purifier operation mode" (InternalState) {channel="vesync:airPurifier:6a341b2eef:6625fd1c-197a-442d-8c21-e9bbd5d1820f:fanMode"}

Number BedroomAirPurifierFanSpeed "Bedroom air purifier fan speed" (InternalState) {channel="vesync:airPurifier:6a341b2eef:6625fd1c-197a-442d-8c21-e9bbd5d1820f:manualFanSpeed"}

Number BedroomAirPurifierAirQuality "Bedroom air purifier air quality" (InternalState) {channel="vesync:airPurifier:6a341b2eef:6625fd1c-197a-442d-8c21-e9bbd5d1820f:airQuality"}

Number BedroomAirPurifierAirQualityPM25 "Bedroom air purifier air quality PM2.5" (InternalState) {channel="vesync:airPurifier:6a341b2eef:6625fd1c-197a-442d-8c21-e9bbd5d1820f:airQualityPM25"}`

The Dimensionless and other units are missing. The readme for the PR is here

As you added manually it should be for the manualFanSpeed Number:Dimensionless not Number.

I'm just spinning up to check locally but I'm pretty sure that will be it, as its not a Quantity Type it won't attempt to use it. Changing the type now would cause breaking changes that's why its left as is. Hopefully changing to Number:Dimensionless that will fix it for you.

I'll see if there's clean way to detect this and put a warning in from the binding, to save others hitting the same thing. Please let me know if you try this and it works.

[m0rgano]

@dag81
Well spotted! Yes, that does indeed appear to be the problem. I've changed my Number Items accordingly, and all seems to be working OK now! I will look out for that trap in the future!

Thanks for your help on this (and your work on the VeSys Binding)!

P.S. Let me know if you need me to test anything else on the 100s now or in the future.

[dag81]

Great - glad my simulations based on the pyvesync are correct - I was trying to see how an earth you could get that output :) Thank you @m0rgano for testing and confirming it runs as expected :) Yeah I hadn't ever thought about that before as usually cut/paste and modify from the doc pages when I add items. Thank you again - I may at some point ping you, if something else need's validating on the 100's at a later point, for now it's likely more urgent to get this MR in before the 4.3 release, as there are other key bit's so likely not adding anything more atm due to that. :)