Sorry a question on this one. The parameter is a number between 0 - 100 that gets sent. Does it only do anything at the 0 / 50 / 100 setpoints? It implies its really a enum for off, dim, on if so. The pyvesync just lets 0 -100 therefore hence the question. If it should be remapped to off / dim / on then that can be adjusted for that given model based on the discovered data about the device.
Thanks for all the info, hopefully once the bindings sorted it will be of some use 
Regarding:
Later on after testing over lunch here. I’ll update the channels to remove the config channels for display for both the air-purifiers and humidifiers, so that the single display channel handles it all. In regards to the humidifier the same thing regarding the stop at target reached, so there’s just a single channel that handles it all.
Please see comments under each one in bold to save mass message reading
Regarding this bit - it sort of makes sense if I’m understanding the logic based on how the air purifiers work:
Note:
- If the unit is set in mode=Auto and I change the Virtual Mist, the mode automatically change to manual
- If the unit is set in mode=Manual and I change the humidLvlCfg, the mode stays in manual and the humidLvlCfg is restored as the next reporting. I would have expected it to change to Auto following the previous bullet point logic
This makes sense I think, I will reference the Air Purifiers behaviour as I suspect this is the same:
For the Core400S on the App there are these direct controls:
Auto / 1 / 2 / 3 / 4 / Sleep
So Auto and Sleep take control of the fan speed, and are reported as the mode. If a speed setting is selected, the mode changes to Manual, and the fan speed changes to the relevant level.
For the binding if a speed is set it has to first set the mode to manual, and then set the fan speed.
It sounds therefore from what you have said there is also a mode called “manual” which you see when you set what will be the mist level in the app is that correct? If so it sounds like it follows the same logic as the air filter where the binding should send manual prior to the mist level. If you could confirm you are actually getting manual from the device, firstly, and what changes determine it changing to manual in the app, I can adjust accordingly. I’m just guessing a change in the mistLvl should change it to manual.
Based on the feedback that the night light for the air humidifier only operates at 0 / 50 / 100 as I understand it, and the manual only shows these modes. The channel has been mapped to a new string based channel for the classic 300S humidifier to support only off, dim, on like the air purifiers. A new build has been pushed to main.
All the branches have been merged to main regarding the Air humidifier, so this location will contain the latest revision of the build.
Hi, sorry for this late reply, lot of stuff going on. I’ve tested your latest release, please find my comments bellow regarding the new item definition:
1. power
Still works as expected, no issue here (tested both control and reporting from OH and device)
2. displayEna
Still works as expected, no issue here (tested both control and reporting from OH and device)
3. lowWtrLvl
Still works as expected, no issue here (tested reporting to OH)
4. hiHumid
I’m not able to get this one to trigger when using the Auto mode with and without the “Stop at Target”. If you have hint or thing you want me to try I’m open to suggestions
5. tnkRem
Still works as expected, no issue here (tested reporting to OH)
6. stopAtTrg
Still works as expected, no issue here (tested both control and reporting from OH and device)
7. humidLvl
Still works as expected, no issue here (tested reporting the actual room Humidity Level to OH)
8. mistLvl
Works as expected, no issue here (tested both control and reporting from OH and device). Number 1,2,3 from OH does represent to Device Low,Med,High respectively
10. mode
Works as expected, no issue here (tested both control and reporting from OH and device). mappings=[auto=“Auto”,manual=“Manual”,sleep=“Sleeping”]
11. lightLvl
Not Working, the binding always report a Null String. I think this one should be kept at a 0-100% number as it was before. This was working and was pretty simple to use
14. humidLvlCfg
Works as expected, no issue here (tested both control and reporting from OH and device). This represent the set point when the device is in mode=auto. I may use a visibility attribute in my sitemap to mask it when mode != auto
Hi @lyo125,
Thanks for all the feedback and assistance 
Looking at 4. hiHumid
I looked through the manual and I still don’t know what this represents. In pyVeSync it’s referenced as humidity_high? Maybe if its above the current humidLvlCfg in auto mode - but I’m just guessing? I wonder if it goes to ON if you set the humidLvl below the current humidLvl?
Looking at 11. lightLvl
Before the long bit, I’ve done a cross check and made some silly typo’s which messed up the channel aligning. There’s a new build which should correct this for the off, dim, on. If it is using the values 0 / 50 / 100 at a protocol level 
then it should work. (I’ve checked it at least 3 times now 
).
In regards to whether it should be a enum equivalent of off, dim, or a numeric.
Wearing a developer hat. It should reduce lot’s of queries as to why does it only work at 0, 50, 100 as that is all it sounds like the device uses, so the enum would be an accurate representation of the available functionality. Also it will stop invalid values being pushed to vesync, which I’m guessing they won’t like given the number of commands I’ve seen openhab send when adjusting sliders to other bindings.
Wearing a user hat, I don’t like using string enum’s effectively in text based rules. If it was a number then I would be one of those annoying one’s contacting the developers of this binding or VeSync asking why does it only work on these numbers. As a enum its clear what can be used to command the channel.
Given those points I’d prefer probably going with a string (enum) representation atm, are there other argument’s I’m not seeing?
The channel naming fixes correct the issues with 11.
Thanks again - hopefully the above makes sense - fingers crossed it performs now as expected.
David
Hi, I’ll try to give more test to the hiHumid and see If I can figure out a test scenario where it will work
Regarding the light level I do agree with what you are saying in terms of user perspective. I’ve tested your latest Commits on Nov 20, 2021 (Version 3.2.0.202111201647) and the string still reports null via the thing:
I did try to push a string to the channel using mappings=[on=“On”,dim=“Dim”,off=“Off”] but nothing worked. There may still be a bug somewhere. Also nothing was reported in the log file. The channel does accept the string
But no change on the device or the app. And at the next refresh the string stays there. It is not replaced back by NULL
Hi,
Sorry been it a bit busy here as well. Okay I’ll have a closer look through, and see if theres something I missed in the merge. If you are comfy doing it would you mind capturing the trace information when it poll’s the device - just remove your token info, mac’s or any personal data first. It would be good to see what it poll’s after the device has been set to each mode.
I’ll try to get another look over the weekend, to spot hopefully the silly typo. If you do capture the output, I can add some unit test’s based on the data from the device as well.
Thanks again
David
Here are some Log. Nothing Special to see… I’ve set the light to Off, Dim and On using the VeSynch App. Reported log where:
2021-11-30 19:39:16.944 [DEBUG] [esync.internal.api.VesyncV2ApiHelper] - Got OK response {"traceId":"1638319156756","code":0,"msg":"request success","result":{"traceId":"1638319156756","code":0,"result":{"enabled":false,"mist_virtual_level":5,"mist_level":2,"mode":"auto","water_lacks":false,"water_tank_lifted":false,"humidity":61,"humidity_high":false,"display":false,"automatic_stop_reach_target":true,"night_light_brightness":0,"configuration":{"auto_target_humidity":60,"display":false,"automatic_stop":true}}}}
2021-11-30 19:42:39.494 [DEBUG] [esync.internal.api.VesyncV2ApiHelper] - Got OK response {"traceId":"1638319359289","code":0,"msg":"request success","result":{"traceId":"1638319359289","code":0,"result":{"enabled":false,"mist_virtual_level":5,"mist_level":2,"mode":"auto","water_lacks":false,"water_tank_lifted":false,"humidity":63,"humidity_high":false,"display":false,"automatic_stop_reach_target":true,"night_light_brightness":50,"configuration":{"auto_target_humidity":60,"display":false,"automatic_stop":true}}}}
2021-11-30 19:42:44.716 [DEBUG] [esync.internal.api.VesyncV2ApiHelper] - Got OK response {"traceId":"1638319364518","code":0,"msg":"request success","result":{"traceId":"1638319364518","code":0,"result":{"enabled":false,"mist_virtual_level":5,"mist_level":2,"mode":"auto","water_lacks":false,"water_tank_lifted":false,"humidity":64,"humidity_high":false,"display":false,"automatic_stop_reach_target":true,"night_light_brightness":100,"configuration":{"auto_target_humidity":60,"display":false,"automatic_stop":true}}}}
When trying to set the night light via OH, nothing appears in the log when sending the command. I’ve confirm the Thing does get my request as explained in previous post. ex:
Hi @lyo125,
Apologies for the slow responses it’s been a “tad” busy here - however the break and your debug data have helped greatly thanks.
The good news is that I was able to replicate, on one of the computers I have setup as a testbed. On updating, although everything looks good it did not update the existing channel, although everything indicated that it should have. When I added a new channel that had the same fault.
However… finally a breakthrough… when I added a new Thing, low and behold it picked up the values from the injected simulations based on your data. I think if you unlink your points, delete the thing. Add a new thing for the Air Humidifier and then relink the point’s it should have that night_light_mode channel mapped.
At the moment without more digging, I’m not sure if this is an error in this implementation from the code I have based it on or on the build of OpenHab we are both running. (More than likely I need to adjust this code I am guessing).
If you could delete the thing and then add a new one I suspect it will magically work with the build that you currently have If you could let me know once you have tried that would be great thanks. It may get confused with two using the same addressing, so I would delete then add, not just add another one referencing the same unit… just to be safe.
Hopefully that makes sense, please let me know if not…
David
Hi @dagoodyear,
Thanks for all the hard work on pulling this binding together! While you clearly say 300S may be supported, I bought a 600S Humidifier to try out after stumbling across this post. It seems everything should work and it’s just that the Thing Registration doesn’t support the type. Here is my debug info if you have a few cycles to take a look. Happy to do any troubleshooting I can.
12:19:23.558 [DEBUG] [vesync.internal.api.VesyncV2ApiHelper] - Found device : Adam’s Room, type: wifi-air, deviceType: LUH-A602S-WUS, connectionState: online, deviceStatus: on, deviceRegion: US, cid: XXXX, configModule: WFON_AHM_LUH-A602S-WUS_US, macID: 24:XX:XX:XX:XX:XX, uuidL XXXX
12:21:18.489 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'vesync:AirHumidifier:f9' changed from UNINITIALIZED to INITIALIZING
12:21:18.524 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'vesync:AirHumidifier:f9' changed from INITIALIZING to UNKNOWN
12:21:18.492 [DEBUG] [rnal.handlers.VeSyncBaseDeviceHandler] - Searching for device mac id : 24:XX:XX:XX:XX:XX
12:21:18.529 [DEBUG] [rnal.handlers.VeSyncBaseDeviceHandler] - Searching for device mac id : 24:XX:XX:XX:XX:XX
12:21:18.530 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'vesync:AirHumidifier:f9' changed from UNKNOWN to ONLINE
12:21:18.532 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'vesync:AirHumidifier:f9' changed from ONLINE to OFFLINE (HANDLER_REGISTERING_ERROR): Device Model or Type not supported by this thing
Cheers,
Adam
Hi Adam, I sent you a direct message - please try that build to confirm if most of the functionality works with the V2 API. It doesn’t look like pyvesync has updated their support yet which was my reference point for the end points, the API uses. Other references seem to indicate most of the functionality is close to previous units so it will support most of the functions with the current 300S V2 code.
Everything appears to be working as expected with both my new 300s and the 600s’s. Thanks @dagoodyear! Should be safe to merge to head. The only caveat is the 600s doesn’t have a nightlight, but hopefully anyone using OH3 can figure that out
Hi @veganjinx,
Many thanks for getting back I’ve updated the code a bit if you wouldn’t mind checking on a different installation - that it should remove the night light channel for the 600S and i’ve updated the documentation in the potential branch that will be merged. The build can be found here: 600S Beta Build.
(As you say I would hope people would work that out - but I’d hope the binding doesn’t send irrelevant data to VeSync either - so for completeness I updated it, in a defensive approach).
I’m hoping it all works as expected given they were very quick adjustments - hence the suggestion to use a new installation (or keep your old jar file ready to restore if required ).
Glad it appears to be running as hoped
If you can cross check that would be great when you have time before I merge the branch back to main that would be great thanks.
Thanks / cheers
David
P.S I should thanks the Humidifier support wouldn’t have been possible without the data provided by @lyo125
Tested the new build and verified the channels were all updating and changeable as described by @lyo125 above from both the 300s and 600s.
The night light channel is gone on the 600s, but there is still a “test” channel with name night light for both devices that was also present in previous builds for both devices.
Finally, for extra credit. There are two additional fields in the 600s API as it has the ability to use warm or cool mist.
“warm_enabled”:true
“warm_level”:3 which similar to mist_level is an enum 1, 2, 3
One thing I like about these humidifiers and the binding is that while they auto shutoff with low tank or at a set humidity, they still report current humidity 24/7 so they can be used as a humidistat even when not in use Now to figure out if I can feed this information to my ecobee.
Hi @veganjinx,
I can’t find any reference yet for writing those warm_enabled or warm_level values. However, I’ve updated the .jar on the branch I sent you - if you could check if it can now read the warm_mode and warm_level please? I’ve left them as writable (although it won’t be able send any commands until those bits of the protocol can be added). I’m still searching google at the moment - in case anyone has the details somewhere.
The channels shouldn’t appear for the 300S but should be there for the 600S
Could you confirm whether the warm level reads as 1,2,3 or 1,5,9 as well please? If its 1,5,9 I can remap it to 1,2,3 for consistency.
P.S It’s the same for the Air Filters they constantly measure the air quality when they are off as well I get OpenHab to spin them up for 5 mins every hour, if they haven’t been run for a while, just to make sure they get an accurate latest reading.
For anyone I’ve sent links to for build’s on branches, everything has been merged to the main branch tonight, as I had to rationalise the branches , to determine my old dev system was kaput.
The current build is at: vesyncOpenhabPyPort/manual builds at main · dag81/vesyncOpenhabPyPort · GitHub
Breaking changes for existing installations
Hi, My apologies. I have had to rename the channels as now shown in the readme, looking at other PR’s for getting the binding into OpenHab 
prior to re-creating the PR.
(I have to do the same on my server as well :(). Hopefully however it’s one more step to getting it into the official distribution).
If you download any of the latest manual builds they will use the new channel naming - not the old ones, so likely items if file based will need to be reconfigured as per the readme. E.g. air-quality is now airQuality, etc.
Hi Adam, @veganjinx
I’ve transferred over the potential changes required for the warm level to be set, from the pyvesync PR request. Unfortunately the build is based on the latest, which has the Breaking changes in, built against 3.3. (Channel renames to comply with the requirements for a hopeful PR into the main OpenHab builds).
I don’t know if you or anyone else with a Air Humidifier model 600S could install in a separate instance and see if setting the warm mode between the levels 1 and 3 works, if possible please? I suspect another setting is needed to disable warm mode, unless 1 is off?
Can whoever checks please advise:
The manual build is available here if at all possible?
Its possible to test.
Thanks in advance Adam or anyone who can cross check.