Plugin slows down Homebridge

[cemilbrowne]

Describe The Bug: Logs report slowing down HB:

To Reproduce: Simply enable ttlock plugin

Expected behavior: No errors, I assume? Logs:

[8/23/2022, 7:49:45 AM] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Current State' didn't respond at all!. Please check that you properly call the callback! See https://homebridge.io/w/JtMGR for more info.
[8/23/2022, 8:06:27 AM] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Current State' was slow to respond! See https://homebridge.io/w/JtMGR for more info.
[8/23/2022, 8:06:27 AM] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Target State' was slow to respond! See https://homebridge.io/w/JtMGR for more info.
[8/23/2022, 9:01:56 AM] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Current State' was slow to respond! See https://homebridge.io/w/JtMGR for more info.
[8/23/2022, 9:01:56 AM] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Target State' was slow to respond! See https://homebridge.io/w/JtMGR for more info.
[8/23/2022, 9:02:02 AM] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Current State' didn't respond at all!. Please check that you properly call the callback! See https://homebridge.io/w/JtMGR for more info.
[8/23/2022, 9:02:02 AM] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Target State' didn't respond at all!. Please check that you properly call the callback! See https://homebridge.io/w/JtMGR for more info.

Plugin Config:

        {
            "name": "TTLock",
            "clientid": "xxx",
            "clientsecret": "xxx",
            "username": "xxx",
            "password": "xxx",
            "batteryLowLevel": 15,
            "maximumApiRetry": 5,
            "platform": "ttlock"
        }

Screenshots: N/A Environment:

• Plugin Version:
• Homebridge Version:
• Node.js Version:
• NPM Version:
• Operating System:

[bwitting]

I updated to the new API endpoints at request of TTLock and the API seems much faster to me. Please update when you get a chance and see if that makes a difference for you.

[batkoto]

I am getting the same issue unfortunately.

[23/09/2022, 10:09:30] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Target State' didn't respond at all!. Please check that you properly call the callback! See https://homebridge.io/w/JtMGR for more info.

Will running this as child bridge going to improve the overall handling? Has this been tested as child bridge?

[j88nyr]

[13/11/2022, 20:59:34] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Current State' was slow to respond! See https://homebridge.io/w/JtMGR for more info. [13/11/2022, 20:59:34] [homebridge-ttlock] This plugin slows down Homebridge. The read handler for the characteristic 'Lock Target State' was slow to respond! See https://homebridge.io/w/JtMGR for more info.

Getting the same, but it seems to be running okay! Think it might just be the time for the gateway to respond. Either way, so glad this is working!!! :)

[j88nyr]

After playing with it a bit more, it does seem the lag causes issues. I don't get a notification when unlocking the door without HomeKit, and when doing it via HomeKit I'd say its only about 25-50% successful.

[fmp777]

@cemilbrowne This is still a complaint by homebridge, i wonder if its related to the homekit not getting proper status updates. You slide to unlock and it stays in a "unlocking..." state perpetually until presumably a timeout occurs. Homebridge logs show the gateway command was successful, the lock unlocks, but homekit doesn't know what happened with the request.

Also, many of these locks are set to unlock for something like 5 seconds, before they automatically relock. So a routine to check and update status is important for Homekit to function properly?

[fmp777]

[fmp777]

@cemilbrowne Based on my direct API tests, TTLock API will often take 3-7 seconds to process any queryOpenState or lock/unlock.

Sounds like Homebridge doesn't want to wait that long to get a reply, it prefers that you handle the API call asynchronously and immediately return the last known value (or maybe the anticipated value?). Then once your API call is done, it wants you to call .updateValue on the characteristic. In other words, don't await those axios calls, then add an axios handler that runs updateValue directly on the characteristic.

My concern is what homebridge does with the promise... i would imagine it is dropping the promise then catching the error "this plugin slows down homebridge". If so, then this plugin would appear to be very unstable.

[fmp777]

@bwitting sorry i was tagging the OP on this 😆 - i did some debugging and proposed a solution above.

[bwitting]

@bwitting sorry i was tagging the OP on this 😆 - i did some debugging and proposed a solution above.

@fmp777 Thanks for that, I will check it out. Honestly I haven’t messed with this a bunch since I released it - I’m getting those messages too but running on a child bridge, it doesn’t seem to matter and it is working well enough for my purposes. But I’ll see if I can make these changes and get it resolved.

[fmp777]

@bwitting Looks like @cemilbrowne already reworked some things, might be worth taking a look at? https://github.com/bwitting/homebridge-ttlock/compare/master...cemilbrowne:homebridge-ttlock:quicker_responses

[fmp777]

@bwitting Well, @cemilbrowne really refactored quite a bit, but not sure it really handles the responsiveness right? I see timeouts of 6 seconds on the axios calls, but that will simply trigger incorrect errors because in my tests, the api frequently takes more than 6 seconds to get a lock status.

    const response = await axios.post<LockResponse>('https://euapi.ttlock.com/v3/lock/queryOpenState', qs.stringify({
      clientId: this.platform.config.clientid,
      accessToken: this.accessToken,
      lockId: lockId,
      date: now,
    }), {
      headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
      },
      timeout: 6000,
    });
    if (response.data.errcode === null || response.data.errcode === undefined) {
      this.platform.log.debug('Got Lock Response: ' + response.data.state);
    } else {
      this.platform.log.error('Ensure your TTLock API keys and username/password are correct in the config. Error: ' +
        response.data.errcode);
    }
    return response.data;
  }

so in this case its giving me this "ensure your api keys are correct" error, but thats false, its not erroring because of my api keys, its erroring because of the 6 second timeout on the axios call.

[bwitting]

@fmp777 - After messing with it this weekend, man it feels like the API responsiveness is poorer than when I was initially working on this plugin. Nothing we can do about their infrastructure, but not really sure the best way to handle this in HB. Will keep looking at it this week.