Fix for (some) tuya covers

[imhotep]

Proposed change

The tuya API for some covers is currently breaking as some parameters come back a strings and the code expects integers. This PR attempts to convert the expected integer params from strings.
This PR also sets Reverse param to False which is set to True by default.

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

Additional information

• This PR fixes or closes issue: fixes Covers get added but are unavailable #59035 and maybe Tuya Cover Controller opened/closed inverted #59099
• 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.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

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

To help with the load of incoming pull requests:

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

[homeassistant]

Hello @imhotep,

When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).

The commits that are missing a linked GitHub account are the following:

• 7fa3e0fbcb6e21957d672d1e2391afe92be408a2 - This commit has something that looks like an email address (anis@anislab.com). Maybe try linking that to GitHub?.
• 9a678a654445505ea08787c5cf2c0e42bc0d29b7 - This commit has something that looks like an email address (anis@anislab.com). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.

Here are your options:

1. If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

2. If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

   • If you only made a single commit you should be able to run

     git commit --amend --author="Author Name <email@address.com>"
     

     (substituting Author Name and email@address.com for your actual information) to set the authorship information.
   • If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:
     1. You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
     2. You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.
   • Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.

Thanks, I look forward to checking this PR again soon! ❤️

[probot-home-assistant]

Hey there @tuya, @zlinoliver, @METISU, @frenck, mind taking a look at this pull request as it has been labeled with an integration (tuya) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[frenck]

The tuya API for some covers is currently breaking as some parameters come back a strings and the code expects integers.

This would violate specifications of the API. Have you contacted Tuya about this? As that sounds like an API issue.

This PR also sets Reverse param to False which is set to True by default.

We cannot simply flip that around. This is device depended. What devices will now break?

[imhotep]

This would violate specifications of the API. Have you contacted Tuya about this?

I have not contacted Tuya as I don't know how to reach them. If you can provide me with some contact info I'd be more than happy to do that.

We cannot simply flip that around. This is device depended. What devices will now break?

I agree. Ideally, we'd fetch the Reverse param from the API instead of setting an arbitrary value. I just noticed another user who filed an issue about this and figured it was breaking for more people and that the sane default would be to set it to False. If the API doesn't provide the info that perhaps we can make it user configurable?

[frenck]

I have not contacted Tuya as I don't know how to reach them. If you can provide me with some contact info I'd be more than happy to do that.

You can contact support when you log into the developer portal. Please note, that there are unsupported/devices out there that are not conform specifications. As there are many, we are not planning to add workarounds for them.

If the API doesn't provide the info that perhaps we can make it user configurable?

We can't make that user configurable. We don't have a construct for that in Home Assistant at this point.

[Jhonattan-Souza]

I have not contacted Tuya as I don't know how to reach them. If you can provide me with some contact info I'd be more than happy to do that.

You can contact support when you log into the developer portal. Please note, that there are unsupported/devices out there that are not conform specifications. As there are many, we are not planning to add workarounds for them.

If the API doesn't provide the info that perhaps we can make it user configurable?

We can't make that user configurable. We don't have a construct for that in Home Assistant at this point.

Hi @frenck , in the tuya custom_integration ( TuyaV2 before migration ), me and some friends wrote custom code for devices that weren't specified in tuya's documentation, it's natural because they work with white label devices, do you think it's possible to develop some feature so that Home Assistant accepts custom settings? As there are so many tuya devices, I believe it would be a good alternative, but I don't know if it is possible

[frenck]

That question is to generic to be able to answer. Home Assistant doesn't have a construct for device level options (only integration level options).

Custom integrations often violate design principles, but I cannot judge from your story if that is the case or not, as there is no concrete implementation suggestion in it.

That said, that might be out of scope for this PR as well.

[imhotep]

@frenck I got in touch with Tuya support and they fixed the API. Their iot dashboard was also crashing because of this bug so it wasn't just specific to Home Assistant. The integers come back nicely now.
However, the Reverse issue still remains. Is there a reason why the default Reverse is set to True?

[frenck]

I got in touch with Tuya support and they fixed the API. Their iot dashboard was also crashing because of this bug so it wasn't just specific to Home Assistant. The integers come back nicely now.

Awesome! Thank is amazing progress! Thank you! 🙏

Is there a reason why the default Reverse is set to True?

Yes, because it is device (or device category) dependent. So we can't just swap it for all.

[imhotep]

Yes, because it is device (or device category) dependent. So we can't just swap it for all.

I get that but this setting doesn't work for some users like me that don't have their motors set to Reverse. What is the solution for us? This is not even documented and most users might just think that the integration is broken.

[frenck]

What is the solution for us?

There is none. You could use a template entity to wrap its behavior. We won't be able to support every single device that uses a Tuya chip (as not all manufacturers that use these chips are following the spec).

[imhotep]

Alright. I will keep using a custom component for now. Closing this one.