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.

[almirus]

We are eagerly waiting for the solution.

[almirus]

@make-all It's really unfortunate that supporting more than 3 devices (some) with one hub is still missing, how is the progress on the PR?

[make-all]

There is no PR

[almirus]

@grayyang 🙏

[darro-gbn]

Is this a limitation on gateways we have, or in this implementation? I guess I'm asking do I need to purchase another brand of gateway or wait for this fixed to be merged into the main release?

Thanks
Darren

[almirus]

@darro-gbn The problem isn't with the devices (gateways)—the issue lies in the integration itself. As the author mentioned, gateway support was added at the last minute and follows the same logic as the end devices.

[mariustt]

I would recommend trying the Moes gateway, which in my case solved the problem. I've tried maybe 10-15 different gateway models, but this is the only one that doesn't have limitations with local support - #1323 (comment).

This will save a lot of your precious time. But of course I would also like to find a solution that does not use separate connections for each sub-device.

[darro-gbn]

@almirus Thanks, yes that was my understanding it was the code.
@mariustt I have a Moes Gateway, but best I can tell I have this issue, It's the "Tuya Zigbee Matter Thread Gateway Smart Home Bridge Matter Hub" SKU: MZHUB-MS

My 1st device was discovered and added, but I can't add any additional devices.
Is there something in the logs I should be specifically looking for?

I appreciate all the assistance.
Darro

[mariustt]

Another hack you can try and it worked for me, is to open the Tuya/Smart life app and enable/disable all entities of the device you want to add. I found that if a specific entity was not used through the gateway, then it is not visible locally.

[darro-gbn]

Thanks I'll give that a try.

[ciscolyon69]

hello, is there any chance this will work on the original project?

[felipecrs]

I believe the very first step is @grayyang to create a PR here.

[rhazbun]

So seems like maybe @grayyang is MIA.
@make-all how do you think we should proceed?
I'd be willing to try and test this using my non-hub tuya devices as was originally requested. But I am running 2024.8.0 and have no idea how to install this in parallel. Is there a guide or suggested procedure?

[darro-gbn]

My HA system is not really live, so I'm happy to do any testing required. I now have about 12 Zigbee devices.

[make-all]

I think there were some HA changes around July which broke backwards compatibility, so it will probably take some effort to bring this up to date.
For medium term I plan to rewrite the connection handling, incorporating hub support among other connection related issues that are outstanding, so any effort spent here may be of limited lifespan.

[darro-gbn]

OK, Thanks for the Road map, I look forward to it at some stage. Let me know if I can be of any (non-coding) help.

[vampywiz17]

If you have a matter compatible hub, able to use these way: #2775