Slow requests

[bimusiek]

Describe the bug
In beta 21, the moment I tap to switch a light in Homekit, it takes less than 2s, most of the time less than 1s, to trigger Tuya.
In next versions the response time is around 5s.

Expected behavior
I don't expect to have the light switched instant, however the difference is quite big. Especially when setting "Goodnight" scene where all the shades and lights are closing. In v21, all of those switch at the same time (so shades starts rolling down together, lights are turned off together, even if it takes 1-2s to trigger it). After v21, some shades will start closing earlier, some later, same with lights.

Device info
There are no logs for v21, but in newer version I could only see the log that message was not in order and it fallen back to fetch API. Could this be a culprit? But I don't see an issue with wrong state of the device now as I though I will with messages being not in order.

[0x5e]

Hi @bimusiek , you can start homebridge in debug mode to see the API and mqtt logs. beta 21 until the latest version didn't change too much in network request. Where's your location and which data center are you using?
For the control command, I think longer than 1s is abnormal. If we can see the homebridge debug logs, maybe we can find out why.
For the status update response (mqtt) currently there's a known issue: #32

[bimusiek]

@0x5e Hey, I am from Poland (connecting via Starlink) and in project I have Central Europe Data Center, Western Europe Data Center configured as data center.

One of the slow requests.
Turning on light was quick, then turning it off took time.

[22/11/2022, 20:18:08] [TuyaPlatform] [TuyaOpenAPI] Request:
method = post
endpoint = https://openapi.tuyaeu.com
path = /v1.0/devices/bfe0ec7a8ab4854756bmm5/commands
query = null
headers = {
  "t": "1669148288181",
  "client_id": "k3akuj97e4kxyckwg3yg",
  "nonce": "9f2c01ac-9360-4fb2-b9f6-d15c9e9f4e37",
  "Signature-Headers": "client_id",
  "sign": "FA53629AF8714BC094B9D01DF4B1ADBAE3EF8F5AD98C3BCF56FA355814A4D6D1",
  "sign_method": "HMAC-SHA256",
  "access_token": "",
  "lang": "en",
  "dev_lang": "javascript",
  "dev_channel": "homebridge",
  "devVersion": "1.6.0-beta.38"
}
body = {
  "commands": [
    {
      "code": "switch_1",
      "value": false
    }
  ]
}
[22/11/2022, 20:18:15] [TuyaPlatform] [TuyaOpenAPI] Response:
path = /v1.0/devices/bfe0ec7a8ab4854756bmm5/commands
data = {
  "result": true,
  "success": true,
  "t": 1669148295847,
  "tid": "cbff38286aa211edadcaa64798946735"
}
[22/11/2022, 20:18:16] [TuyaPlatform] [TuyaOpenMQ] onMessage:
topic = cloud/token/in/199b1625e164f38cf2d40590bc64cae6
protocol = 4
message = {
  "dataId": "4ee209e7-9f8a-462b-bd0d-b3cd98957dc7",
  "devId": "bfe0ec7a8ab4854756bmm5",
  "productKey": "jqo111f6ahvas3tr",
  "status": [
    {
      "1": false,
      "code": "switch_1",
      "t": "1669148295",
      "value": false
    }
  ]
}

Using Tuya app the switch works instant, only via homebridge it takes a lot of time.
Here are the logs at the time of using Tuya app:

[22/11/2022, 20:23:50] [TuyaPlatform] [TuyaOpenMQ] onMessage:
topic = cloud/token/in/199b1625e164f38cf2d40590bc64cae6
protocol = 4
message = {
  "dataId": "0a09fd27-2f07-4d91-ad51-0b1668eb4000",
  "devId": "bfe0ec7a8ab4854756bmm5",
  "productKey": "jqo111f6ahvas3tr",
  "status": [
    {
      "1": false,
      "code": "switch_1",
      "t": "1669148629",
      "value": false
    }
  ]
}
[22/11/2022, 20:23:50] [TuyaPlatform] [Terrace] Update value true => false for service = '00000049-0000-1000-8000-0026BB765291', subtype = 'switch_1', characteristic = '00000025-0000-1000-8000-0026BB765291'

[0x5e]

Wow Starlink... cool.
I think turn on or turn off doesn't have relation with latency, guess it's much like the network issue.
Let me explain why Tuya app is instant, in the same wifi the app will use lan protocol communicate with the device so it's quick.
If not in the same wifi, app use mqtt to send the command, which is different with plugin - It is a private method, so plugin are not able to use.
And tuya app's mqtt is using quic instead of tcp, in bad network will have better performance. - Not able to use too...

Could you try ping openapi.tuyaeu.com and see what's the max and min latency? The latency of internet will double the time of your control, if ping is 2s, then control command from plugin to tuya cloud cost 2s, and then tuya cloud send to device cost 2s too. Same as the state update response.
Lan protocol will be much suitable for you but... please see #90 .

[bimusiek]

Ok, after realising that it connects through Cloud api which means internet connection needs to be stable I checked my Grafana logs of speedtests and indeed, there was something off... I checked my network and basically one switch was connected via broken cable in 100mbs mode. After replacing cable and internet connection being stable it works much quicker now.