Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List of future improvements #15

Closed
postlund opened this issue Sep 14, 2020 · 91 comments
Closed

List of future improvements #15

postlund opened this issue Sep 14, 2020 · 91 comments
Labels
documentation Improvements or additions to documentation

Comments

@postlund
Copy link
Collaborator

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
Copy link

cwttdb70 commented Sep 15, 2020

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
Copy link
Owner

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

@postlund
Copy link
Collaborator Author

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

@rospogrigio
Copy link
Owner

rospogrigio commented Sep 28, 2020

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
Copy link
Collaborator Author

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

@postlund postlund added the documentation Improvements or additions to documentation label Oct 11, 2020
@sajid2310
Copy link

Support for Multi gang switch with FAN.

@postlund
Copy link
Collaborator Author

Support for Multi gang switch with FAN.

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

@RobyDomo
Copy link

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
Copy link
Collaborator Author

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
Copy link

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
Copy link
Owner

@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
Copy link
Collaborator Author

@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
Copy link
Owner

Yes, I agree...

@rospogrigio
Copy link
Owner

@RobyDomo I created the PR #111 for the vacuum implementation. Please post the DPS dump there once you have it, so we don't flood this topic.
Thank you

@rospogrigio
Copy link
Owner

rospogrigio commented Oct 22, 2020

Updated 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.

  • DONE: 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.

  • 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.

  • DONE: 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.

  • DONE: 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.

  • 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.

  • DONE: Positioning handling for covers

  • IN PROGRESS: Improve documentation, translations in config flows, etc.

  • IN PROGRESS: Registration among default HACS integrations

  • IN PROGRESS: Improve support to lightbulbs

  • IN PROGRESS: Support to climate platform

  • IN PROGRESS: Support to vacuum platform

  • Easy set up of helper sensor, e.g. integration sensor that calculates kWh for used energy.

  • Introduction of utility sensors, e.g. Connection status error...

  • Introduction of a database of devices' presets for commonly used commands combinations, feedable by users.

What an incredible roadmap!

@postlund
Copy link
Collaborator Author

An incredible journey indeed!

@WizBangCrash
Copy link

Great journey indeed and you didn't even include "IN PROGRESS: Support for passive door/window sensors" :-)

@postlund
Copy link
Collaborator Author

Ok, that part might not be totally true 😉 But I'm getting closer. Been prioritizing bug reports lately. But will get back on that horse soon.

@Vismuthxxx
Copy link

Good time of day! how do I add a ZigBee wireless gateway? there is not a single line there is no gateway. Only binary_sensor, cover, fan, light, sensor and switch

@postlund
Copy link
Collaborator Author

@Vismuthxxx Not possible since it's not supported yet. There's already a request for it: #69

@postlund
Copy link
Collaborator Author

I will go on and close this issue now as I feel that it has served its purpose: give us a start. We have plenty of feature requests already and bugs to deal with. So no need for this.

@glorifiedg
Copy link

Any plans for IR controllers?

@postlund
Copy link
Collaborator Author

@glorifiedg This issue is closed now, but somewhat related to #159?

@galtamur
Copy link

galtamur commented Dec 8, 2020

Hello, I am experiencing this situation: I configured TuyaLocal component with four smartPlugs with current monitoring, and i implemented the template sensors to show the consumption in Lovelace.
It works fine, but from time to time, it looks like the data are not updated (like freezed); when I open on my iphone the SmarLife app and i go into the consumption page, I see number updated, and the are updated also in HA.
Did anyone else experienced the same problem? Any suggestion?
Thank you

@postlund
Copy link
Collaborator Author

postlund commented Dec 8, 2020

Hello, I am experiencing this situation: I configured TuyaLocal component with four smartPlugs with current monitoring, and i implemented the template sensors to show the consumption in Lovelace.
It works fine, but from time to time, it looks like the data are not updated (like freezed); when I open on my iphone the SmarLife app and i go into the consumption page, I see number updated, and the are updated also in HA.
Did anyone else experienced the same problem? Any suggestion?
Thank you

Here: #87

@geckom
Copy link

geckom commented Dec 23, 2020

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

Hope this might help - tuya climate device.

 dps: {
     '1': true,  -- power
     '2': 23,   -- target temp
     '3': 25,   -- current temp
     '4': 'DRY',  --- mode  DRY/HEAT/COOLOFF
     '5': '1',   FAN -  1 = low, 2 = medium. 3=high
     '19': 'C', = C or F
     '102': false,    -- Unknown - I suspect this is water tank is full
     '103': 3,     -- Current timer set (in hours)
     '104': false,  --Swing
     '105': 179,   -- Current Timer Countdown (in minutes)
     '106': 0,
     '110': '0'
}

@jmargallo
Copy link

Hello
Do you think the Support to Wifi Door Sensor platform will be soon?

I just installed this sensor yours () and even manually setting the deviceid and the local key ... I can't integrate it.
The rest of my devices yours without problem and very grateful

@Bohr80
Copy link

Bohr80 commented Dec 27, 2022

I agree with BrainStormer, it would be good be get all devices from Tuya IoT Platform. At the moment setting up Tuya IoT Platform doesn't work - gives error 1106: permission deny. At the same moment Tuya integration using the same IDs and passwords works perfectly fine.

That error is that the free month access is up and you need to extend the test period.

I don't think so, because it hasn't been a month yet since I've set my account on Tuya IoT Platform.
But thanks for that suggestion, I would probably wonder what is going on after a month. ;)

@avenger11
Copy link

Please add the support for Humidifier on the TODO list :)

@rtech73
Copy link

rtech73 commented Jan 5, 2023

Is there any plan to add support for their LED light strips? I just got one with TV sync and while the device is found and integrated, it indicates “not supported”.

@jonwestuk
Copy link

Please add the support for Humidifier on the TODO list :)

and if possible dehumidifiers - with the ability to set humidity level on the device, activate childlock, fan speed etc.

@abcben78
Copy link

Just install the latest update, try to install a sensor and it hang the whole Local Tuya Integration. Nothing works anymore, it was already strange that it not discovering anymore.

@rospogrigio
Copy link
Owner

Well that's really strange, I have received many positive feedbacks and I am using the new version myself with no issues at all.
Did you try restarting HA and/or reverting to the previous version of localtuya? Have you also tried to enable debugging (checking the new debug button) when adding the new sensor? Can you share the log messages?
Thank you

@abcben78
Copy link

abcben78 commented Jan 11, 2023 via email

@rospogrigio
Copy link
Owner

rospogrigio commented Jan 11, 2023

@abcben78 well, I had a lot of users who tested and they all gave positive feedbacks, so I guess there's something strange with some of your devices. The changes introduced with 5.0.0 are quite extensive but they don't justify all these failures.
You said you posted the logs but you actually didn't, so please retry.
Then here is how I'd proceed:

  • I'd revert to localtuya 4.x.x and check that everything works as before
  • then I'd remove the integration entirely, upgrade to 5.0.0 and start re-adding the devices one by one, starting with the most problematic ones, enabling the debug with the new button I added. Once we are able to add the device successfully the debug can be disabled for that device
    Send your logs in the meantime so I can check if there is some clear error.
    Thank you

@abcben78
Copy link

abcben78 commented Jan 12, 2023 via email

@rospogrigio
Copy link
Owner

Well... no. Tuya works via cloud APIs, localtuya uses a local socket to send commands directly. Also, there is a new protocol that Tuya is using that seems no-one was able to decrypt yet (maybe protocol 3.5? who knows). Of course everything that works in Tuya COULD work in LocalTuya but it has to be coded differently.

@rumlak
Copy link

rumlak commented Feb 22, 2023

Support for the wifi pet feeders would be a great addition

@TolianIPB
Copy link

Hi guys! I really want to see support for Zigbee network Getwways by IP in Local Tuya. It would be an awesome solution.
Something like this:
https://github.com/leeyuentuen/localtuya/

Your branch is very positive branch and you fix problems quickly.
Please tell me, is there any hope that Zigbee will appear in your branch?

@cloudbr34k84
Copy link

the ability to add entities to an already created device. You currently have to start all over again

@patrik-malina
Copy link

the ability to add entities to an already created device. You currently have to start all over again

+1

@wenstarner
Copy link

Hi, I have a DP ID of 3, which contains the speed of my Tuya fan (Breville AirDynamic).

I can see the value updating in the configuration window (if I manually set the speed on the fan itself, the value in the config window for the relevant DP ID will update).

However, when I create a number entity, the fan doesn’t change speed. The fan has speeds from 1 to 8, and even a simple change to ‘2’ does nothing. I have set the number entity type to String.

Does anyone know why this is the case? Perhaps number entities are not supported? Switches work fine for me.

Thanks!

@cloudbr34k84
Copy link

Number entities are supported but this is a fan. I think there is fan domain you can choose??

@cloudbr34k84
Copy link

Number entities are supported but this is a fan. I think there is fan domain you can choose?? Try playing with that

Screenshot_20230307-230744.png

@wenstarner
Copy link

wenstarner commented Mar 7, 2023

Thank you—I tried that, but it doesn’t work!

Even more interesting is what I found after some more testing:

  1. The number entity will READ the current fan speed (a number from 1 to 8, inclusive). So when I change the speed on the fan itself, the number entity updates in the logbook.
  2. I cannot WRITE a new number to the fan. The slider stays on the number I select, but the logbook shows no actual update. Also, I can see that the fan speed has not changed.
  3. An exception to Point 2: When I set the fan speed on the fan itself, adjusting the number entity slide up or down will put the fan into some kind of ‘0’ power state (seems to operate at the same power as Level 1). Strangely, when I go to add a new device while on this mode, Local Tuya reports for this DP ID the value that I manually set on the unit—so the slide changed the fan speed to low, but the unit doesn’t seem to register that it’s changed to the strange ‘0’ lower speed.

Anyway, I suppose long story short is: Does anyone know how I can get the number entity slider to successfully write to the unit? As it currently can read fine.

I’m new to HA so am happy to provide logs, but thought I’d ask this now as switches, etc. work perfectly fine. Thanks!

@lukiluki123
Copy link

Hi guys! I really want to see support for Zigbee network Getwways by IP in Local Tuya. It would be an awesome solution. Something like this: https://github.com/leeyuentuen/localtuya/

+1

@spanzetta
Copy link

Any chance to support directly this device?

make-all/tuya-local#638

It's a Wifi Water timer that works with Smartlife..

I asked the support at tuya-local, the author said it was implemented, but it's not true.. it doesn't work and when i asked help the answer was always generic..

I hope you can enable support for it.. all device pid (exported from tuya cloud) are listed on the above link

Thanks in advance

@GarfieldMZ
Copy link

Hey!
Is there any chance to get a "Pet Feeder" integrated (like this)

Thanks!!

@MikeLehnitz
Copy link

Hello, I would like temperature/humidity sensors (WIFI) to be integrated.

@ralvarez83
Copy link

Hi, I would like Smart Bluetooth Soil Tester Temperature and Humidity Meter to be integrated. A product example is this.

Thanks so much

@sommelierak111
Copy link

sommelierak111 commented Jan 31, 2024

Hi. Tuya makes Garage Door Opener CKM01-EU, (product category ckmkzq) logicaly its a short time connection relay with binary sensor. And this device may be used also as controller for electric mechanical locks on the doors.
Tuya addon integrates it to HA as "cover".
Need to support this device in localtuya. Minimal requirements are object state from sensor, + switch_on + switch_off.

@phelipebf
Copy link

Maybe we can start mapping DPs for some devices. I did this for Inkbird IHC-200 WiFi:

Sensors:
104: PV (current humidity)
106: SV (target humidity)

Mode:
115: 
- 1 = Work2 ON (Dehumidification)
- 2 = OFF
- 3 = Work1 ON (Humidification)

Settings:
102: Humidity Calibration
108: Dehumidification Delay Time
109: Alarm High Humidity Limit
110: Alarm Low Humidity Limit
117: Humidification Diferential Value
118: Dehumidification Diferential Value

UNKNOWN:
12: (number)
111: (boolean)
112: (boolean)
113: (boolean)
119: (boolean)

@Bluscream
Copy link

Maybe we can start mapping DPs for some devices. I did this for Inkbird IHC-200 WiFi:

Sensors:
104: PV (current humidity)
106: SV (target humidity)

Mode:
115: 
- 1 = Work2 ON (Dehumidification)
- 2 = OFF
- 3 = Work1 ON (Humidification)

Settings:
102: Humidity Calibration
108: Dehumidification Delay Time
109: Alarm High Humidity Limit
110: Alarm Low Humidity Limit
117: Humidification Diferential Value
118: Dehumidification Diferential Value

UNKNOWN:
12: (number)
111: (boolean)
112: (boolean)
113: (boolean)
119: (boolean)

we need this badly!

@cloudbr34k84
Copy link

Maybe we can start mapping DPs for some devices. I did this for Inkbird IHC-200 WiFi:

Sensors:
104: PV (current humidity)
106: SV (target humidity)

Mode:
115: 
- 1 = Work2 ON (Dehumidification)
- 2 = OFF
- 3 = Work1 ON (Humidification)

Settings:
102: Humidity Calibration
108: Dehumidification Delay Time
109: Alarm High Humidity Limit
110: Alarm Low Humidity Limit
117: Humidification Diferential Value
118: Dehumidification Diferential Value

UNKNOWN:
12: (number)
111: (boolean)
112: (boolean)
113: (boolean)
119: (boolean)

we need this badly!

How did you get inkbird connected to tuya?? I have the wifi pool thermometer but could get it to connect

@phelipebf
Copy link

How did you get inkbird connected to tuya?? I have the wifi pool thermometer but could get it to connect

Pair with Tuya Smart app and it will be available in the cloud through this integration.

@cloudbr34k84
Copy link

How did you get inkbird connected to tuya?? I have the wifi pool thermometer but could get it to connect

Pair with Tuya Smart app and it will be available in the cloud through this integration.

Mmm tried that.. wouldn't pair

PaulCavill pushed a commit to PaulCavill/localtuya that referenced this issue May 9, 2024
* rewrite add device manually message.

* Add 7000 Port listening and reuse port

* App broadcasting and improve data decrypt

* Add auto protcol in config flow

* and supported protocols in const

* Add node ID to const

* Add settings contexts

* Add support for SubDevices and 3.5[Hope] in pytuya core

* Fix sample template

* clarify CID context

* ADD Tuya const

* add explain error into config_flow

* Clarify Error_values when try to connect!

* Report errors values if happend in core!

* add node_id to common.py

* update config_flow with many changes in PR edit: 1

* remove debug message

* comment

* increase timeout to 8secs.

* revert increase timeout

* typo

* fix a bug when import template [need rewrite dev_config)

* rework on helpers

* update dps function version uses constant versions

* remove duplicated function

* cleansup codes

* Fix unique IDs already exists. solve_issue_1 in PR

* Rework config_flow actions Menu instead of radiobox

* Spaces on Cover Commands Labels

* Rename from `LocalTuya integration` to `Local Tuya`

* rewrite translation to menu init

* remove `CONF ACTION` and adjust `CONF CLOUD`

* add `data_description` en lang to template step

* Fix devices don't comeback after adding new device

* remove unnecessary contect func

* remove unnecessary contect func

* fix entity_category and some cleans

* clean up codes

* cleans up helpers

* for futrue things.

* pump version

* Give Docs when installing new integration.

* cleans up repo
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests