Open neuronflow opened 1 year ago
Im having the same problem with my WiFi Online Control Monitor
This started happening too one of my bulbs a few home assistant updates ago, readding it seem to have fixed it for now.
issue persists :( do you require more information?
I am having the same issue as well
Same issue for me. Anyone has found a workaround?
is it possible to create an automation that reloads the plugin every n hours?
@neuronflow you might want to try switching the protocol version to 3.2. I just realized you used 3.3 like I did. I switched it to 3.2 just to see what happenes, and so far my Ledvance bulb is working great!
thanks, will try! Interestingly, for my devices just 3.1 and 3.3 are available? o_O
you need to update localtuya from your HACS tab. Protocol 3.2 was added in the newest version 5.0.0, see https://github.com/rospogrigio/localtuya/releases/tag/v5.0.0
btw others used a Ledvance LED with protocol 3.4: https://github.com/rospogrigio/localtuya/pull/1222#issuecomment-1375866798 3.4 didn't work for me, it depends on the model I guess
@neuronflow you might want to try switching the protocol version to 3.2. I just realized you used 3.3 like I did. I switched it to 3.2 just to see what happenes, and so far my Ledvance bulb is working great!
nevermind it still disconnects :(
So I checked with tinytuya. Its protocol 3.3. The bulb can still be used with tinytuya, even after it became unavailable in HASS.
I checked the logs, There's a permantent flood if the following messages while the bulb is working:
(MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Sending command 9 (device type: type_0a) (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Sending payload: b'{"gwId":"bfb78a3161e332d6a4jrhz","devId":"bfb78a3161e332d6a4jrhz"}' (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Command 9 waiting for sequence number -100 (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Dispatching message CMD 9 TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211, crc_good=True) (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Got heartbeat response (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] ACK received for command 9: ignoring it
And this is when the bulb becomes unavailable:
(MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Sending command 9 (device type: type_0a) (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Sending payload: b'{"gwId":"bfb78a3161e332d6a4jrhz","devId":"bfb78a3161e332d6a4jrhz"}' (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Command 9 waiting for sequence number -100 (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Connection lost: [Errno 104] Connection reset by peer (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Heartbeat failed due to timeout, disconnecting
tuyadebug output: INFO:localtuya:localtuya version 1.0.0 INFO:localtuya:Python 3.11.1 (main, Dec 7 2022, 00:00:00) [GCC 12.2.1 20221121 (Red Hat 12.2.1-4)] on linux INFO:localtuya:Using pytuya version '10.0.0' INFO:localtuya:Detecting list of available DPS of device bfb78a3161e332d6a4jrhz [192.168.178.41], protocol 3.3. DEBUG:localtuya.pytuya:[bfb...rhz] Sending command 10 (device type: type_0a) DEBUG:localtuya.pytuya:[bfb...rhz] Sending payload: b'{"gwId":"bfb78a3161e332d6a4jrhz","devId":"bfb78a3161e332d6a4jrhz","uid":"bfb78a3161e332d6a4jrhz","t":"1674180707"}' DEBUG:localtuya.pytuya:[bfb...rhz] Command 10 waiting for sequence number 1 DEBUG:localtuya.pytuya:[bfb...rhz] Dispatching message CMD 10 TuyaMessage(seqno=1, cmd=10, retcode=0, payload=b'Q0\x06B5\xfd<\xb5p\x84U/\x9d\xb7q\xe8\xe05=~\xea:\x0e\xe3\xe6\x8dH\x0e\xe4\x9eRv\x97\xb2\xadO4\x127\n\x04\x84\x0c\xcb\x93e\xfd\x15UL.\xf5\xe3~\xefw\x07\xd7=\xe6\xa5@\xe7M\x81\xc6\xc3-\xd0\xad\x07\xbd\xfb\x93\xa6\x17\xc6\x05\xbeB\xa1\xb6\x03T\x80\xa1L\xb02\xbe!8G#j\xda[\x9b\x95P\xdb\xa0\x1a\x07\xa9\x1c\xe3\xb5N\xf66\x13\x8f1!\x0f\xaf\x13\xffM!\xb5C\xda\x9e\x0c\xfa`', crc=4159497351, crc_good=True) DEBUG:localtuya.pytuya:[bfb...rhz] Deciphered data = '{"dps":{"20":true,"21":"white","22":1000,"23":165,"24":"003c035903e8","25":"000e0d0000000000000000c80000","26":0,"101":true}}' AVAILABLE DPS ARE [{'20': True, '21': 'white', '22': 1000, '23': 165, '24': '003c035903e8', '25': '000e0d0000000000000000c80000', '26': 0, '101': True}] INFO:localtuya:COMPLETE response from device bfb78a3161e332d6a4jrhz [192.168.178.41].
deviceInfo returned OK
TuyaDebug (Tuya DPs dump) [1.0.0]
Device bfb78a3161e332d6a4jrhz at 192.168.178.41 key XXXXXXXXXXX protocol 3.3 dev_type type_0a: DPS [20] VALUE [True] DPS [21] VALUE [white] DPS [22] VALUE [1000] DPS [23] VALUE [165] DPS [24] VALUE [003c035903e8] DPS [25] VALUE [000e0d0000000000000000c80000] DPS [26] VALUE [0] DPS [101] VALUE [True]
I have the same issue with gosund smart plugs. One works, one loses connection after a few hours, then it stops working until I reload (by editing the device and just clicking okay twice).
EDIT: I got it fixed by downgrading. Check my solution out here: https://github.com/rospogrigio/localtuya/issues/1116#issuecomment-1427047385
The problem
Environment