home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
71.15k stars 29.82k forks source link

Tuya Integration - Status of bulbs/switch/plugs not refreshed or slow. Remains stuck on ON or OFF status for long minutes #37880

Closed StefanoGiu closed 3 years ago

StefanoGiu commented 4 years ago

The problem

The refresh of tuya device status (bulbs, switches, plugs) doesn't act immediately but sometimes it takes also half an hour. If I switch off a light... it's showed still as turned on for several minutes. Despite, if I invoke the discovery api at https://px1.tuyaeu.com/homeassistant/skill, the device status looks correct, but HA is not able to update it in the time fashion manner. If I restart HA, the statuses gets updated properly. If I try to run force_update service from the HA UI, I'm not able to get the status refreshed from HA. So to summarize:

Environment

Traceback/Error logs

From the logs, I can read a lot of...

2020-07-15 13:35:38 DEBUG (SyncWorker_4) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke

2020-07-15 13:35:38 DEBUG (SyncWorker_0) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:38 DEBUG (SyncWorker_2) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:39 DEBUG (SyncWorker_3) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:39 DEBUG (SyncWorker_4) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:39 DEBUG (SyncWorker_0) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:39 DEBUG (SyncWorker_2) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:39 DEBUG (SyncWorker_3) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:39 DEBUG (SyncWorker_0) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:39 DEBUG (SyncWorker_4) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:40 DEBUG (SyncWorker_2) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:40 DEBUG (SyncWorker_4) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:40 DEBUG (SyncWorker_3) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:40 DEBUG (SyncWorker_0) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:41 DEBUG (SyncWorker_2) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:41 DEBUG (SyncWorker_4) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:41 DEBUG (SyncWorker_3) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:41 DEBUG (SyncWorker_0) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:41 DEBUG (SyncWorker_2) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:41 DEBUG (SyncWorker_4) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:41 DEBUG (SyncWorker_3) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:41 DEBUG (SyncWorker_0) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:42 DEBUG (SyncWorker_2) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:42 DEBUG (SyncWorker_4) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:42 DEBUG (SyncWorker_3) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:42 DEBUG (SyncWorker_0) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:43 DEBUG (SyncWorker_3) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:43 DEBUG (SyncWorker_2) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:43 DEBUG (SyncWorker_4) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:43 DEBUG (SyncWorker_0) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:43 DEBUG (SyncWorker_2) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke 2020-07-15 13:35:43 DEBUG (SyncWorker_4) [tuyaha.tuyaapi] control device error, error code is FrequentlyInvoke

probot-home-assistant[bot] commented 4 years ago

tuya documentation tuya source (message by IssueLinks)

probot-home-assistant[bot] commented 4 years ago

Hey there @ollo69, mind taking a look at this issue as its been labeled with an integration (tuya) you are listed as a codeowner for? Thanks! (message by CodeOwnersMention)

ren9821 commented 4 years ago

I had the same problem.

StefanoGiu commented 4 years ago

the same problem.

Had? Is it solved now?

ren9821 commented 4 years ago

No solution, it is estimated to be an integration problem.

------------------ Original ------------------ From: StefanoGiu <notifications@github.com> Date: Thu,Jul 16,2020 0:24 AM To: home-assistant/core <core@noreply.github.com> Cc: Shwan <851617700@qq.com>, Comment <comment@noreply.github.com> Subject: Re: [home-assistant/core] Tuya Integration - Refresh of bulbs/switch/plugs states not refreshed or slow. Remains stuck on On or OFf (#37880)

the same problem.

Had? Is it solved now?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

ren9821 commented 4 years ago

Do you have a solution?

StefanoGiu commented 4 years ago

No I don't have any solution. Tuya has a very fast cloud solution and with Google Home voice commands it responds immediately. The same with Smart Life app.

The problem is within HA and maybe the dedicated API for HA.... even if I tested the API with POST web calls and it seems to be reliable (exact info of devices status) and fast.

StefanoGiu commented 4 years ago

I also have bunches of...

2020-07-16 23:47:42 WARNING (MainThread) [homeassistant.helpers.entity] Update of switch.scrivania1 is taking over 10 seconds 2020-07-16 23:47:42 WARNING (MainThread) [homeassistant.helpers.entity] Update of switch.salone3 is taking over 10 seconds 2020-07-16 23:47:42 WARNING (MainThread) [homeassistant.helpers.entity] Update of switch.salone2 is taking over 10 seconds 2020-07-16 23:47:42 WARNING (MainThread) [homeassistant.helpers.entity] Update of switch.viale is taking over 10 seconds 2020-07-16 23:47:42 WARNING (MainThread) [homeassistant.helpers.entity] Update of switch.condizionatore is taking over 10 seconds 2020-07-16 23:47:42 WARNING (MainThread) [homeassistant.helpers.entity] Update of switch.salafuori is taking over 10 seconds

StefanoGiu commented 4 years ago

Hello @ollo69,, did you check this issue?

ollo69 commented 4 years ago

This is duplication of issue ##36744. Try for the moment to install tuya_custom and report if it solve your issues,

StefanoGiu commented 4 years ago

I tested this fix...

def device_control(self, devId, action, param=None, namespace="control"): if param is None: param = {} response = self._request(action, namespace, devId, param) if response and response["header"]["code"] == "SUCCESS": success = True if action == "turnOnOff": device = self.get_device_by_id(devId) if param["value"] == "1": device.data["state"] = True else: device.data["state"] = False else: success = False return success, response

It's not working...

ollo69 commented 4 years ago

This is not what I suggested....

StefanoGiu commented 4 years ago

I'm trying the custom component now...

StefanoGiu commented 4 years ago

I installed the custom component. The problem is the same... the refresh of the status is not happening...

nao-pon commented 4 years ago

@StefanoGiu The reason why the changed status other than HA such as smart life application is not reflected immediately is in the Tuya API, and there is nothing that we who are using the Tuya API can do. Tuya Custom integration should now reflect without any issues if you change the status in HA.

StefanoGiu commented 4 years ago

Did you read my initial comment? I can read the updated status if I invoke the APIs.... manually...

nao-pon commented 4 years ago

Currently, the Tuya API limits access frequency, frequently returns an error in API calls, and the latest information cannot be obtained. What complicates the problem is that the timing of returning errors is random rather than constant. Reducing the frequency of API calls does not help.

StefanoGiu commented 4 years ago

So there is no solution? What about local tuya? Does it need a fixed IP ?

nao-pon commented 4 years ago

@StefanoGiu There is no documentation for HA-only APIs, and I don't know what kind of command is accepted and what kind of response is obtained other than the current implementation. If a general-purpose API is available, I think it's better to change it there. Do you have information about general-purpose API usage?

nao-pon commented 4 years ago

Local Tuya needs a local key for each device in addition to the device ID. HA integration may not be easy unless there is a way to get it automatically.

StefanoGiu commented 4 years ago

I have local key and device ID... but I cannot get the devices to obtain a fixed IP, cause I have 3 range extenders for Wifi

StefanoGiu commented 4 years ago

Is it possible to create a custom api with this? https://docs.tuya.com/en/iot/open-api/quick-start/quick-start1?id=K95ztz9u9t89n

nao-pon commented 4 years ago

I haven't taken a closer look at Local Tuya. The problem is compounded if a fixed IP is required.

StefanoGiu commented 4 years ago

I also explored the tuya convert... but then you lose the benefit of voice command via Google Home speaker...

nao-pon commented 4 years ago

Hmm. However, if it is necessary to reflect status changes other than HA in HA in real time, it may be necessary to consider moving to Tasmota or replacing the device with Meross, eWelink, etc. at present.

It is very disappointing...

frenck commented 4 years ago

@StefanoGiu I've removed your last comment. Posting those kinds of things is not allowed. Please reframe from doing it again anywhere in our community.

Thanks 👍

crackers81 commented 4 years ago

Tuya_custom worked for me. Now the status changes instantly.

moedaug commented 4 years ago

Funny Thing, afterupgrading to beta 0.113, the tuya integration works fine for me.

ollo69 commented 4 years ago

Funny Thing, afterupgrading to beta 0.113, the tuya integration works fine for me.

This is expected. New HA release use new version of TuyaHA library that partially fix the problem, but refresh of device status will be worst than tuya_custom for the moment.

moedaug commented 4 years ago

Hmmm, it works just as fast as it used to for me. ( or could be that I find anything faster than 5 mins to be fast !) Great work ! Thanks Ollo for all you do ! Much appreciated ! You too Nao-Pon

ollo69 commented 4 years ago

Just to give right credits, we must also thanks @estebanz01 that release first PR in TuyaHA, @PaulAnnekov that maintain TuyaHA library and all the community that give contribute to fix and test this issue with all possible solution.

StefanoGiu commented 4 years ago

I installed the custom component again, and the situation seems to be improved now!! Well done...

I still have the following issues:

Are you planning to solve those issues too?

Now send commands to device and HA status update is faster, but still takes like 10 seconds or more... will this time improve somehow?

moedaug commented 4 years ago

Sorry, yes.Thanks to @estebanz01 ,@PaulAnnekov and the rest of the Hassio folks that contribute to this awesome piece of software. Without all of you I would be still using manual timers and switches !

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

StefanoGiu commented 3 years ago

The issue is still there

estebanz01 commented 3 years ago

This one is going to be fixed once latest changes in the tuya integration gets released.

Erickclee commented 3 years ago

Issue is still there, i am still switching back to custom tuya.

ZoltrixGFC commented 3 years ago

Yes I've also came across this issue recently, as mentioned here: https://community.home-assistant.io/t/physical-switch-not-working-but-works-in-home-assistant-gui/273915/9 and here https://community.home-assistant.io/t/my-grid-connect-lights-are-working-even-though-they-are-in-tuya/149229/12

alienator88 commented 3 years ago

Yes I've also came across this issue recently, as mentioned here: https://community.home-assistant.io/t/physical-switch-not-working-but-works-in-home-assistant-gui/273915/9 and here https://community.home-assistant.io/t/my-grid-connect-lights-are-working-even-though-they-are-in-tuya/149229/12

I'm also seeing the same issue as your first link. Physically turning on switch does not update the state of the switch in the HA UI.

ollo69 commented 3 years ago

I'm also seeing the same issue as your first link. Physically turning on switch does not update the state of the switch in the HA UI.

Refreshing status from Tuya take long due to TuyaAPI limitation, cannot be polled more frequently than every 600 seconds (10 minutes). There is no way to fix this in HA integration and when you change status directly on device or using Tuya phone app you have to wait 'till 10 minutes before status is updated in HA. There is no fix for this!!!

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

StefanoGiu commented 3 years ago

Issue still not solved...

ollo69 commented 3 years ago

@StefanoGiu,

as already explained in previous post, issue is related to API behavior and cannot be resolved by integration, so maintain this issue open does not make sense. Try writing to Tuya if you want to try a solution.

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

nao-pon commented 3 years ago

Here's the solution in my case.

I gave up the integration with Tuya API. And for devices that can be flashed with Tuya Convert, the firmware was rewritten with Tasmota or ESPHome. Devices that cannot be flashed with Tuya Convert have been migrated to LocalTuya.

These Tuya devices are controlled within the LAN, allowing for full control and delay-free status acquisition.