Good find, thing is I'm using which should be an updated version as the original noble is no longer maintained. Maybe this helps: noble/noble#877 and/or noble/noble#400 There are a lot of command types and data structure versions for both what the SDK sends to the lock and what the lock replies also.īut I think the most important, at least for now, are door locks and newer SDK versions (in my example, it's 05 - yours will probably/hopefully have the same version) I saw that you already have included it into this repo, so I might try it out and see what happens. using sleep()) between sending each packet.īefore the initialization of the lock there is a default AES key that is being used Sending more than 20 bytes via BLE is easily achievable by splitting your data into 20 byte packets and implementing a short delay (i.e. If you want to send more than 20 bytes, you should define array byte to contain how many packets you want. Probably the 20 bytes is a limit somewhere.īLE allows you transfer maximum of 20 bytes. Yeah, I was curious if this is something standard in BLE communication (split read/writes to some characteristic into 20 bytes blocks and then add CRLF to the last one). Considering what you've done, I think you are already many lightyears ahead of me - Just looking at this confused the heck out of me :Dīut still, I will look into it as soon as I have some time (and patience), sounds interesting enough. that needs to persist between different runs.ītw, there is some reading material inside docs/SDK-Analysis.md if you feel like messing up with the lock some more :D This is where I got the original info posted in my repo.Īfter that, the initialisation should theoretically be straight forward.īut, even after the init is complete, I still need to find a way to store all the private data about the lock, like passwords, aes key etc. If you want I can send you a hci_dump from my cellphone. Next step for me is to create the logic to read/write the required characteristics (this happens in 20 bytes blocks aparently, that's what the CRLF is for at the end of the last packet, is this something standard ?) and handle subscriptions and notifications (to get responses back from the lock).ĬRLF as it seems happen on every packet, afaik. But there is no real communication just yet. There is also the command object that builds the command packets. I built some wrappers around the bluetooth objects (device, service, charcteristics etc.) to ease the communication flow. Would probably be wiser to chat on Disord or Telegram, what do you think? Since this is the only way of communicating, I had to open an Issue. My question is more asking which is the next step.
0 Comments
Leave a Reply. |