Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After power cycle bthome broadcasts using random bindkey #372

Closed
agittins opened this issue Sep 10, 2023 · 4 comments
Closed

After power cycle bthome broadcasts using random bindkey #372

agittins opened this issue Sep 10, 2023 · 4 comments

Comments

@agittins
Copy link

After I power-cycle my LYWSD03MMC's, they start broadcasting with what I think is a randomised bindkey, not the one I had configured it with. The bindkey appears to be stored in flash OK, and works if I re-configure the bindkey, but stops working after a power-cycle.

Steps to reproduce:

  • Configure LYWSD03MMC with:

    • advertising format: BTHome
    • adv flags: on
    • encrypted: on
  • Send a bind key to the device

    • it reports it written and read OK (so looks like the flash write is good).
  • disconnect

    • homeassitant then starts receiving encrypted advertisements, and homeassistant's bthome integration decrypts them OK.
  • Remove the battery from the device for several seconds, then reinstall battery.

    • advertisements are still encrypted but homeassistant cannot decrypt them with the previously working bindkey.
  • Connect to the device

    • "read bindkey" shows correct, original bindkey.
    • "write bindkey"
    • disconnect
  • Device sends encrypted advertisements, and homeassistant can decrypt them OK.

(note: currently Homeassistant's BTHome integration has a bug where it gets stuck trying to re-auth/reconfigure the device, I'll link to the PR to fix that once I've raised it)

Guesses :-)

I notice that init_ble is called before bindkey_init but I don't know if that matters at all.

Since I can read the bindkey after a reboot it looks like the flash is working OK, but for some reason the device starts up not using the bindkey that is stored in flash.

@pvvx
Copy link
Owner

pvvx commented Sep 10, 2023

You are using 2 bind-keys.
One from the official firmware or the latest "Authorization" and the second - recorded in memory with custom firmware in flash_eep.
These are different keys.
Processing priority:
First of all, the key recorded during activation or registration in MiHome is used. It is written to a special Flash area and can be used to restore the official firmware. These keys can be erased or changed in "TelinkMiFlasher".
If this key is not available, then the key is taken from flash_eep, which will be saved for all versions of alternative firmware and will not be erased by the official firmware.

@agittins
Copy link
Author

Ahh, thank you for your edit, that clarifies things for me a lot.

So I should use the "Show all mi keys" button then "!Erase all Mi Keys!" button to clear them?

I am curious why the custom firmware loads the mi key at all instead of just loading the flash_eep by default?

@pvvx
Copy link
Owner

pvvx commented Sep 10, 2023

Because it can work with Xiaomi gateway if you know the keys and entered them during flashing (use key "Login"), and also if after "authorization" the replace key with the previous one button is used.


In the new version 4.4 (current status: beta version), only the value from the "EEP BindKey" is taken as the binding key.

@pvvx pvvx closed this as completed Sep 20, 2023
@agittins
Copy link
Author

agittins commented Oct 6, 2023

In the new version 4.4 (current status: beta version), only the value from the "EEP BindKey" is taken as the binding key.

Fantastic, thanks! That feels a lot more logical. I've tried the beta on a couple of devices and it seems to be working well 👍🏼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants