Adding a status command

[Ircama]

Congratulations for this code!

I can confirm that it works as per documentation on a Raspberry Pi Zero W with Raspbian O.S.

I anyway think that there are a couple of possible improvements: removing the currently included delays (the code has at the moment one delay of 5 seconds and another one of 10 seconds which might be optimized) and adding the status command (useful feature; e.g., door is currently locked/unlocked).

I tried to test key_ble.request_status(), which, if I am not wrong, is always returning null data (regardless the actual state of the door):

{ '0':
   { __type__:
      { __super__: [Object],
        id: 131,
        label: 'STATUS_INFO',
        properties: [Object] },
     data_bytes: [],
     data:
      { a: false,
        user_right_type: 0,
        e: false,
        f: false,
        g: false,
        h: false,
        i: false,
        j: false,
        lock_status: 0,
        l: undefined,
        m: undefined } } }

Notice that I also used a similar test code to dump keyble.ensure_nonces_exchanged() and some information is returned in this case:

{ '0':
   { __type__:
      { __super__: [Object],
        id: 3,
        label: 'CONNECTION_INFO',
        properties: [Object] },
     data_bytes: [ 5, 53, 34, 245, 210, 138, 108, 142, 235, 0, 16, 23, 0, 0 ],
     data:
      { user_id: 5,
        remote_session_nonce: [Array],
        bootloader_version: 16,
        application_version: 23 } } }

Can you advise on how to get the locked or unlocked state of the device?

[oyooyo]

You're perfectly right about everything.

Those delays are rubbish, I introduced them as a dirty temporary workaround when I realized a certain problem, but the problem should be solved differently.

And unlike what the name suggests, key_ble.request_status() currently really does not return the actual status; it actually just sends the "request_status" command, but does not wait for the response from the device.

Even worse, the code currently does not interpret status information data sent by the device at all. The output of the keyble-sendcommand tool for example is currently more or less just fake.

The issues you've mentioned are actually what I too consider the most pressing issues right now. I'll try to fix them soon.

[oyooyo]

The mentioned issues should be solved in the latest version: The delays are removed and replaced with a proper solution, and the request_status() command now resolves to an array like [2, "unlocked"], where the first element is the status code as an ID, and the second argument is the status code in string form.

Closing this issue for now.