Energy monitoring not refreshing

[AdmiralStipe]

Energy monitoring sometimes refreshes the very second the switch toggles, but sometimes it doesn't refresh at all. Heater in the smartplug is running, but the current and current consumption show 0, or vice-versa (heater is off, but the consumption shows 10A / 2300W). Restarting HA may or may not help resolving it (cca 50% success rate).

Additional issue for me: status changes (from physical buttons) are not instant, instead they take from 10 to 30 seconds (as before the last release).

System Operating system Raspbian GNU/Linux 10 (buster) on Raspberry PI 4B Docker version 19.03.13

Supervisor version: 247 Host system version: Home Assistant 0.116.3, running on Raspberry Pi 4B in Docker (Supervised install)

[postlund]

Make sure you are running version 3.0.0 of this component. All versions prior to that polls the device every 30s (I think it's every 60s for 1.2.0 and earlier). That makes it quite unreliable.

[AdmiralStipe]

I AM using the latest version, but it doesn't solve it... I was hoping this one would solve it, as it didn't work well before :)

[postlund]

Can you enable some logs and provide us?

[AdmiralStipe]

Which logs do you have in mind, HA general logs or plugin specific? If plugin specific, how do I enable them?

[postlund]

The ones for localtuya I would say. Should be something like:

logger:
  default: warning
  logs:
    custom_components.localtuya: debug

[AdmiralStipe]

Done... I kept it running for a few minutes and tried to switch on and off some of the plugs. Without changing anything, the detection of switch now occured almost instantly (regardless of software switch or physical button), but the consumption still does not work (at least most of cases). What I have found out furthermore is, that the consumption status changes the very second I open the Consumption page on my phone in original TuyaSmart app - looks like the app somehow forces or pushes the consumption status change. I'm not sure if you will be able to see that in logs, but one plug also changes the consumption status with the change of On/Off state, and the other two plugs did not (well, at least until I opened the TuyaSmart app on my phone). Just to add, all of my plugs are the same model (named simply Robaxo or Robas??? but using TuyaSmart and/or Smartlife android app).

Shall I post the log here (privacy concerns because of IP number, MAC adresses, ID's,...) or shall I send it to some email address?

[postlund]

You can send the logs to me by email, probably better from privacy perspective 👍

[AdmiralStipe]

Just to make sure... did you receive my mail with the log and is the log long enough? I sent it to the mail address from your profile...

[postlund]

@AdmiralStipe Ah, yes, sorry for not givning any feedback. I have received it and will have a look at it ASAP.

[AdmiralStipe]

I sent you an e-mail with more detailed description, as I'm afraid, I didn't explain my issue properly. Let me continue with my thinking here: If I understand the log file correctly, the Tuya device reports status change by itself and localtuya only interpretes it. So, I see, that all my Tuya devices report change of state (On/Off) with the change of dps 1 (True/False) correctly and on time. However, when the dps 1 changes, I expect, that also dps 18 and dps 19 change (the current starts/stops flowing and the consumption of energy starts/stops). But in the device's status update there is only dps 1 and the time of change, but the dps 18 and 19 are missing! They are sometimes (but rarely) reported a few seconds later (this time only dps 18, 19 and 20, there is no dps1, as it has been reported before). However, dps 18 and 19 are reported the very same moment as I open the TuyaSmart app on my phone and go to Consumption page. From that I understand, that the Tuya app knows how to demand or force that report. So, would it be possible to implement a toggleable setting (obviously only my plugs need it :) ), which would request status of dps 18 and 19 (and possibly 20) from the device immediately whenever the dps 1 changes?

[AdmiralStipe]

So, If you don't mind I would like to try to fiddle with the code myself a little bit (I'm no programmer, but I can do some light customisation stuff). I would like to try to force my smartplugs to send full status report (all available dps) whenever the switch status (dps 1) changes. Can you give me two hints, so I know where to start:

1. which part of plugin (which file and roughly which line) takes care of inital status query (I understood that at startup the plugin requests full status report for all dps from the smartplugs)?
2. which part of plugin (again, which file and which lines) interpretes the received dps data? Thx in advance.

[nqkdev]

I got the same issue. Any progress on this? :)

[postlund]

I will try to get back on this horse soon, but I have a few other matters I need to attend first. @AdmiralStipe I will try to give a short explanation once I'm done with what I'm working on.

[MarlevPy]

I got the same issue as well. While I wait for the pros I can appreciate the good work you're doing with this integration! Big thanks and good job!!

[michel130]

I have exactly the same issue! Hope this gets resolved soon. Keep up the good work :)

[postlund]

If anyone has any idea on how to move forward, feel free to try them out. I don't have any clues at the moment😕

[postlund]

@AdmiralStipe OK, so, fiddle away and see what happens 🙂

The initial status update (where an entity requests the state of all datapoints) is done here:

https://github.com/rospogrigio/localtuya/blob/f3cfde030837e942b1c2b67ee512694106a308fc/custom_components/localtuya/common.py#L150

Whenever a status update is received from the device (by pytuya), this callback method is called:

https://github.com/rospogrigio/localtuya/blob/f3cfde030837e942b1c2b67ee512694106a308fc/custom_components/localtuya/common.py#L186

The status variable passed to the method contains the value of a known datapoints so far. So you will not be able to know if "1" changed at this point as the value of individual datapoints are not exposed like that.

It's also worth knowing that all this logic is handled by an instance of TuyaDevice. Each physical device has one instance of that class used to communicate with the device. Each entity has access to it in case it needs to send something and it is also responsible for telling each entity when datapoints changes to they can reflect upon that. The status_updated method is called in each entity class associated with a TuyaDevice whenever one or more datapoint change.

https://github.com/rospogrigio/localtuya/blob/f3cfde030837e942b1c2b67ee512694106a308fc/custom_components/localtuya/common.py#L296

It's of course possible to hook directly into pytuya and fiddle around, but the external interface is what recommend that you use. My last two cents here are that I don't think it's gonna work to request all datapoints at this point as I believe that it will just respond with whatever has already been reported. But who knows.

[AdmiralStipe]

Oh, I see... I thought I will be able to detect whether only dps1 or also other datapoints are included in a variable.... Well, I'm quite stubborn so I'll try to figure out something anyway. I will very likely fail (as I said, I'm no programmer), but I don't wanna give up without a fight :D

[postlund]

It's possible to do that from within pytuya, but I changed it to keep a cache of every DP and just pass that along to the listener because of some problems we had. Can't remember which issue number it was related to now. But that's how it works currently.

[makkie2002]

I think the issue is that the device does not automatically report changes to any of the “measurements” like voltage, current and power. This is logic as these values change very often and would otherwise flood the communication channel. Probably we need to actively poll these values from the device (e.g. every 10s). No idea how to do it though. I however know that other devices in Home Assistant allow to define a polling interval in their configuration.

[AdmiralStipe]

I tried a few different things and I failed, as expected :). This level of coding is a total overkill for my level and all I managed was to completely kill the code a couple of times (all Tuya plugs unavailable and the localtuya could not be reloaded :) ). So I guess @makkie2002 is right - to make this work , the code should actively poll the selected additional values 18, 19 and 20 (of course only if the plug is On) on a predefined interval, but at the same time rely on async for immediate status change reporting (for dps1, it's working great and really instant since async implementation) . Unfortunately I'm not able to write this in a code. @postlund, is ti even possible to have both ways (async and selective polling) active at the same time?

[postlund]

@AdmiralStipe It's possible, I made a prototype in #117. When adding a sensor, you can specify a poll interval in seconds. At every interval, the current value of the datapoint used by the sensor is requested by setting it to None. This is a small quirk in the firmware, as nothing will happen with the datapoint but it will trigger a status update containing only the value of the specified datapoint.

Feel free to try this out, maybe it can help us getting further (it's not a complete solution, just a PoC). You will need to remove and re-add and previous devices having a sensor entity for this to work.

[AdmiralStipe]

Tried it with great hope and expectations :), but unfortunately my report is not so cheer. Everything behaved completely the same as before. I followed your instructions and completely removed previous devices, added them once again (through config, not yaml), added sensors, added poll time of 10 seconds, restarted and started testing. Sometimes the current and power changes have been reported, sometimes (mostly) not. Switch status is again always reported correctly and on time. I'm starting to think that I might just have crappy plugs which behave badly. I use these. Attached you can check the latest log (timed simulation). From privacy reasons I changed all seven plugs id's from their original to 11111111111111111111 through 77777777777777777777. Maybe just a few additional words of comment to it. I started the simulation (switched the plug on) at 00:50:00. The heater started heating immediately, but as you can see, the current and power reported remain 0 through the following 10 sec polls. At 00:51:00 I opened TuyaSmart app on my phone for this particular plug and that forced report of the correct current and power (because of the app, not the poll or self report). At 00:52:00 I switched the plug off (so also current and power should be 0), but the current and the power remained on previous values through following polls. At 00:52:00 I again opened TuyaSmart app and again the changes of current and power (both 0) have been forced reported. So, it seems to me, that my plugs are only obeying the commands from original Android app and not localtuya :(. I'm getting more and more attracted to flashing Tasmota...

log1.txt

[postlund]

I was kinda expecting that result. Found this issue which sounds exactly what you are experiencing:

https://github.com/codetheweb/tuyapi/issues/272

However, it was closed with the "solution" to kill the app and never open it again. Not sure that makes any difference... Try to put some additional effort into sniffing the app traffic with be a good step. Another thing that I would personally recommend trying is to set up a developer account at tuya and re-pair the device that way (that's how I do it). This will prevent you from using smartlife though, but I wouldn't be surprised if it worked.

[AdmiralStipe]

I agree, sniffing traffic and finding out what exactly happens when the app demands status update would be good - unfortunately I don't know how to perform it effectively... I've heard of Wireshark and similar stuff, but I don't have an idea how exactly to set everything up and furthermore, what and how to capture then. If I only capture some encrypted garbage, it will be of no help for sure. I think I will try your suggestion with developer account for now (maybe just for one plug for starters, since I'm not really that keen on losing app control over plugs despite controling them mostly through HA). Thx for the tip :).

[AdmiralStipe]

@postlund, by the way, if I open developer account and re-pair the devices (and you said I won't be able to use the app anymore) - how do I get the localkey then? Now I got it from the android app, so are there other ways to get it as "developer" - maybe directly in the develoepr profile somewhere?

[postlund]

@AdmiralStipe I followed this and used tuya-cli to register my devices:

https://github.com/codetheweb/tuyapi/blob/master/docs/SETUP.md

[AdmiralStipe]

OK, great, but I have another question - after following the guide and registering as developer, already in Step 1 I only have the possibility to use Cloud develompent as free trial (until July 2021). What happens after that, will everything continue to work or will I be forced to pay for Premium to use these functions?

[postlund]

I think that everything you need to register new devices will still work after that. Seems to work fine for me.

[AdmiralStipe]

OK, I'm officially giving up. After huge troubles installing npm (which I finally managed to do on Raspberry as I have no other Linux machine available) I always get an error when trying to re-pair the plugs with cli (apparently I have no access to this API). I've had enough of troubleshooting one thing after another. So, my energy monitoring is ended for now and if you ever find a solution for this one (intentionally or through any other fix), I will gladly accept it. Thx for your past and future effort and time invested. Should I also close this issue or do I let it opened for possible future findings?

[postlund]

It's a bit tricky to get right, for sure! Maybe you manage to get it working some other day. You can leave it open as the issue itself still exists. Maybe someone else can try this method and confirm if it works or not.

[postlund]

@AdmiralStipe Before giving up, can you provide a DPS dump of your socket?

https://github.com/rospogrigio/localtuya/wiki/HOWTO-get-a-DPs-dump

[AdmiralStipe]

Sure, no problem, here you go (attachment). I made the dump from three plugs, for which I wanted to monitor the consumtion, although they are all the same type. One of them was accidentally turned on during the dump, cause I was charging my phone :) . I masked the Dev Id and local key for apparent reasons, hopefully that doesn't render the files useless - if so, let me know and I will send you the original log privately. Three dumps.txt

[myntath]

I have the same behaviour using kogan plugs (https://templates.blakadder.com/kogan-KASPEMHUSBA.html). The only difference being that my plugs do eventually update the monitoring every 10 minutes. If I open the tuya app energy page then updates are every few seconds.

The DPS is in exactly the same format as above. I don't know the use of DPS 21-25 and have not been able to get them to change. 21 is always 1. For 22-25 they are different between plugs but are quite close to each other and close to AdmiralStipes values (perhaps some sort of calibrations)?

I may try the tuya-cli method later to see if there is any difference in behaviour.

[ultratoto14]

@postlund something came to my mind. The issue you made a reference to, is basically the fact that the device only support one connection at a time if i understand well. But the app is not the only way to have a cloud connection opened. If you enable the alexa/google assistant support, this will also try to establish the connection to the device. What do you think ?

[linkmaks]

Hi, I have a similar problem, but I have noticed the tricky thing that if I open Tuya app during plug is on - stats is shown correctly in HA, but if not - it's not working. I can attach any logs if you say how :)

[postlund]

@ultratoto14 Maybe, it's a possibility of course. My first instinct would be that this connection would be via the cloud, rather than local. But I don't really grasp the full picture of how things are interacting here. Is this problem bound to specific SoC or is it programmatic, so vendors can alter this behavior somehow? Don't know.

@linkmaks Yeah, that seems to be the case. I think @AdmiralStipe mentioned it in the initial issue text if I'm not mistaken. I would like to know what the app is doing to trigger this.

[ilikecaterpillars]

If I could add to this, I don't know if it's much help at all, but I have left the app closed and managed to get the data updating again by reloading the entities through the integration panel. This works for a time, but then stops reading the data again after a while. I know next to nothing about coding, but is there a way of scheduling a reload of the entities periodically in order to keep the data flowing? xXx

[AdmiralStipe]

@postlund, just to let you know... I don't know, what have you changed in the last version, but suddenly all my energy monitoring works like a charm without touching anything at all. The plugs report energy related dps states at latest two to three seconds after switch on/off. So happy right now :). So, after all we can close this issue (at least from my side).

[postlund]

@AdmiralStipe Nothing had changed, really 😬 Any firmware update recently?

[AdmiralStipe]

Negative, firmware is unchanged for at least one year, maybe even more on all plugs :). Like I said, I havent touched a thing since sending you the last three dumps (I simply gave up). The only two things that have actually changed are update of HA (which I do with every update available) and latest update of localtuya. Well, even if you didn't change anything cruical, hopefully it will stay this way :).

[AdmiralStipe]

Oh well, it was nice till it lasted, but it was only for a couple of hours... after HA restart it's the same old way - no automatic refreshing, that is :(.

[pizipi]

Hi, I have a similar problem, but I have noticed the tricky thing that if I open Tuya app during plug is on - stats is shown correctly in HA, but if not - it's not working. I can attach any logs if you say how :)

Hi, exactly the same thing for me, the metrics is updated if electric tab in smart life app is open for the device. I do a test, app close, switch turning on on HA with a heater plug to the socket, current stay 0mA, I keep the switch on and open smart life app, go to electric tab, and current in HA synchronize and show the right value. So my understanding is that, those DPs is updated if only we look to them in the app

[diabl0]

Unfortunently have same issue az pizipi.

When app is off logs shows:

2020-12-06 23:18:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Sending command heartbeat (device type: type_0a)
2020-12-06 23:18:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Send payload: b'{}'
2020-12-06 23:18:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Waiting for sequence number -100
2020-12-06 23:18:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2020-12-06 23:18:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Got heartbeat response
2020-12-06 23:18:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Decrypted payload: {}

Wieving "Electric" tab in Tuya app

2020-12-06 23:18:56 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Dispatching message TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00\x00\x7f\x00\x00\x00\x013&t\xc72\xbb\xa2\xdf\xae7\xfc\n\x80\x0f\x12\x0e\x9dG \x1c\xca\xefma-\xffm\xc0=)\x9f\xe3\xaf\xb5\x82\xc7a3\xca\x81\xafd\xd7g\xbf\xfbz\x8cdIB\xee\xe1~#G\xb6S\xb9d!\xc1\x15\x8a\xe6\xcb\xb8\xfd\xaa\xc27"m#\t9\xc3\x8c\x9d\xb8K\xa1\xa6\r\xf4\xc1\x08\xb8\xde\xa4\x89\x19\xd8\x04\xab\x8b', crc=4212269267)
2020-12-06 23:18:56 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Got status update
2020-12-06 23:18:56 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Decrypted payload: {"devId":"52706618d8bfc0f14f6f","dps":{"18":1314,"19":2770,"20":2344},"t":1607293135}
2020-12-06 23:19:01 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Dispatching message TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00\x00\x80\x00\x00\x00\x013&t\xc72\xbb\xa2\xdf\xae7\xfc\n\x80\x0f\x12\x0e\x9dG \x1c\xca\xefma-\xffm\xc0=)\x9f\xe3*)t+O\xb4\xc3\xcdY\xbcRe\x99\xf6\xaeW\xdf\xb7\x17\xbc\xf7F\n\x843\x10\x04\x15wo\xc9\xd8\x08,\x01T\xff\xad"\xa7\xca\xc2\x94\x95C\xc2\x91\x81', crc=2120199829)
2020-12-06 23:19:01 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Got status update
2020-12-06 23:19:01 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Decrypted payload: {"devId":"52706618d8bfc0f14f6f","dps":{"19":2773},"t":1607293140}

Sending tuya app to background (hitting home button) on phone

2020-12-06 23:19:12 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Sending command heartbeat (device type: type_0a)
2020-12-06 23:19:12 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Send payload: b'{}'
2020-12-06 23:19:12 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Waiting for sequence number -100
2020-12-06 23:19:12 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2020-12-06 23:19:12 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Got heartbeat response
2020-12-06 23:19:12 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Decrypted payload: {}

During restart of HA (Tuya App on phone killed):

2020-12-06 23:23:44 DEBUG (MainThread) [custom_components.localtuya.discovery] Discovered device: {'ip': '10.0.0.26', 'gwId': '52706618d8bfc0f14f6f', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'keyjcr45yfptp7h7', 'version': '3.3'}
2020-12-06 23:23:44 DEBUG (MainThread) [custom_components.localtuya.discovery] Listening to broadcasts on UDP port 6666 and 6667
2020-12-06 23:24:09 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:09 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Waiting 0 seconds before connecting
2020-12-06 23:24:10 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:10 ERROR (MainThread) [custom_components.localtuya.common] [527...f6f] Connect to 10.0.0.26 failed
Traceback (most recent call last):
  File "/config/custom_components/localtuya/common.py", line 146, in _make_connection
    self._interface = await pytuya.connect(
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 626, in connect
    _, protocol = await loop.create_connection(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1025, in create_connection
    raise exceptions[0]
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1010, in create_connection
    sock = await self._connect_sock(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 924, in _connect_sock
    await self.sock_connect(sock, address)
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 496, in sock_connect
    return await fut
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 528, in _sock_connect_cb
    raise OSError(err, f'Connect call failed {address}')
ConnectionResetError: [Errno 104] Connect call failed ('10.0.0.26', 6668)
2020-12-06 23:24:10 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:10 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Waiting 0 seconds before connecting
2020-12-06 23:24:11 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:11 ERROR (MainThread) [custom_components.localtuya.common] [527...f6f] Connect to 10.0.0.26 failed
Traceback (most recent call last):
  File "/config/custom_components/localtuya/common.py", line 146, in _make_connection
    self._interface = await pytuya.connect(
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 626, in connect
    _, protocol = await loop.create_connection(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1025, in create_connection
    raise exceptions[0]
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1010, in create_connection
    sock = await self._connect_sock(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 924, in _connect_sock
    await self.sock_connect(sock, address)
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 496, in sock_connect
    return await fut
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 528, in _sock_connect_cb
    raise OSError(err, f'Connect call failed {address}')
ConnectionResetError: [Errno 104] Connect call failed ('10.0.0.26', 6668)
2020-12-06 23:24:11 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:11 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Waiting 0 seconds before connecting
2020-12-06 23:24:11 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26

2020-12-06 23:24:11 ERROR (MainThread) [custom_components.localtuya.common] [527...f6f] Connect to 10.0.0.26 failed
Traceback (most recent call last):
  File "/config/custom_components/localtuya/common.py", line 146, in _make_connection
    self._interface = await pytuya.connect(
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 626, in connect
    _, protocol = await loop.create_connection(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1025, in create_connection
    raise exceptions[0]
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1010, in create_connection
    sock = await self._connect_sock(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 924, in _connect_sock
    await self.sock_connect(sock, address)
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 496, in sock_connect
    return await fut
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 528, in _sock_connect_cb
    raise OSError(err, f'Connect call failed {address}')
ConnectionResetError: [Errno 104] Connect call failed ('10.0.0.26', 6668)
2020-12-06 23:24:12 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:12 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Waiting 7 seconds before connecting
2020-12-06 23:24:19 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:19 ERROR (MainThread) [custom_components.localtuya.common] [527...f6f] Connect to 10.0.0.26 failed
Traceback (most recent call last):
  File "/config/custom_components/localtuya/common.py", line 146, in _make_connection
    self._interface = await pytuya.connect(
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 626, in connect
    _, protocol = await loop.create_connection(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1025, in create_connection
    raise exceptions[0]
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1010, in create_connection
    sock = await self._connect_sock(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 924, in _connect_sock
    await self.sock_connect(sock, address)
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 496, in sock_connect
    return await fut
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 528, in _sock_connect_cb
    raise OSError(err, f'Connect call failed {address}')
ConnectionResetError: [Errno 104] Connect call failed ('10.0.0.26', 6668)
2020-12-06 23:24:19 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:19 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Waiting 13 seconds before connecting
2020-12-06 23:24:26 ERROR (MainThread) [homeassistant.components.google_assistant.http] Request for https://homegraph.googleapis.com/v1/devices:reportStateAndNotification failed: 404
2020-12-06 23:24:26 ERROR (MainThread) [homeassistant.components.google_assistant.http] Request for https://homegraph.googleapis.com/v1/devices:reportStateAndNotification failed: 404
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Started heartbeat loop
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Sending command heartbeat (device type: type_0a)
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Send payload: b'{}'
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Waiting for sequence number -100
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Connection lost: [Errno 104] Connection reset by peer
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Closing connection
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Disconnected: [Errno 104] Connection reset by peer
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Already connecting to 10.0.0.26 (52706618d8bfc0f14f6f) - False, <Task pending name='Task-4267' coro=<TuyaDevice._make_connection() running at /config/custom_components/localtuya/common.py:146> wait_for=<Future finished result=None>>, None
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Wait was aborted for seqno -100
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Retrieving initial state
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Sending command status (device type: type_0a)
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Send payload: b'{"gwId":"52706618d8bfc0f14f6f","devId":"52706618d8bfc0f14f6f"}'
2020-12-06 23:24:32 ERROR (MainThread) [custom_components.localtuya.common] [527...f6f] Connect to 10.0.0.26 failed
Traceback (most recent call last):
  File "/config/custom_components/localtuya/common.py", line 156, in _make_connection
    status = await self._interface.status()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 461, in status
    status = await self.exchange(STATUS)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 439, in exchange
    self.transport.write(payload)
AttributeError: 'NoneType' object has no attribute 'write'
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Closing connection
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:32 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Waiting 2 seconds before connecting
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Connecting to 10.0.0.26
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Started heartbeat loop
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Sending command heartbeat (device type: type_0a)
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Send payload: b'{}'
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Waiting for sequence number -100
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.common] [527...f6f] Retrieving initial state
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Sending command status (device type: type_0a)
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Send payload: b'{"gwId":"52706618d8bfc0f14f6f","devId":"52706618d8bfc0f14f6f"}'
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Waiting for sequence number 1
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Got heartbeat response
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Decrypted payload: {}
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Dispatching message TuyaMessage(seqno=1, cmd=10, retcode=0, payload=b'3&t\xc72\xbb\xa2\xdf\xae7\xfc\n\x80\x0f\x12\x0e\x9dG \x1c\xca\xefma-\xffm\xc0=)\x9f\xe3\xdc\xdbF\xaa\xc2\xcf\x00]\x19\xc3\\\x10\x814\x01\xd5R\x8d-\xc8\xa7p}HR\xd3*\xc4\x8f\x04\x184q\xb9G\x85\xefO\xb5\x9f\xec\xd8f\x93\x10 \xc4\x15\x80}\x1e\xbf\xfb2$\x843\xc1\xdb\x1e\x18\xc0\x93\x8e,2#\xf6\xca\xed\x02*v\xad\xec\xea\x95p\xb77q\xd1~\xa3\xfd\t\xdf\xab=\xba\xea\xa7PhC\xb5\xd9\x182N\x97\xc2\xd5\x82\xd3\x0c7G\xb9\x90k\xb0', crc=357942458)
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Dispatching sequence number 1
2020-12-06 23:24:34 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Decrypted payload: {"devId":"52706618d8bfc0f14f6f","dps":{"1":true,"9":0,"18":1313,"19":2773,"20":2348,"21":1,"22":585,"23":29285,"24":16924,"25":1232}}
2020-12-06 23:24:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Sending command heartbeat (device type: type_0a)
2020-12-06 23:24:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Send payload: b'{}'
2020-12-06 23:24:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Waiting for sequence number -100
2020-12-06 23:24:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2020-12-06 23:24:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Got heartbeat response
2020-12-06 23:24:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [527...f6f] Decrypted payload: {}

Hope this will help to found and fix issue...

[mralex79]

have a same problem, but opening of the SmartLife app is not forces refreshing of DPs in HA

[lishan89uc]

anyone figure this out? i seem to be having this issue as well.i have notice that the dps dump does not refresh the current draw either. does that mean there has to be a packet sent to the device from tuya to refresh the current draw for a limited amount of time? Since i also notice that just by going into the power consumption page of tuya app that the current and power draw will update itself for a minute or two. Below is my dps dump and setup

  - host: xxx.xxx.xxx.xxx
    device_id: xxxxxxxxxxxxxxxxxxxxxx
    local_key: xxxxxxxxxxxxxxxxx
    friendly_name: Washer Plug
    protocol_version: "3.3"
    entities:
      - platform: switch
        friendly_name: Washer Plug
        id: 1
        current: 18
        current_consumption: 19
        voltage: 20

      - platform: sensor
        friendly_name: Washer Current
        id: 18
        device_class: current
        unit_of_measurement: "mA"

Device xxxxxxxxxxxxxxxxxxxxxx at xxx.xxx.xxx.xxx key xxxxxxxxxxxxxxxx protocol 3.3 dev_type type_0a:
    DPS [1] VALUE [True]
    DPS [9] VALUE [0]
    DPS [17] VALUE [100]
    DPS [18] VALUE [3418]
    DPS [19] VALUE [3185]
    DPS [20] VALUE [1230]
    DPS [21] VALUE [1]
    DPS [22] VALUE [1094]
    DPS [23] VALUE [6883]
    DPS [24] VALUE [7028]
    DPS [25] VALUE [5120]
    DPS [26] VALUE [0]

update: with this current setup it seems that the sensor will update every 30 secs or so if the values changed. if the values don't change there is no update or refresh.

[adraffy]

Anyone got any Wireshark logs of an official app interacting with their devices?

Linking another project with the same issue: https://github.com/jasonacox/tinytuya/issues/8#issuecomment-751545691

[ultratoto14]

Can you check with latest master, as the connection is far more stable it could have fix the problem.

[lishan89uc]

yes i too have solved the issue with master. May i ask when theres no release? or even a beta?

[postlund]

We should probably make a release soon, but it will be after the holidays. Only @rospogrigio can do that right now and he is very busy at the moment.