BLE-bridge for certain Mijia-Bluetooth-sensors via NRF24L01

[Staars]

Description:

-adds a generic driver for the NRF24L01 based on slightly modified RF24-library
-add sensor driver to sniff BLE-advertisements from certain BLE-sensors and present them as "virtual" sensors via MQTT and WebUI (currently MJ_HT_V1 and Mijia Flora Sensor)

(some changes to my_user_config.h in the SPI/DISPLAY-section must be reverted before a potential merge)

Checklist:

• The pull request is done against the latest dev branch
• Only relevant files were touched
• Only one feature/fix was added per PR.
• The code change is tested and works on core 2.6.1
• The code change pass travis tests. Your PR cannot be merged unless tests pass
• I accept the CLA.

[Staars]

NRF24l01(+)

This chip is manufactured by Nordic Semiconductors as a single chip transceiver in the 2,4 GHz band. There are many applications in wireless consumer products and the chip is well-known in many Arduino-projects as a versatile low-cost-solution.
In recent years solutions were found to use this chip for limited Bluetooth-Low-Energy communication.
One of the first articles about this topic can be found here:
https://dmitry.gr/?r=05.Projects&proj=11.%20Bluetooth%20LE%20fakery

Several further work was done later on by different developers and a working bridge to read sensor data from a XIAMO-MI_HT_V1 already exists.
The fundamental principle is, that some of these sensors send its data as a usual BLE-advertisement packet with a proprietary data format at the end of the payload. These packets had to fit into the 32 bytes of the FIFO-RX-buffer of the NRF24l01, otherwise the "later" bytes were lost.

For the Tasmota-driver a new solution was found.
The basic idea is to use some constant ID-bytes of the BLE-packets as the PDU-type for the NRF24l01. Thus, all bytes before these ID-bytes are lost and the size restriction for the payload is successfully circumvented. That way it is possible to read the sensor data from a Mi Flora sensor, which is positioned outside of the 32-byte-range.
Of course there is still no bidirectional "real" BLE-communication, only advertisements can be read.

USAGE:

Uncomment #USE_SPI and #USE_NRF24 and configure the pins vor SPI_DC and SPI_CS while connecting the hardware SPI pins 12 - 14(MOSI, MISO and CLOCK). Comment out all other SPI-related (display-)drivers. No additional steps are necessary.
The driver will do the rest automatically and starts to look for known BLE-advertisements. When it finds one, the corresponding "special" packets will be used to extract the sensor readings.
Web-GUI and TELE-messages will be populated with the sensor data.

For the first driver versíon multiple MI_HT_V1-sensors and Flora-sensors are supported. They will be discriminated by using the company-assigned ID of the BLE Public Device Address (= the "lower" 24 bits). So a TELE-message could like like this:

10:13:38 RSL: stat/tasmota/STATUS8 = {"StatusSNS":{"Time":"2019-12-18T10:13:38","Flora-6ab577":{"Temperature":21.7,"Illuminance":21,"Humidity":0,"Fertility":0},"MJ_HT_V1-3108be":{"Temperature":22.3,"Humidity":56.1},"TempUnit":"C"}}

As the NRF24l01 can only read BLE-advertisements, only the data in these advertisements is accessible.
All sensors have an additional GATT-interface with more data in it, but it can not be read with a NRF24l01.

The driver tries to figure out, if the NRF24l01(+) is still working and will internally re-init the radio, if no data is received for a certain period of time (default = 120 sec).
As we can not use a checksum to test data integrity of the packet, only data of sensors, which adresses showed up more than once (default = 3 times) will be published. Internally from time to time "fake" sensors will be created, when there was data corruption in the address bytes.

Working sensors:

MI_HT_V1:

This device works with an AAA-battery for several months and the driver can read temperature, humidity and battery level.

Mi Flora:

Works with a CR2032-coin-cell and provides temperature, illuminance, (soil-)humidity and (soil-)fertility.

It can not be ruled out, that changes in the device firmware may break the functionality of this driver completely !!!

[Staars]

[Staars]

That should work, as long as they did not change the internal working. From the outside and specs I have the same sensor at home. Please keep in mind, that this is really hacky and experimental stuff. So only buy it, if you have a „plan b“ to use it. I already published a WIKI-entry on tasmota.com for it. Best regards Christian

…

Am 05.01.2020 um 13:24 schrieb markusb68 ***@***.***>:  Hi, does it also support the one with the round Display? https://de.aliexpress.com/item/32846083629.html — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[fragolinux]

I already published a WIKI-entry on tasmota.com for it. Best regards Christian

sorry, can't find it, can you share a link, please? Thanks

[Staars]

Tasmota.com -> Documentation -> Peripherals -> MIBLE

[markusb68]

Today I pulled the sources, made the changes in the my_user_config.h and compiled.
Now I get this on the console:

00:00:00 Project mihome Tasmota Version 8.1.0.5(tasmota)-2_6_1
00:00:00 NRF24L01 initialized
00:00:00 NRF24L01+ detected
00:00:00 MIBLE: started

but my "MI_HT_V1" is not seen:

Any hints / solution?

[Staars]

Please compile with uncommented
#define DEBUG_TASMOTA_SENSOR // Enable sensor debug messages
in my_user_config.h.

Then watch the console (with seriallog 3)

So far I can see no error in your config. Maybe we can find some more infos.

[markusb68]

There is not much. Hope it helps:

...
20:39:34 MIBLE: check for FAKE sensors
20:39:34 MIBLE: Change packet mode after 60 seconds, MIBLE.timer: 601
20:39:34 MIBLE chip connected
20:39:34 MIBLE: Change Mode to 2
20:40:34 MIBLE: check for FAKE sensors
20:40:34 MIBLE: Change packet mode after 60 seconds, MIBLE.timer: 601
20:40:34 MIBLE chip connected
20:40:34 MIBLE: Change Mode to 3
20:41:34 MIBLE: check for FAKE sensors
20:41:34 MIBLE: Change packet mode after 60 seconds, MIBLE.timer: 601
20:41:34 MIBLE chip connected
20:41:34 MIBLE: Change Mode to 1
....
etc.

[Staars]

Okay, no signs of data traffic.
Please try in that order:
1)
Change line 836 to:
MIBLEinitBLE(0);
and line 619 to:
MIBLEinitBLE(0);

This should catch generic Xiaomi-packets and show „something“ in the console.

Change line 630 to:
if(MIBLE.buffer.bleAdv.header.uuid!=0xfe95){ // XIAOMI-BLE-Packet

This should show all captured packets and produce lots of traffic in a normal environment with many bluetooth devices around.

Test you hardware setup with a sketch of your choice to test the general functionality of the used hardware.

BTW, this channel is not intended for this kind of support. If possible grab me on discord or open an issue. That way every information is available for all users.

Good luck!

[markusb68]

Hello Christian, just opened an new issue:
[https://github.com//issues/7642]