My fork supporting multiple subdevices behind one hub device.

[grayyang]

Multiple Subdevice supported Tuya Local fork

Link: https://github.com/grayyang/tuya-local

The current tuya-local has a limitation on connecting to multiple subdevices behind one single hub if the hub device limits the number of connections it accepts. Refer to the document for the details.

I modified the original component to remove this limitation by communicating with all subdevices using one shared connection to the hub device. Thus, it uses only one single connection to the hub device and no limitation on the number of subdevices exists anymore.

Currently, I have used my forked version to support 9 subdevices under 1 hub. Everything works well including sending commands and getting notifications on status changes.

Example: 8 subdevices under control

If anyone needs to connect multiple subdevices behind one single hub, you may try out my repository as an alternative.
Currently, I would suggest you specify the IP address and protocol of the hub device explicitly instead of auto-discovery as these two features are not well-tested under my own setup.

[grayyang]

@make-all , would you think you may suggest the ones who also need to connect to multiple subdevices have a try on my forked version if they encounter the limitation of the number of connections of the hub device?

[make-all]

How suitable is this to be merged? Is it tested also against non-hub devices, to ensure no regressions for other device types?
You could submit a pull request and work toward getting it merged.

[grayyang]

Great! I think it would be great if this could be merged into the main repo.

For the non-hub devices, I have no such one on my hand yet, thus I have no chance to test it for now. Thus, I may need your help with testing, not sure if that is possible.

For the creation of one PR, I would make some refactoring to the code and comments first. Hopefully, I will submit the PR in recent days.
Also to mention, I think this PR will be a big one as it made a big change on the device.py to add a new class to abstract the hub device and the dedicated receive loop for the hub device.

[almirus]

any news?

[mariustt]

@grayyang I've been looking forward to this, great work! I have created an issue for this question - #1323. But at the same time, I had very high hopes that this solution would resolve a couple of things:

1. The limitations of having max 3 devices per gateway. This is basically what you have encountered and solved.
2. Significant delay when you want to switch on/off lighting at the same time.

Question on point 2 - if you create a home assistant helper group from some one of the device entities and turn on/off, is there still a significant delay with this implementation?

[AdrianGarside]

What's the current situation with this? I'm about to add a couple more soil sensors connecting (hopefully, if the range works) to an existing gateway device. So I'll have 3 devices on the one gateway at that point. That might work, or might not if the gateway only accepts a single connection. I won't know until the extra soil sensors arrive.