Add humidifier entity for Vesync devices

[iprak]

Proposed change

This request introduces humidifier entities (and related sensors) for Vesync devices.

This is not a complete representation of the humidifier. The humidifier exposes some binary states and allows number mist level to be set. The former is being introduced in #134221 and I will introduce the latter in another PR.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: Levoit classic 300s vesync not showing #72709
• This PR is related to issue:
• Link to documentation pull request: Draft request to update Vesyns humidifier documentation home-assistant.io#36624

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hey there @markperdue, @webdjoe, @TheGardenMonkey, @cdnninja, mind taking a look at this pull request as it has been labeled with an integration (vesync) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of vesync can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign vesync Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[cdnninja]

Thoughts on us shifting to checking the class used by the library vs keeping a full list of models? It seems a key pain point is sometimes the underlying library supports a variant and we miss adding it.

I was hoping for two approaches. 1. When can just validate the value exists use that. 2. If needing to know for sure if it's a type like fan or humidifier check the class.

[iprak]

Thoughts on us shifting to checking the class used by the library vs keeping a full list of models? It seems a key pain point is sometimes the underlying library supports a variant and we miss adding it.

I was hoping for two approaches. 1. When can just validate the value exists use that. 2. If needing to know for sure if it's a type like fan or humidifier check the class.

I think you are suggesting checking device.type against VeSyncHumid200S or VeSyncSuperior6000S or VeSyncHumid1000S in is_humidifier ? That does sound better.

I do see there is this humidifier VeSyncSuperior6000S which does not derive from VeSyncHumid200300S and so would its own handling.

[cdnninja]

Something along those lines yes. Also for other purposes. I am finding a key challenge with the way it is written today is it depends on the vesync library stating something is a "fan" or "switch" when a platform of switch in HA doesn't align, switch can be used for many things, including screens, power, modes etc. So the platforms themselves need an easy way to check support. I think the binary sensor code does that for most values reasonable well, just need a way to check methods in addition.

For fan and humidifier I feel like a method like you mentioned above makes sense. Check if it is one of the classes. That way variants are covered without us mapping everything.

If interested could you join the HA discord so we can message on this? Love the work you are doing!

Ps I have a refactored draft of switch ready as well. I am waiting for items to be merged though since lots outstanding on that front.

[iprak]

I have adjusted the is_humidifier function and it works well. Seems the addition of humidifier has lowered the test coverage .. so I will write some more tests to get it above 80%

[cdnninja]

I agree with #134166 (review) joostlek comment that we should move our platform checks within the platform. It would greatly simplify some of the code. Thinking as we add new platforms we should do that.

As well do you see any value in the discovery call back? I don't think it will be used, just seems to complicate things?

[iprak]

I agree with #134166 (review) joostlek comment that we should move our platform checks within the platform. It would greatly simplify some of the code. Thinking as we add new platforms we should do that.

As well do you see any value in the discovery call back? I don't think it will be used, just seems to complicate things?

The discovery service would only be used if one add/removes devices to the account. It feels more intuitive to "Reload" the integration which should update the devices or would that not remove the older entities? Maybe that is still okay, one can remove them manually.

[cdnninja]

Correct but with the coordinator change we only call updates to the devices so we will never see a new device?

[iprak]

Correct but with the coordinator change we only call updates to the devices so we will never see a new device?

Yes and I think that is okay. Maybe that is why all integrations have the reload option. I have not seen or used an integration which queries for device update but my integration usage is limited.

[cdnninja]

Some do, I agree reload makes more sense here.

[cdnninja]

@home-assistant add-label new-feature

[cdnninja]

Quick note in another PR they wanted to keep the callbacks and potentially add a scheduled device list update. So for this we should keep it in. Eventually we can add a PR to check for devices from time to time. I am thinking this can be re-based and go for review? I don't think it actually depends on the binary_sensor beyond potential test conflicts which could be quickly updated once binary is merged?

[cdnninja]

I also wonder if switch changes should be removed from this to make it easier to get across the finish line. Then we can add those features after #134409 gets merged.

[iprak]

I also wonder if switch changes should be removed from this to make it easier to get across the finish line. Then we can add those features after #134409 gets merged.

That is a good idea. I will keep humidifier simple for now and then add sensor/switches later.

[iprak]

This is ready for review but there is this check "Has at least one of the required labels (breaking-change, bugfix, code-quality, dependency, deprecation, new-feature, new-integration)" which is failing and I am not sure what I need to do to address that.

The documentation PR only mentions 2 humidifiers. I can only verify the functionality on the model I have.

@joostlek Would you be able to review this too?

[iprak]

@home-assistant add-label new-feature

[iprak]

Resolved conflicts

[neilime]

Thank you for your work guys! I can't wait to use it for my installation

[cdnninja]

Amazing work! This one has been an ask for many years from the community so very excited it is done!