It works!!!
Thank you for sharing!
Could you tell me how you did that? I have same problem and localtuya and tuya-local not refresh every x seconds in my case.
Looks like my subscription on Tuya IOT has expired. How do you guys get this to work? The cheapest option for payed subscription is 25000 dollar?? What am I doing wrong?
Edit: found extending the trial option 
Chipping here in again, what I found to be the most reliable is to use the tuya-local integration to have all the sensors and entities easily available as I suggested earlier. When you have issues with updating even then, I suggest to add the localtuya integration with the dps set to 10 seconds (and using the trick of @matt3003 for 3.4 devices) and have the two integrations work in parallel, whilst hiding the entity of localtuya. This should solve the updating issue.
I stopped foolin around with the Tuya plugs and ordered these:
Smart Power Plugs:Zigbee Smart Plug with Measure and Timer Function, Tuya App Control, Push Notification, Zigbee Hub Required, 16A Zigbee Plug,Compatible with Alexa and Google Home,Pack of (4 Pack) : Amazon.nl: DIY & Tools
Works perfectly and gives live data!
It has the following sensors (top 4 are my own Helpers for periodic data).
are you setting that property through Local Tuya ? calling the api externally to HASS ?
Thanks a LOTTTTT it works!
1 Like
Hi Matt, thanks for your contribute. I’am spending a lot of time on this whitout a solution. I tried your fix but unfortunately it doesn’t work for me. Do you have any suggestion ? anything else to check ?
Somehow this worked…
I wonder if they didn’t change it because it’s not exactly reliable? Anyway, it saved my smart plug from being a paper weight lol
I have 2 kind of plugs. The EU reports automatically every 5 minutes. The US only report when I open Tuya app. I think this is a firmware/manufacturer problem.
EU plug
The US plug
I found a link somewhere also said US plug doesn’t work.
I have only EU plugs and had the problem on some plugs. As Matt said, probably version of firmware… 3.3 vs 3.4, etc
I use latetly offical tuya addon for HA, and tuya-local (not localtuya which is different), with good results… only one plug from certain brand is giving problems of turning as unavailable sometimes.
@Va-na : Sorry that it didn’t work for you - appart for some obvious checks (Did you restart HA after the edit ? Did you edit the correct _init .py ? (Carreful there are two of them - one in the root of the “localtuya” folder, and one in the “pytuya” folder - that’s the one you need to edit, the second one) I am not sure I can help.
(Do you know if your device(s) are 3.3 or 3.4 firmware ?)
To everyone else : just for information, after 7 months of using my “fix”, it still works, perfectly (no “unavailable” problems, it updates at the interval I specified, and after checking my electricity usage bills and details, it’s exactly the same values as measured in HA, so it doesn’t “miss” any power values - or at least not enough to me measurable).
(For more information : I mostly use “ANTELA” brand plugs - EU ones, and a few TONGU (or other brands but same device) TO-Q-SY1-JWT
The TO-Q-SY1-JWT are all 3.4 - the ANTELA EU plugs are 3.3 or 3.4 (the first one I purchased in october / december where 3.3, but since the begining of the year 2024 all the one I received seem to have the 3.4 firmware)
Ok more information about “my” “fix” of including “3.4” in the list of supported firmwares for the “update_dps” function in localtuya.
I was curious if I should say something to the localtuya integration creators on github to ask them if they should include 3.4 in the update_dps function back in january, but I thought it was so obvious it was likely just a question of time - they would obviously do it so I would not bother them (I don’t even really know how to do it “the right way” lol).
But this thread got me curious, so I went to github and looked at the code for the update_dps function, and … they did it already … more than 18 months ago ?
(the line 820 is already “if self.version in [3.2, 3.3, 3.4]:” - you can go look it up https://github.com/rospogrigio/localtuya/blob/87d61eea6f4189bf1dc01614534e1fff84db4a7f/custom_components/localtuya/pytuya/init.py - the change is dated Jan 18th 2023
So it’s not “my” fix at all lol (not that I thought I was the only one who found and edited the line, but it’s official : they already did it before I even bought my Pi and was confronted with the “bug” of 3.4 devices not updating
But … my install of HA was end of 2023, then I reinstalled everything on a new Pi 4 in march … and I still had to edit it myself …
And less than a month ago, I installed a new HA on a new Pi 4 on a new location, and still … the update_dps did not include 3.4 …
So I just checked a few minutes ago - made a completely new install of HA, then SSH addon to install HACS, then install HACS, then install localtuya, then File Editor, and I used it to go look at line 820 and … the update_dps function does NOT include 3.4 !!
So I checked if maybe HACS directed me to a different depot of localtuya - but no, it’s the “rospogrigio” one, the same one I just checked on github - it should include 3.4 in the update_dps function !
I’m relatively new to HA and HACS, and I only ever used HACS to install localtuya, so maybe there is something I don’t understand - can someone explain it to me ? It looks like HACS doesn’t install the latest version of localtuya - or at least not the latest version of the “pytuya” part (the custom_components/localtuya/pytuya/__init__.py file)
Bottomline : localtuya SHOULD update 3.4 devices at the specified interval out of the box - the code on github has been updated more than 18 months ago - you should never have / had this problem with localtuya … but for some reason if you install localtuya from HACS, you don’t get the latest version of the code.
Can someone tell me if they know why ? Is it normal and I am just not understanding how HACS install integrations and get the last version of them, or should I mention something to someone ?
Hi Matt. Sorry, not answering your question. But was wondering if you have tried Tuya-Local from hacs (not localtuya). The one here:
…it works for me. Probably with firmwares 3.2, 3.3 and 3.4 (at least all my devices are updating), and last version is from last month. Seems better updated.
It will be good to know from you, that knows this problem deeply, if Tuya-Local works for you out of the box. It will help others to know which hacs addon to install preferably.
Hi @user512.
I actually tried tuya-local first, but it was back in the end of 2023.
Back then I was discovering HA for the first time, and I just got 2 or 3 tuya devices for the first time too.
I couldn’t make it work the way I wanted, but back then I naively thought you could get the total power meter value from those tuya “power meters”.
And I could not understand why the “add_ele”, which is DP17 and was supposed to be the accumulated power usage in kWh (you know, the “meter” part of my “metered” device - the reason I bought the device in the first place) was NOT CHANGING.
Then by playing directly with pytuya and python, I FINALLY UNDERSTOOD why it didn’t work, and COULD NEVER WORK because of the way tuya and HA are.
(if someone wants more details I can explain, but essentially when you query d17 you get the total amount of kWh SINCE THE LAST TIME DP17 WAS UPDATED. - so 99% of the time it stays the same, for example 100, which means “+0.1kWh”, and HA interprets this as “the meter value is 0.1”)
So I finally accepted the fact that even thought thoses devices have a memory, and can store data in it, and can measure the power usage, and where called “meters”, they didn’t store the power used in kWh in any usable way.… grrrrrr …
So I resigned myself to use the integral integration to create “meters” based on the power values (D19).
But then I discovered this thread’s focus : I wasn’t getting up to date values for most of my devices (3.3 and 3.4 alike).
Then on one forum someone talked about localtuya and how there was an “interval” option to force the update of the power values - I thought I would try it.
I installed it, and instantly my 3.3 devices were respecting the interval ! I was finally able to monitor my power usage with my devices … except for a couple of them.
Then I realised those were the 3.4 ones - came to the conclusion that localtuya was not forcing the update of the 3.4 devices the same way as with the 3.3 … and here we are.
– (sorry for the long rambling that doesn’t really answer your question) –
To answer your question : I will test with tuya-local, out of the box, and my 3.4 devices that have the potential issue.
I will try to do it tonight or tomorrow and I will tell you
Ok so I had the time so I tested it.
Fresh new HA install, on a Pi 4. Installed SSH addon → Installed HACS → Installed tuya-local (the one you linked).
I only tested it with two of my tuya devices - one 3.4 eu ANTELA plug, and one TO-Q-SY1-JWT TONGU rail device (also 3.4) - that I know won’t update with localtuya without the update_dps fix
Well … It’s not great :
- The Power value is updated about every 60 sec (almost exactly) if the Smart Life App is closed
- The Power value is updated about every 30 sec if the Smart Life App is open
And sometimes, at random, it takes a lot more than the 30 / 60 sec
So … for me it would not be fast enough at all to be accurate.
And tuya-local has less options - specifically, no way to ‘force’ an interval (I tried the “poll only” option on the devices - no change)
Also - just for information - when adding the device, the process fails if I leave the protol to “Auto”. I had to manually select “3.4” for my 3.4 devices.
So for me, considering that I can get it to work with localtuya by editing the one line of code, and then I have a system where my devices can be polled at a controllable per-device interval, and with tuya-local I get one update per 60 sec - which would result in totally false energy usage totals … I will stick with localtuya + edition of one line
(+ if you want you can just download the folder on github and paste it in “custom_components” - no need for HACS or SSH addon or File Editor, no need to edit a line of code - you would just need a way to paste it in the config folder - so maybe just Samba Share ?)
But to sum up, while in my case it’s clear localtuya + make sure the update_dps function includes 3.4 is CLEARLY the way to go, I suspect it will be more on a case by case depending on the devices …
My ANTELA and TONGU devices clearly work ok with pytuya (which is the python library to talk to tuya devices) - which is used by localtuya - and they actually responds when they are polled with the update_dps function that “forces” them to. And clearly they’re not very talkative if you don’t force them to talk (they are shy lol). Maybe some other devices won’t be and will send the data every few seconds even if not forced to.
I can’t be sure (I only took a very quick look in the code on github) but tuya-local doesn’t seem to use pytuya.
So chances are, if your devices work well with pytuya → localtuya will work well
And it they don’t, tuya-local might work more reliably.
You are not supposed to use both at the same time (they would “talk over each other” because the tuya devices can only speak to one other device at a time), but … I know some people do it, and it can work …
For example, I just tried : I installed localtuya on top of my test installation - + file editor and edited the update_dps line - then added the two devices in localtuya, with the “update_dps” set to 2 sec.
So, now, localtuya sends a “what is the power value” to the two devices, every 2 seconds.
And so, every 2 seconds, the devices send a “the power is xxx” to HA
And this message is picked up by both localtuya and tuya-local, because they are both listening for tuya protocol messages.
So right now, my tuya-local entities are updated every 2 seconds … because its localtuya that sends the requests.
(Important note : for this to work - for tuya-local entities to be updated by messages initiated by localtuya - you need to make sure the “poll only” option for the device in tuya-local is not checked - if it’s checked it doesn’t seem to “process” values that it didn’t ask for itself)
(in theory, if tuya-local and localtuya tried to send a message to a device at exactly the same time, at least one of the requests would be lost. But considering they seem to repeat their requests a lot, and only every few seconds, I think it could work long term)
That makes me think that you could, if you really wanted to use tuya-local, and not have to install localtuya, and have every devices configured in both etc … you could in theory use a python script, using pytuya, to just send a “what is the power value” (basically sending a “update_dps” command) every few seconds, all the time, to a list of all your devices, and tuya-local would receive the values that comes back because the devices are now forced to respond and be more talkative.
With your tuya-local install that works well with your devices, at what interval approximatively are the values updated ?
1 Like
You are completely right… and my installation behaves exactly the same way. It takes 60 seconds to update (of course without app open, or it will be useless).
…this I didn’t noticed. I suppose I haven’t been so meticulous to check, but probably happen to me too.
Yes. I thought maybe I did something wrong, but if that happens to you too… it should be some bug on tuya-local.
60 seconds. They keep working for months without problems. Probably a faster update (probably, instantly when value changes), it will be better but for necessities right now, it is enough.
But if for some reason I use a device that needs a faster update, I think I will go with your method. The only benefit is that tuya-local works out of the box, and is something less to have in mind when you update addon, etc. (that I suppose it will break the line).
In any case, I suppose the best would be to have localtuya being updated with the ‘real’ last version with the 3.4 devices contemplated. Hope somebody around can explain why version on github has the line updated, and hacs addon is not downloading that release.
Thanks a lot Matt for your complete test.
You’re welcome.
I created a separate topic about why HACS is not installing the latest version of the github code (https://community.home-assistant.io/t/why-is-hacs-installing-an-older-version-of-localtuya-that-the-one-on-github/761934)
We will see if someone can tell me if I am missing something, or if we should contact HACS coders / localtuya coders / github.
Hopefully, in the near future the problem will be solved, and localtuya will then work out of the box (and respects the update intervals).
Have a nice day
1 Like
Ok so for everyone still interrested - from the other thread I created I got my answers:
-
It’s normal to not get the updated update_dps function if you install localtuya from HACS, because the latest version released (5.2.1) was BEFORE the update - so the code we can see (and download) on github has not been RELEASED (as an OFFICIAL RELEASED VERSION) yet
-
There is a fork of localtuya that is updated way more frequently (every month or every two months) and has the fix included - it’s this one : https://github.com/xZetsubou/hass-localtuya (Thank you @reste_narquois ! )
(You can add the repo to HACS if you have it installed by clicking this link : https://my.home-assistant.io/redirect/hacs_repository/?category=integration&repository=hass-localtuya&owner=xZetsubou ) -
(EDIT : and … a few hours ago the rospogrigio fork of localtuya - the one you get by default from HACS without having to touch anything - released a new version - 5.2.2 - and it has the 3.4 fix, so, as of now, the ‘original’ localtuya (the one HACS directs you to install) works out of the box too.!! Yeah !! )
And I tested it - this version (the xZetsubou one) works OUT OF THE BOX (not surprising considering the update_dps function has the 3.4 fix - so the power values are updated at the interval you ask for) - so I highly recommand it for a new user, or if someone needs to reinstall HA - I have so many tuya devices already configured that I won’t make the switch YET, but when / if I need to reinstall, I will definitely use this fork
(It’s up to date - so for example with 3.5 devices starting to appear on the market it would support them, and with a new version every month or two any new fix or feature should be included rapidly. I also like how this fork lets you choose if you want to manually configure the entities, or let it do it automatically)
(There are a few differences from the original that I noticed right away, but they are details, and those differences are not necessarily bad, just needs to know - like how it names entities - like if I add a tuya device “MY TUYA DEVICE” and then configure the entity “POWER”, it names the entity “sensor.my_tuya_device_power” - which is not bad - great actually, but you need to know that, because it doesn’t on the rospogrigio one (the ‘original’ one), so I created a device “MY TUYA DEVICE”, and configured the entity (dp19) as “MY TUYA DEVICE POWER”, and that ends up with an entity names “sensor.my_tuya_device_my_tuya_device_power” lol)
So to sum up : use this fork : https://github.com/xZetsubou/hass-localtuya - Works out of the box - (with the power values updated at the interval you configure) and updated frequently (last version from july) (Again, thank you @reste_narquois) / EDIT : or re-try the “original” rospogrigio one - the one HACS include by default in its repos, the new version 5.2.2 (from today) should update the power values correctly)
1 Like