Forcing light status update from "unavailable" to "on"

[SmartM-ui]

Hi @rospogrigio @postlund @ultratoto14, I have noticed that often when I turn off the light bulb from the switch, when I turn it on after many hours, the status remains on "unavailable" and does not update even after many minutes. (even after the smartlife app detects the status update)

To update the status, I have to click on settings / server management / Reload LocalTuya integration

To change state from "on" to "unavailable", however, takes a few seconds.

If I try to turn the light back on immediately after turning it off with the switch, however, the status from unavailable to off changes quite quickly, about a minute.

Is it possible to force the update of the status of the bulbs (also switches?) turned off by the switch?

Thanks

[postlund]

This behavior sounds more like a bug than anything else. Please provide debug logs from when this happens. Preferably we should wait for the PR regarding contextual logging is merged though.

[SmartM-ui]

This behavior sounds more like a bug than anything else. Please provide debug logs from when this happens. Preferably we should wait for the PR regarding contextual logging is merged though.

OK, thanks, I had disabled the debug log to avoid a too large log :-)

I reactivate it and send the debug

Thanks!

[SmartM-ui]

Hi @postlund how are you? I finally went home and was able to better check what happens when the state of the light bulb changes from unavailable to on.

I noticed that if the light bulb stays off for a long time (via real switch), the status is not updated.

The check on the switched off bulb by means of a real switch takes place every 5 minutes and, when it is switched on again by means of a real switch, it took 10 minutes as it failed the first check.

Once the bulb has been found in the localtuya network, it takes only 15 seconds to make the change of state from ON to unavailable and vice versa.

Could you try to lower the 5 minute check? Can you also check if you can understand the problem that is generated on the first attempt to reconnect? Sometimes even more than 10 minutes went by and he could not connect the bulb.

I send you the logs:

Logger: custom_components.localtuya.common Source: custom_components / localtuya / pytuya / init.py:593 Integration: LocalTuya integration (documentation, issues) First occurred: 18:48:04 (62 occurrences) Last logged: 23:20:25 Connect to 192.168.1.131 failed

Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 140, in _make_connection self._interface = await pytuya.connect ( File "/config/customcomponents/localtuya/pytuya/init.py", line 593, 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} ') OSError: [Errno 113] Connect call failed ('192.168.1.131', 6668)

23.22 HOURS LAMP 192.168.1.131 ON THROUGH PHYSICAL SWITCH FIRST CHECK CARRIED OUT WHEN THE SWITCH WAS ON BUT THE LOCALTUYA STATE CONTINUED TO BE OFF

2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Started heartbeat loop 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Sending command heartbeat (device type: type_0a) 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Send payload: b'{}' 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Waiting for sequence number -100 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Connection lost: [Errno 104] Connection reset by peer 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Closing connection 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Wait was aborted for seqno -100 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Sending command status (device type: type_0a) 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Send payload: b'{"gwId":"MyID","devId":"MyID"}' 2020-11-16 23:25:25 ERROR (MainThread) [custom_components.localtuya.common] Connect to 192.168.1.131 failed Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 150, in _make_connection status = await self._interface.status() File "/config/custom_components/localtuya/pytuya/__init__.py", line 428, in status status = await self.exchange(STATUS) File "/config/custom_components/localtuya/pytuya/__init__.py", line 406, in exchange self.transport.write(payload) AttributeError: 'NoneType' object has no attribute 'write' 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Closing connection 2020-11-16 23:25:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x01\xa4\xb0\x00\x00\x00\x01\x05\xbd\xe6\xd9oA\xdez\xa9\x93\x0e\x86\xd6{D\xde\xf8\xcbz\xff\xdc\\*\x88\x90d\xcb\xc0\x10\x0c(\xb2\xe4!vH%x\xb6\xf3\xed\xfcb\xcf\x0e\x0e\xb0\x1d', crc=2879467477)

AFTER ANOTHER 5 MINUTES THAT THE BULB WAS ON, THE LOCALTUYA STATE HAS CHANGED CORRECTLY BY SETTING ON

2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Started heartbeat loop 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Sending command heartbeat (device type: type_0a) 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Send payload: b'{}' 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Waiting for sequence number -100 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Sending command status (device type: type_0a) 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Send payload: b'{"gwId":"MyID","devId":"MyID"}' 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Waiting for sequence number 1 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211) 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Got heartbeat response 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Decrypted payload: {} 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=1, cmd=10, retcode=0, payload=b"\x93\xb8Z\xef\xbb\xdf\xd3\x86\x84g\xb9\x7fp\xcdO\x9bn\xcf\xe8\x8e\x08\x08\x11\xb8\x11\xa1T\x8c\x10v\xd4\xc5\x82w\x86i2\x92\xa4\x16i\x8b\xa5l\xf2\xb0\x93\x94\x91(\x1fVV_\xe2;\xdb\x90\xd6\xe1M\xa1\x14\x94\xc5\x16\x9f\xd4\xc7\x87\xd4\x83\xf4y\x9d\xb6*{\xe6:\xf7\x16.\xc84\xb1\x0f\xa70\xebE\xe7\xd0\xfc\x81\xe7\x10\xb3X:\xd4=l|J\x7f\x98\xbf6\x98+\x82\xa1\x1f\x84'\xe5\xd3\x8b\xcc\xc5\xa3\x885\x02mW\xd2\xb6\x06U\xb2\xa5\x1c\xf0\x10\xb7nM\xd6\xb9\x0fC\x1aq0\x15\xae\xb8\x912f)\t]\xe0R\xfad\xd1\xd1\x84\xfa\xce\xeex/S\x9a)T=\xf5645\xc62\x13;\x7fO\xb0\x93Q\xc6\xd3,\x90oWc\xe7\x12\x80T\xaeF\xd1\x83\xe0\x8c\xba\xf9\x04\x0f5$\xc2\xfc\x00N\xbbA*T\x16\x19N\xae\xfb\xb9\xa8\x90\xd4=~\x1e\x04\x11Fi\xaa\xb7Q*\xd4\xbd\xb3Pq<\x1a\xd5T\xb7Z\xd0\x9ea\xbc\x12\x0f\xc2\x89\xe4e%W\xb0\x93\x071 \xb5Cy\xe1gLI", crc=2043867565) 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Dispatching sequence number 1 2020-11-16 23:30:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Decrypted payload: {"devId":"MyID","dps":{"20":true,"21":"white","22":14,"23":0,"24":"00f003e800dc","25":"05464601000003e803e800000000464601007803e803e80000000046460100f003e803e800000000464601003d03e803e80000000046460100ae03e803e800000000464601011303e803e800000000","26":0}} 2020-11-16 23:30:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Sending command set (device type: type_0a) 2020-11-16 23:30:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Send payload: b'{"devId":"MyID","uid":"MyID","t":"1605565826","dps":{"20":true,"22":14,"23":0}}' 2020-11-16 23:30:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Waiting for sequence number 2 2020-11-16 23:30:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=2, cmd=7, retcode=0, payload=b'', crc=416269786) 2020-11-16 23:30:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Dispatching sequence number 2 2020-11-16 23:30:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Decrypted payload: {} 2020-11-16 23:30:26 DEBUG (MainThread) [customcomponents.localtuya.pytuya] Dispatching message TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x01\x93\xb8Z\xef\xbb\xdf\xd3\x86\x84g\xb9\x7fp\xcdO\x9bn\xcf\xe8\x8e\x08\x08\x11\xb8\x11\xa1T\x8c\x10v\xd4\xc5\x82w\x86i2\x92\xa4\x16i\x8b\xa5l\xf2\xb0\x93\x94\xc1\xa3qE;\x90\xb9\xde\xe7\xdb8\xf9M\xc7\xf1\%\xdbz\xd5\xd2\xd9\xf6G\x18:\x08pk\xa5\xea\xd1\xb2x=\xebO\xcePS9\xd4\xc9I\x83]{', crc=2126595516) 2020-11-16 23:30:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Got status update 2020-11-16 23:30:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Decrypted payload: {"devId":"MyID","dps":{"20":true,"22":14,"23":0},"t":1605565825} 2020-11-16 23:30:26 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x01\xa5&\x00\x00\x00\x01\xdbq:\xc2\x7fQ69\x9d\xa3 O\x14\xe6\x80\x0b@\x7f#7\x81\xd1]{-\xbc \xe2\xd2\x85\xf0$\xc5\x9b\xc7\xfc\xf2\x02(\x1fv\x01\x05yH\xf8k\xdb', crc=1798504856)`

TURN OFF BY REAL SWITCH AT 11:37 PM: xx

2020-11-16 23:38:11 ERROR (MainThread) [custom_components.localtuya.pytuya] [MyID] Heartbeat failed (), disconnecting Traceback (most recent call last): File "/config/custom_components/localtuya/pytuya/__init__.py", line 346, in heartbeat_loop await self.heartbeat() File "/config/custom_components/localtuya/pytuya/__init__.py", line 435, in heartbeat return await self.exchange(HEARTBEAT) File "/config/custom_components/localtuya/pytuya/__init__.py", line 407, in exchange msg = await self.dispatcher.wait_for(seqno) File "/config/custom_components/localtuya/pytuya/__init__.py", line 206, in wait_for await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout) File "/usr/local/lib/python3.8/asyncio/tasks.py", line 498, in wait_for raise exceptions.TimeoutError() asyncio.exceptions.TimeoutError 2020-11-16 23:38:11 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Stopped heartbeat loop 2020-11-16 23:38:11 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Closing connection 2020-11-16 23:38:11 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Connection lost: None 2020-11-16 23:38:11 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Closing connection

TURN ON BY REAL SWITCH AT 23:41:03

2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Started heartbeat loop 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Sending command heartbeat (device type: type_0a) 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Send payload: b'{}' 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Waiting for sequence number -100 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Sending command status (device type: type_0a) 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Send payload: b'{"gwId":"MyID","devId":"MyID"}' 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Waiting for sequence number 1 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211) 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Got heartbeat response 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Decrypted payload: {} 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=1, cmd=10, retcode=0, payload=b"\x93\xb8Z\xef\xbb\xdf\xd3\x86\x84g\xb9\x7fp\xcdO\x9bn\xcf\xe8\x8e\x08\x08\x11\xb8\x11\xa1T\x8c\x10v\xd4\xc5\x82w\x86i2\x92\xa4\x16i\x8b\xa5l\xf2\xb0\x93\x94\x91(\x1fVV_\xe2;\xdb\x90\xd6\xe1M\xa1\x14\x94\xc5\x16\x9f\xd4\xc7\x87\xd4\x83\xf4y\x9d\xb6*{\xe6:\xf7\x16.\xc84\xb1\x0f\xa70\xebE\xe7\xd0\xfc\x81\xe7\x10\xb3X:\xd4=l|J\x7f\x98\xbf6\x98+\x82\xa1\x1f\x84'\xe5\xd3\x8b\xcc\xc5\xa3\x885\x02mW\xd2\xb6\x06U\xb2\xa5\x1c\xf0\x10\xb7nM\xd6\xb9\x0fC\x1aq0\x15\xae\xb8\x912f)\t]\xe0R\xfad\xd1\xd1\x84\xfa\xce\xeex/S\x9a)T=\xf5645\xc62\x13;\x7fO\xb0\x93Q\xc6\xd3,\x90oWc\xe7\x12\x80T\xaeF\xd1\x83\xe0\x8c\xba\xf9\x04\x0f5$\xc2\xfc\x00N\xbbA*T\x16\x19N\xae\xfb\xb9\xa8\x90\xd4=~\x1e\x04\x11Fi\xaa\xb7Q*\xd4\xbd\xb3Pq<\x1a\xd5T\xb7Z\xd0\x9ea\xbc\x12\x0f\xc2\x89\xe4e%W\xb0\x93\x071 \xb5Cy\xe1gLI", crc=2043867565) 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Dispatching sequence number 1 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Decrypted payload: {"devId":"MyID","dps":{"20":true,"21":"white","22":14,"23":0,"24":"00f003e800dc","25":"05464601000003e803e800000000464601007803e803e80000000046460100f003e803e800000000464601003d03e803e80000000046460100ae03e803e800000000464601011303e803e800000000","26":0}} 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Sending command set (device type: type_0a) 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Send payload: b'{"devId":"MyID","uid":"MyID","t":"1605566474","dps":{"20":true,"22":14,"23":0}}' 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Waiting for sequence number 2 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=2, cmd=7, retcode=0, payload=b'', crc=416269786) 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Dispatching sequence number 2 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Decrypted payload: {} 2020-11-16 23:41:14 DEBUG (MainThread) [customcomponents.localtuya.pytuya] Dispatching message TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x01\x93\xb8Z\xef\xbb\xdf\xd3\x86\x84g\xb9\x7fp\xcdO\x9bn\xcf\xe8\x8e\x08\x08\x11\xb8\x11\xa1T\x8c\x10v\xd4\xc5\x82w\x86i2\x92\xa4\x16i\x8b\xa5l\xf2\xb0\x93\x94\xc1\xa3qE;\x90\xb9\xde\xe7\xdb8\xf9M\xc7\xf1\\xa7s\xc1\xf8\x8c/\x7f\x92\xf8k:/\x12\xf8\x89X\xb2x=\xebO\xcePS9\xd4\xc9I\x83]{', crc=3237229690) 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Got status update 2020-11-16 23:41:14 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Decrypted payload: {"devId":"MyID","dps":{"20":true,"22":14,"23":0},"t":1605566474} `

[postlund]

Ah, right. I think I understand you now. You mean when you break the electricity to the bulb so that we have to re-connect, right? Didn't understand that first. We use a re-connect with exponential backoff. It basically means that we double the re-connect window after every failed attempt. So after 5 failed attempts we have a window of 2^5=32s. We then pick a random number of seconds from that window and sleep before connecting again. As the number of failed connection attempts increase, so does the re-connect time. This is to avoid hammering and it's basically as good as it gets (with some tweaking possible of course). But we do not want to support hammering as that is bad practice. However...

We have #106 lingering. It's a PR I have neglected now for a while, but will continue to work on once I get the issue situation under control. One outcome from it is that it will introduce a passive mode. A device configured as passive will not use the re-connect loop described above. Instead it will listen for broadcast messages (the same we use for discovery) and re-connect whenever one of those is received. This will make re-connects instant. So hopefully that will solve this issue for you. Sorry about the long segue way...

[SmartM-ui]

Ah, right. I think I understand you now. You mean when you break the electricity to the bulb so that we have to re-connect, right? Didn't understand that first. We use a re-connect with exponential backoff. It basically means that we double the re-connect window after every failed attempt. So after 5 failed attempts we have a window of 2^5=32s. We then pick a random number of seconds from that window and sleep before connecting again. As the number of failed connection attempts increase, so does the re-connect time. This is to avoid hammering and it's basically as good as it gets (with some tweaking possible of course). But we do not want to support hammering as that is bad practice. However...

We have #106 lingering. It's a PR I have neglected now for a while, but will continue to work on once I get the issue situation under control. One outcome from it is that it will introduce a passive mode. A device configured as passive will not use the re-connect loop described above. Instead it will listen for broadcast messages (the same we use for discovery) and re-connect whenever one of those is received. This will make re-connects instant. So hopefully that will solve this issue for you. Sorry about the long segue way...

Thanks sincerely for reading all of my long post. I have tried to best describe the error, reporting the various tests. You understood very well! The problem is noticed when I cut off the electricity, as I turn off some of the light bulbs through the physical switch on the wall.

It would be convenient to be able to decide on individual bulbs.

As for the problem that occurred after the expected 5 minutes, however, is it due to some other setting that I can try to change?

I refer specifically to this error:

2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Started heartbeat loop 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID ] Sending command heartbeat (device type: type_0a) 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Send payload: b '{}' 2020-11-16 23:25 : 25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Waiting for sequence number -100 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Connection lost: [ Errno 104] Connection reset by peer 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Closing connection 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components. localtuya.pytuya] [MyID] Wait was aborted for seqno -100 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Sending command status (device type: type_0a) 2020-11 -16 23:25:25 DEBUG (MainThread) [custom_components.lo caltuya.pytuya] [MyID] Send payload: b '{"gwId": "MyID", "devId": "MyID"}' 2020-11-16 23:25:25 ERROR (MainThread) [custom_components.localtuya.common ] Connect to 192.168.1.131 failed Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 150, in _make_connection status = await self._interface.status () File "/ config / custom_components /localtuya/pytuya/init.py ", line 428, in status status = await self.exchange (STATUS) File" /config/custom_components/localtuya/pytuya/init.py ", line 406, in exchange self.transport.write (payload) AttributeError: 'NoneType' object has no attribute 'write' 2020-11-16 23:25:25 DEBUG (MainThread) [custom_components.localtuya.pytuya] [MyID] Closing connection 2020-11-16 23:25: 26 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage (seqno = 0, cmd = 8, retcode = 0, payload = b'3.3 \ x00 \ x00 \ x00 \ x00 \ x00 \ x01 \ xa4 \ xb0 \ x00 \ x00 \ x00 \ x01 \ x05 \ xbd \ xe6 \ xd9oA \ xdez \ xa9 \ x93 \ x0e \ x86 \ xd6 {D \ xde \ xf8 \ xcbz \ xff \ xdc \ * \ x88 \ x90d \ xcb \ xc0 \ x10 \ x0c (\ xb2 \ xe4! vH% x \ xb6 \ xf3 \ xed \ xfcb \ xcf \ x0e \ x0e \ xb0 \ x1d ', crc = 2879467477)

[postlund]

The upper backoff time is 5min, so that's why you get roughly that time. It's just arbitrarily chosen to not be too long and not too short.

[postlund]

Ok, so, @SmartM-ui, I have created a PR adding support for "passive devices", where connection attempts are driven by discovery messages. It's in #171 (you can read the text there for some details). It would be really great if you tried it out.

If you configure via YAML, you need to add passive_device: true to the main part of the configuration for the device in question. If you used config flow, there's a check box found under Options. You can't miss it.

[SmartM-ui]

Ok, so, @SmartM-ui, I have created a PR adding support for "passive devices", where connection attempts are driven by discovery messages. It's in #171 (you can read the text there for some details). It would be really great if you tried it out.

If you configure via YAML, you need to add passive_device: true to the main part of the configuration for the device in question. If you used config flow, there's a check box found under Options. You can't miss it.

THANKS THANKS THANKS!

I try now, I just have the lamp of the studio chandelier turned off for a few hours via the wall switch :-)

[fzimmermann89]

@SmartM-ui : Would you mind giving an update?

... I'd like to know if the behavior is improved before investing the time to install homeassistant and localtuya ;)

[SmartM-ui]

@SmartM-ui : Would you mind giving an update?

... I'd like to know if the behavior is improved before investing the time to install homeassistant and localtuya ;)

Hi, you can find updates to pull #171

Switching from UNAVAILABLE to ON takes 5 to 10 seconds Switching from ON to UNAVAILABLE takes 12 to 18 seconds