Device paired; not getting unlock notifications

[cemilbrowne]

Hi!

Great tool; happy to help debug. I've got a lock. Lock/Unlock work OK from UI and fine on lock, but I don't seem to get UNLOCK messages into my MQTT broker.

Any ideas?

[Fusseldieb]

Hi,
can you share the log that's been generated from the add-on when you lock/unlock and wait a bit?

The unlock events should be generated, afaik, within max. 10 seconds, see: https://github.com/kind3r/ttlock-sdk-js#monitoring-for-lockunlock-events

Or do we need to run "npm run listen" explicitly? @kind3r might know more about, I'm a little bit out of the loop.

[ddv2005]

I got the same issue. Some timesI see notifications in Addon logs but most times no update to HA.
This is "npm run listen" log

> [email protected] listen
> npm run build && node --trace-warnings ./examples/listen.js


> [email protected] build
> rm -rf ./dist && tsc

Scan started

Peripheral connect start
Peripheral connect triggered
Peripheral state: connected
Device emiting connected
BLE Device reading basic info
BLE Device discover services start
BLE Device discover services end
BLE Device read characteristics start
BLE Device read characteristics end
BLE Device read characteristics start
BLE Device read characteristics end
BLE Device read basic info
BLE Device subscribed
Connected to known lock, reading general data
========= feature list
Lock waiting for connection to be completed
<Buffer 59 75 cc d5 f7 00 00 05 04 00 00 00 00 00 00 00 00>
========= feature list Set(20) {
  0,
  1,
  2,
  4,
  5,
  6,
  7,
  8,
  10,
  12,
  14,
  15,
  18,
  19,
  22,
  23,
  24,
  28,
  29,
  30
}
========= check admin
========= check admin: XXXXX
========= check random
========= check random
========= autoLockTime
========= autoLockTime: 5
========= lockSound
========= lockSound: 1
Connected to a known lock


Disconnected from a known lock
Emmiting paramsChanged { batteryCapacity: false, newEvents: true, lockedStatus: false }
Reconnecting to lock to read log
Peripheral connect start
Peripheral connect triggered
Peripheral state: connected
Device emiting connected
BLE Device reading basic info
BLE Device discover services start
BLE Device discover services end
BLE Device read characteristics start
BLE Device read characteristics end
BLE Device read characteristics start
BLE Device read characteristics end
BLE Device read basic info
BLE Device subscribed
Connected to known lock, reading general data
Lock waiting for connection to be completed
========= get OperationLog 65535
[]
>>>>>> Lock is now locked <<<<<<
Disconnected from a known lock

[ddv2005]

May be it happening because get OperationLog is empty because G2 gateway already took new log entries. And sometimes I got an error on connect to get a log.

[ddv2005]

I found another problem - unlock/lock events in ha.js just emit the same event handler (updateLockState) that update to CURRENT lock state. The problem is that if auto lock occurs before update event is fired then it always miss unlock event.

[kind3r]

@ddv2005

May be it happening because get OperationLog is empty because G2 gateway already took new log entries. And sometimes I got an error on connect to get a log.

Indeed that is the case. How this works:

• the lock broadcasts it's BLE advertisment packets
• those packets contain a byte that states if there are new events in the log
• if such a packet is received, the addon checks for changes and so the byte is automatically reset
  Since the G2 does the same, it resets the 'new events' byte before the addon has a chance to detect it.

@cemilbrowne
What are you trying to achive with MQTT? The lock device in HA exposes the locked/unlocked status and you can create an automation based on that.

[kind3r]

@ddv2005

I found another problem - unlock/lock events in ha.js just emit the same event handler (updateLockState) that update to CURRENT lock state. The problem is that if auto lock occurs before update event is fired then it always miss unlock event.

I'm not sure this is an issue, this is handled in manager.js:_onLockUpdated() triggered by lock's updated event which is emited by the SDK when the broadcasted BLE packet is received, which the lock should emit when it is being unlocked. _processOperationLog reads the operations log first and emits locked and unlocked events as they are read from the log, and finally it checks the current state and if it differs from the one in the logs it updates once again.

So, even if one packet is missed, at some point it will replay all the lock/unlock events from the operations log.