shmuelzon
commented
3 years ago Hey,
Thanks for the detailed description. There are a few things here that I'll try to address. First, if you do not wish to connect to a peripheral, you can always blacklist it (or not whitelist it) but broadcasts would still work.
As for the broadcast data, I'm not sure exactly what the payload looks like but, if you're familiar with it, it can be added to the list of supported broadcasters. There is another Mijia device there, perhaps it would be similar. If you can't or don't know how to add support for another broadcaster, send me the format of the advertisement packet and I'll try to add it myself. I will need a way to identify this type of device though.
Regarding the usage of the stock firmware or not, I don't really mind having both supported. If the only thing missing is the bind key, we can add it to the same list of passkeys so as not to create a special configuration entry just for it (though it would probably need to be a string and not a number) and implement the decoding when parsing the advertisement data.
Hope that helps
ozonejunkieau
RoganDawes
Is your feature request related to a problem? Please describe. I have recently acquired a number of the abovementioned temperature and humidity sensors. Unfortunately, their advertisements are encrypted using a bind key, which means that they do not work immediately. Rather, there is a process that needs to be performed to obtain the bind key, so that the advertisements can be decrypted. This is documented here (https://github.com/atc1441/ATC_MiThermometer), which provides a web-bluetooth app to do so, along with an alternate firmware that removes the encryption on the advertisements. When using the alternate firmware, ble2mqtt IS able to extract the readings from the various advertised services, however, this likely comes at a cost to the battery lifespan, as ble2mqtt has to be connected to the device, rather than simply receiving the broadcasts.
Describe the solution you'd like It would be ideal if ble2mqtt could perform the required decryption of the advertisements by the stock firmware, alternatively, decoding the advertisements from the replacement firmware, or at least, rebroadcast the advertisements via mqtt so that a more capable/configurable service can do the necessary decryption or parsing.
It is understood that the configuration file would need to be extended to provide the bind key associated with the specific MAC address (in the first instance), or the code would need to be updated to identify, parse and rebroadcast the advertisements issued by the replacement firmware.
Describe alternatives you've considered ESPHome already has support for decrypting the stock firmware's advertisements, so if this is not a desirable feature for esp-ble2mqtt, alternatives do exist.
Additional context https://esphome.io/components/sensor/xiaomi_ble.html#lywsd03mmc https://atc1441.github.io/TelinkFlasher.html