Issue with Multiple BLE Lamp Instances Creating Delays When Linked with Tuya Gateway

[mariustt]

Description:
When using a Tuya gateway to connect BLE lamps as sub-devices in Home Assistant, each lamp is added as a separate instance. This creates a noticeable delay when a single switch is used to turn on multiple lamps simultaneously. However, this issue is not present when operating the lamps directly through the Tuya app.

Steps to reproduce the behavior:

1. Add BLE lamps as sub-devices through the Tuya gateway interface.
2. Link these devices with Home Assistant, noting that each lamp is treated as a distinct instance.
3. Use a single switch to activate multiple BLE lamps at once.
4. Observe a delay between the activation of each lamp.

Expected behavior:
The expected behavior is to have all BLE lamps turn on simultaneously without delay when operated through Home Assistant, similar to their behavior when controlled via the Tuya app.

Additional context
The delay is not present when operating the lamps directly through the Tuya app, suggesting the issue lies in the communication between the Tuya gateway and Home Assistant when handling multiple instances. A possible solution could be to allow the addition of all sub-device IDs upon device pairing, enabling them to be added as a single instance in Home Assistant.

Linked discussion: Tuya Local Discussion

Screenshots

[make-all]

This has been solved in the fork mentioned in #1581, pending pull request.

[mariustt]

@make-all good news! I'm really looking forward to the PR and then I can test it with my devices. I have quite a few BLE devices - 23. Only if I understand correctly PR will have a number of major changes. In that case, I would perhaps appreciate you reviewing and commenting on it first. Then we can move on to the testing phase.

[grayyang]

@mariustt, in my case, I have several thermostats behind one hub. I haven't try control them in one group, thus not sure whether any improvement in the delay can happen.

However, I can describe what has been changed to help better understand what may cause the delay you observed, whether my change may help some improvement, or what further changes may needed to improve the delay.

Firstly, how the device status update, e.g. turn on light, is implemented in tuya-local internally. @make-all, please correct me if my description below is not correct.
In tuya-local, each device connects to the hardware device via one tinytuya.Device (device abstraction in the tinytuya library), the tinytuya.Device if being one subdevice owns one tinytuya.Device acting as its parent (the hub device). It is the parent tinytuya.Device who holds one TCP connection to the corresponding device.
The "set property" (e.g. turn on the light) commands are sent to the hardware device in groups by a 1-second interval, that is multiple set that happens within 1 second are grouped and sent to the hardware to be executed together.

Secondly, what has changed in my fork.
In my modified version, each subdevice will still use its own tinytuya.Device; however, all tinytuya.Device now use the same shared parent tinytuya.Device. Thus, multiple subdevices reuse the same TCP connection to send command to the hardware.
This means concurrent updates to multiple subdevices will now sent through the same underlying TCP connection instead of several different TCP connections, which may result in some difference on how the devices may react.
However, the tricky part is that, in tinytuya library, multiple requests to hub are required for updating of each subdevice. I am not familiar with the underlying tuya API, and not sure if there are some batch API that could control multiple subdevices in one command as enhancement, and whether the official Tuya App use it.

However, this still means, depending on the current implementation of tinytuya library we are using, it is not possible to treat multiple subdevices as one single device since you have to control them one by one nevertheless.

[mariustt]

@grayyang Thank you for your very detailed reply! Considering that the logic itself has remained the same: one device -> one team, there might not be much change in the delay.

However, your observation about TCP overuse is very good. In practice, as far as I've come across, opening a connection takes some time. If I understood correctly from the information you gave, the same TCP connection will be used to transfer information between all devices. As a consequence, we should save time in setting up the connection. In addition, it is not yet clear how the gateway interprets a single parent device. Perhaps at its level the requests will be aggregated and sent to the end-devices, because as far as the tuya API is concerned, the API itself does not have access to the BLE devices, which means that the gateway has to do this job.

In any case, I look forward to the PR and I am eager to contribute to the testing. If the delay problem is not solved, then at least I will be able to get rid of 2 unnecessary gateways out of the 3 that I would use to control 9 lights.

[almirus]

@mariustt
offtop:
Could you please let me know which smart tack lights do you have? I have similar ones, but they work through their own wireless protocol 2.4 GHz and hub (PRO X2P) instead of BLE. Although they are visible through a BLE scanner (BLE mesh), they do not work with any Bluetooth hub.

Images

[mariustt]

@mariustt offtop: Could you please let me know which smart tack lights do you have? I have similar ones, but they work through their own wireless protocol 2.4 GHz and hub (PRO X2P) instead of BLE. Although they are visible through a BLE scanner (BLE mesh), they do not work with any Bluetooth hub.

Images

My equipment set includes:

• Moes - https://moeshouse.com/products/moes-gateway-mhub-ms
• TAMPA led system - https://www.topelighting.com/en/tampa-magnetic-led-system

I tried about 10 different gateways and they all only supported max 3 devices. The only one I could find that supports more than three devices is the Moes Wired Multi-mode Gateway. However, I have a problem with it which is described in this issue.

[almirus]

@mariustt Thank you. Yes, I can also only add 3 devices (lights). And when the tracks are on, do you see the BLE devices on your phone, for example through the nRF Connect app?

[mariustt]

@almirus I have not tried the nRF Connect app. To tell you the truth, I have never heard of it. However, I reach all devices directly via BLE (without a gateway) via tuya or the smart life app.

[zalatnaicsongor]

However, this still means, depending on the current implementation of tinytuya library we are using, it is not possible to treat multiple subdevices as one single device since you have to control them one by one nevertheless.

Just chiming in: Tuya has an excellent websockets based LAN control API for gateways: https://developer.tuya.com/en/docs/connect-subdevices-to-gateways/quick-start?id=Kd0g2gbi56ott

@make-all would you like me to take a stab at implementing this sort of protocol? I'm not a python dev (I work with Scala mainly), but I can give it a try.

[make-all]

It seems like unnecessary bloat to add a completely different protocol to this integration. It would probably be better as a separate integration.

[mariustt]

However, this still means, depending on the current implementation of tinytuya library we are using, it is not possible to treat multiple subdevices as one single device since you have to control them one by one nevertheless.

Just chiming in: Tuya has an excellent websockets based LAN control API for gateways: https://developer.tuya.com/en/docs/connect-subdevices-to-gateways/quick-start?id=Kd0g2gbi56ott

@make-all would you like me to take a stab at implementing this sort of protocol? I'm not a python dev (I work with Scala mainly), but I can give it a try.

@zalatnaicsongor a very interesting solution, which in principle can be implemented simply through homeassistant RESTful. The only problem with this is that you can't completely abandon the cloud? Because if you want to get an access token you have to make a request to a cloud endpoint which has to be accessible from the cloud?

[zalatnaicsongor]

It seems like unnecessary bloat to add a completely different protocol to this integration. It would probably be better as a separate integration.

It surely can be, but it'd be to share device definitions and other parts like home assistant integration between the two components. It's just merely adding a new transport, it doesn't really change the underlying logical protocol (data points, mappings, etc.)

@mariustt you are right, the usefullness of this depends on the lifetime of the access token. I'll investigate further.

[mariustt]

@zalatnaicsongor if you decide to explore this issue further and perhaps even create a separate lib, please share. I think this should open up full support for all datapoints via BLE, as my understanding is that this would be a kind of local tuya cloud. :)

[Krispkiwi]

Would this issue also relate to the "invalid key" errors with the BLE solar lights despite them having the correct key for the hub and being semi controllable when they're willing to respond which is like 50% of the time as mentioned in the previous issue raised? The issue does appear to be between the connection between tuya and the integration as the app still controls them well or is it something else?