kind3r / hass-addons

Integration of the offline TTLock sdk into Home Assistant
66 stars 26 forks source link

Device paired; not getting unlock notifications #17

Open cemilbrowne opened 3 years ago

cemilbrowne commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

> ttlock-sdk-js@0.3.14 listen
> npm run build && node --trace-warnings ./examples/listen.js

> ttlock-sdk-js@0.3.14 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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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:

@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. image

kind3r commented 3 years ago

@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.