1. Server sends unlock command. 2. Device sends ‘OK’ on receiving the request. 3. Device sends ‘unlock report’ to server on successfully unlocking and does not send anything if not unlock failed. 4. On receiving ‘unlock report’, lock status gets updated to ‘unlock’.
Device behavior on lock:
1. On manual locking, device sends lock report to server. 2. On receiving lock report, lock status gets updated to ‘lock’ in database.
On every heartbeat from device (asynchronous of unlock/lock commands):
1. On receiving heartbeat, current lock status gets updated in database.
Middleware takes action as per follows on receiving unlock request:
1. Acknowledge sent to jugnoo immediately. 2. Check the current status in database. 3. If already unlocked, lock status (update_lock_status) response is immediately sent to Jugnoo and no command is sent to device 4. If locked, unlock command is sent to device and waits for ‘unlock report’ 5. On receiving ‘unlock report’ from device, lock status (update_lock_status) response is immediately sent to Jugnoo. Response time from device is usually 3s for sending unlock report. 6. A mandatory current lock status (update_lock_status) response will be sent after 10s if request response was not already sent. This will contain current lock status. 7. On any change in lock status, current lock status (update_lock_status) response is sent out immediately.
Middleware takes action as per follows on receiving lock request:
1. Acknowledge response sent to jugnoo immediately. 2. Check the current status in database. 3. Current lock status (update_lock_status) response is immediately sent to Jugnoo and no command is sent to device. 4. On receiving ‘lock report’ from device, lock status (update_lock_status) response is immediately sent to Jugnoo. Response time from device is usually 3s for sending lock report. 5. A mandatory current lock status (update_lock_status) response will be sent after 10s if request response was not already sent. This will contain current lock status. 6. On any change in lock status (e.g. from heartbeat), current lock status (update_lock_status) response is sent out immediately.
Response times from device:
Signal strength (>= 2/5): ● Unlock command: ○ For command response: upto 2s; average 1s ○ For unlock report: upto 5s; average 3s ● Lock: ○ For lock report after manual locking: upto 4s
Weak signal strength (1/5):
● Unlock command: ○ For command response: maximum upto 26s; around 10s ○ For unlock report: maximum upto 26s; around 10s ○ At other times, device doesn’t respond and it re-initiates socket connection. This can take upto 2 min. ● Lock: ○ For lock report after manual locking: observed upto 12s Device Type: BL10-S
Device behavior on unlock:
1. Server sends unlock command. 2. Device sends ‘Enable OK’ on successful unlocking and ‘Enable Fail’ on failure. 3. Device does not send anything if command not received or action not performed.
Device behavior on lock:
1. Server sends lock command. 2. Device sends ‘Lock OK’ on successful locking. 3. Device does not send anything if command not received or action not performed.
On every heartbeat from device (asynchronous of unlock/lock commands):
1. On receiving heartbeat, current lock status gets updated in database.
Middleware takes action as per follows on receiving unlock request:
1. Acknowledge sent to jugnoo immediately. 2. Check the current status in database. 3. If already unlocked, lock status (update_lock_status) response is immediately sent to Jugnoo and no command is sent to device 4. If locked, unlock command is sent to device and waits for ‘enable ok’ response. 5. On receiving ‘enable ok’ from device, lock status (update_lock_status) response is immediately sent to Jugnoo. Response time from device is usually 3s for sending response. 6. A mandatory current lock status (update_lock_status) response will be sent after 10s if request response was not already sent. This will contain current lock status. 7. On any change in lock status, current lock status (update_lock_status) response is sent out immediately.
Middleware takes action as per follows on receiving lock request:
1. Acknowledge response sent to jugnoo immediately. 2. Check the current status in database. 3. If already locked, lock status (update_lock_status) response is immediately sent to Jugnoo and no command is sent to device. 4. If unlocked, lock command is sent to device and waits for ‘lock ok’ response. 5. On receiving ‘lock ok’ from device, lock status (update_lock_status) response is immediately sent to Jugnoo. Response time from device is usually 3s for sending locking response. 6. A mandatory current lock status (update_lock_status) response will be sent after 10s if request response was not already sent. This will contain current lock status. 7. On any change in lock status (e.g. from heartbeat), current lock status (update_lock_status) response is sent out immediately. Response times from device: ● Good signal strength (>=4/5): ○ Unlock: ■ For unlock response: upto 6s; average 3s ○ Lock: ■ For lock response: upto 4s; average 3s