Bump pydaikin to 2.0.1, catch HTTPForbidden exception

[fredrike]

Proposed change

Catch HTTPForbidden thrown when authentication in init() is unsuccessful.

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)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

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
• The code has been formatted using Black (black --fast 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.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

[ctalkington]

#34523 introduced some common strings such as invalid_auth that are shared between all integrations that choose to use them. I wonder if thats better to use here also is there a reason to abort when it may be user correctable if you provided error feedback?

[fredrike]

#34523 introduced some common strings such as invalid_auth that are shared between all integrations that choose to use them. I wonder if thats better to use here also is there a reason to abort when it may be user correctable if you provided error feedback?

Yes you are right, I will change it to use common strings,what is the best way to show the error?

[balloob]

@Frederike create an errors dict and pass it to async_show_form. Use the field name to show the error near the field. Use the name "base" if you want to show the error above the form.

[fredrike]

@Frederike create an errors dict and pass it to async_show_form. Use the field name to show the error near the field. Use the name "base" if you want to show the error above the form.

Great! I'm updating the code right now..