Zigbee Gateway will Only accept one enabled child at a time when using tuya-local

[felipejfc]

Describe the bug
I have two ZB gateways at home, one of them works great, I have like 8 devices attached to it, no problem. The other one, a newer one using Zigbee 3.5, will only allow for one enabled device at a time. If I connect a device and enable it, it will work, second device I try to add will not go though.
Interestingly, not even a manual tinytuya script, directly from python will work. e.g. I have this script for testing:

import tinytuya

gwid="eb8368a08a9e5938044seh"
addr="10.1.0.143"
lk="'xxxxxxxxxxxxxxx"
dcid="a4c13867806ec8e8"
did="eb2056fdab6476a3e9r0uf"

tinytuya.set_debug(True)

gw = tinytuya.Device(gwid,address=addr,local_key=lk,version=3.5)
api = tinytuya.Device(did,cid=dcid,parent=gw)

print(api.status())

If I turn off tuya-local or disable the only device attached to this gateway in Homeassistant, this script will work. If I turn on one child of this device in Homeassistant, the very same script will fail with the following debug messages:

home python3 test.py 
DEBUG:TinyTuya [1.12.10]

DEBUG:Python 3.11.4 (main, Jul 25 2023, 17:36:13) [Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
DEBUG:Using PyCrypto (3, 17)
DEBUG:status() entry (dev_type is default)
DEBUG:final payload_dict for 'eb2056fdab6476a3e9r0uf' ('v3.5'/'default'): {1: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 7: {'command': {'protocol': 5, 't': 'int', 'data': {'cid': ''}}, 'command_override': 13}, 8: {'command': {'gwId': '', 'devId': ''}}, 9: {'command': {'gwId': '', 'devId': ''}}, 10: {'command': {}, 'command_override': 16}, 13: {'command': {'protocol': 5, 't': 'int', 'data': {'cid': ''}}}, 16: {'command': {}}, 18: {'command': {'dpId': [18, 19, 20]}}, 64: {'command': {'reqType': '', 'data': {}}}}
DEBUG:building command 10 payload=b'{"cid":"a4c13867806ec8e8"}'
DEBUG:sending payload quick
DEBUG:final payload: b'0123456789abcdef'
DEBUG:payload encrypted=b'00006699000000000001000000030000002c303132333435363738396162f94a2663ef30c4c95d985f721b9cb42fc62e391184bc73fd209a4b13bcf9784300009966'
DEBUG:_recv_all(): no data? b''
DEBUG:received null payload (None), fetch new one - 1 retries remaining
DEBUG:_recv_all(): no data? b''
DEBUG:_recv_all(): no data? b''
DEBUG:received null payload (None) but out of recv retries, giving up
DEBUG:session key negotiation failed on step 1
DEBUG:ERROR Check device key or version - 914 - payload: null
DEBUG:status() received data={'Error': 'Check device key or version', 'Err': '914', 'Payload': None}
{'Error': 'Check device key or version', 'Err': '914', 'Payload': None}

It's like either the GW, or tinytuya/tuya-local can only accept one session at a time? Any insights/tips to debug/fix this?

To Reproduce
The Gateway in question is this one: Aliexpress link, Tuya IoT recognizes it as: G01Y001

Expected behavior
To be able to control multiple child from the gateway.

[felipejfc]

Adding info:
It really seems this gw can only handle one session per time. If I use the following:

gw = tinytuya.Device(gwid,address=addr,local_key=lk,version=3.5,persist=True)

Executing two instances of my test script, one of them will fail. Is it possible to make the connections (to only some devices) non-persistent using tuya-local?

[make-all]

There is a polling option in the device config. However I don't know how much difference this will make, as Tuya devices that only accept one connection seem to also have other shortcomings with their connection handling, such as needing a couple of seconds recovery time between connections.

[felipejfc]

With 2 instances running like this:

gw = tinytuya.Device(gwid,address=addr,local_key=lk,version=3.5,persist=False)
api = tinytuya.Device(did,cid=dcid,parent=gw)

while True:
    print(api.status())
    sleep(1)

Most if not all requests will succeed. If I run Three, then one of them will start failing, so I think it's safe to assume the "rate_limit" would be around 2req/sec.
Do you think there's an way to handle multiple devices out of a single connection?

[felipejfc]

hmm tried locally and I think maintaining only one connection to the GW would work for controlling multiple devices:

the following works fine:

gw = tinytuya.Device(gwid,address=addr,local_key=lk,version=3.5,persist=False)
api1 = tinytuya.Device(did,cid=dcid,parent=gw)
api2 = tinytuya.Device(did2,cid=dcid2,parent=gw)

while True:
    print(api1.status())
    print(api2.status())
    sleep(0.1)

both requests will consistently work even though I'm sending 10 req/sec

EDIT:

Stressed further and put 3 devices and sleep .01 and still no problem in the requests. Think the way will really be pass all cmds through this single connection for all children

[felipejfc]

my (dirty) take on solving this from someone with 0 xp with the project so far:
felipejfc@c53d7ec

happy to turn into a "mergeable" commit if you're willing to give some directions :)

[make-all]

It seems that gateway.py is made by copying device.py and modifying it somehow. But because all this was done in one commit, it is difficult to see what the modifications are.

I would suggest the following:

1. use a separate branch from your new device PR, so that PR is not delayed by the review of more complex changes.
2. first create a commit that is just a copy of device.py to gateway.py, then create another commit with the modifications.

The easy way to do this would be

1. to take a copy of the modified files outside your git workspace (or make another workspace alongside).
2. reset your head to just the new device change (I see you just did this)
3. create a new branch from the commit before the new device addition.
4. copy device.py to gateway.py unmodified and commit.
5. copy your modified files back into the tree and commit.

[felipejfc]

Did separate already, I messed up the first try :p

For the change of the gateway, far from ready to be merged, only wanted to POC the idea and show it to you. The high level change is instead of creating multiple "apis" using the same gateway, we should create only one, all of its subdevices should "consume" it to update status bidirectionally. Also, when doing this we can't configure parent.dev_id = device.dev_id, any other value will do since what matters is the cid, but it needs to be different for all subdevices when sharing the connection --- I just did dev_id = cid

this was my saturday rush try, I managed to validate the POC as with the changes I can add multiple devices using this gateway, but it's not reliable since I'm probably ignoring a bunch of stuff

[cebik]

I think the same thing happens with my devices in TuyaLocal although I have a different gateway (MOES-Smart Multi-Mode Gateway https://aliexpress.com/item/1005005203503583.html ).

How can I use your version of the plugin?
Is it already working stably?

I still see such an error in the logs and I thought maybe it was caused by it:

`
Logger: homeassistant.util.async
Source: util/async_.py:166
First occurred: 13:38:06 (2 occurrences)
Last logged: 13:43:27

Detected blocking call to sleep inside the event loop. This is causing stability issues. Please report issue to the custom integration author for tuya_local doing blocking calls at custom_components/tuya_local/device.py, line 73: parent=tinytuya.Device(dev_id, address, local_key),_
`

My gateway sucks. I think I'll change it.
I'm new in Tuya world and can't find info which gateway Tuya is the best. Can anyone advise?