List of future improvements

[postlund]

I think it's a good idea to make a list of features and improvements we can make in the future. I'll start with my list:

• Extract code and create base class for entities, e.g. LocalTuyaEntity based on a config entry.
• Update entity on-the-fly when options are changed without having to restart Home Assistant (depends first bullet and Add support for config flow option #14).
• Scanning support in config flow.
• Use scanning to find a device before connecting to it, to handle dynamic IP address changes. I use a similar scheme in the Apple TV component.
• Break out status polling from individual entities and inform entities about updates via the signal interface. This allows us to update devices with multiple entities, e.g. double gang switches, with one request instead of one per entity.
• Make our pytuya implementation actually support the protocol, e.g. by inserting correct sequence number (and other stuff that needs to be handled). The outcome I'm after is to have the network connection up at all time instead of connecting, sending command and immediately disconnect when done. I believe this will be a lot more stable and faster.
• Convert pytuya to asyncio (and the rest of the integration as well).
• Add generic sensor and binary_sensor platforms that can read any DPS value and present as state.
• Easy set up of helper sensor, e.g. integration sensor that calculates kWh for used energy.
• General code clean up, removing commented code (it's still available via git history), remove print statements and change some to debug, run black, pylint and flake8 on all code.
• Improve documentation, translations in config flows, etc.

Anything I have missed? After some discussion we could make a priority list, create issues for things to do and come up with a roadmap (as supported here on GitHub).

[cwttdb70]

There's been discussion over at #10 about adding a "Hacked Position" config option for cover devices that lets you set the "position" for devices that don't technically support setting device position. This could be added as an experimental feature or something along those lines. Or is there a better way to approach this? All of my cover devices support set position, so i'm probably not the best person to work on this feature.

[rospogrigio]

Somebody on the community thread asked for the climate platform to be introduced.

[postlund]

The climate platform should be quite easy to implement now if someone knows how what the DPS are used.

[rospogrigio]

Let's update the list:

• DONE: Extract code and create base class for entities, e.g. LocalTuyaEntity based on a config entry.
• DONE: Update entity on-the-fly when options are changed without having to restart Home Assistant (depends first bullet and Add support for config flow option #14).
• DONE: Scanning support in config flow.
• Use scanning to find a device before connecting to it, to handle dynamic IP address changes. I use a similar scheme in the Apple TV component.
• ALMOST DONE: Break out status polling from individual entities and inform entities about updates via the signal interface. This allows us to update devices with multiple entities, e.g. double gang switches, with one request instead of one per entity.
• IN PROGRESS: Make our pytuya implementation actually support the protocol, e.g. by inserting correct sequence number (and other stuff that needs to be handled). The outcome I'm after is to have the network connection up at all time instead of connecting, sending command and immediately disconnect when done. I believe this will be a lot more stable and faster.
• IN PROGRESS: Convert pytuya to asyncio (and the rest of the integration as well).
• DONE: Add generic sensor and binary_sensor platforms that can read any DPS value and present as state.
• Easy set up of helper sensor, e.g. integration sensor that calculates kWh for used energy.
• DONE: General code clean up, removing commented code (it's still available via git history), remove print statements and change some to debug, run black, pylint and flake8 on all code.
• Improve documentation, translations in config flows, etc.
• Positioning handling for covers
• Support to climate platform
• Improve support to lightbulbs

[postlund]

We should create issues for each remaining thing and perhaps start to use milestones. It makes it easier to plan our work.

[sajid2310]

Support for Multi gang switch with FAN.

[postlund]

Support for Multi gang switch with FAN.

Per se already supported, but the fan platform needs some attention.

[RobyDomo]

Hi,
do you think is it possible to have a vacuum platform?
I have a robot that works with smart life app. I already extracted ID and Key, but without vacuum platform i don't think it can work locally. With tuya integration HA has imported the scene, so i can use vaccuum but anyway i use tuya cloud.

[postlund]

Probably possible, but they are quite complex so likely requires a bit of work. Maybe you can create a new issue (as a feature request) and post a DPS dump?

[RobyDomo]

thank you for you answer @postlund . Sure i can create a new issue as a request, but i don't know how to create a DPS dump.
Thanks for your help. :-)

[rospogrigio]

@postlund I can take care of this, looks like MUCH easier than climate platform.
@RobyDomo in order to have a DPS dump you can use the script in tuyadebug.tgz or wait some hours because we are about to have this PR available: #79 (or maybe you can just try it and provide feedbacks, actually).

[postlund]

@rospogrigio Maybe add some instructions for tuyadebug to readme as I did with debug logs? Or maybe we should move as much as possible over to the wiki instead as that is more flexible?

[rospogrigio]

Yes, I agree...