[REQUEST] Support LYWSD03MMC custom FW developed by @atc1441 (no data encryption in BLE Advertisement)

[ercoleg]

Have you looked for this feature in other issues and in the docs?

Yes, I didn't find anything related to this feature request

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.

Yes, the feature request is related to the fact I didn't succeed getting information from LYWSD03MMC using wemos D1 mini and NRF24L01. Looking for a solution online I found a Github repository in which I found a useful tool to obtain bind_key and flash LYWSD03MMC with a custom FW LYWSD03MMC OTA Flasher_Tool.

Describe the solution you'd like
A clear and concise description of what you want to happen.

I would like Tasmota FW to support this custom FW in order to easily get temperature and humidity information from BLE advertising and change BLE advertising frequency (new feature of LYWSD03MMC custom FW) .

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

I was considering to use TASMOTA actual implementation but after several attempts I was frustrated.

Additional context
Add any other context or screenshots about the feature request here.

I think that this custom FW offers additional features to LYWSD03MMC (in particular BLE advertising frequency) that could be useful to all the TASMOTA community.

(Please, remember to close the issue when the problem has been addressed)

[Staars]

Support for the ESP32 is done.

Now I‘ll take a look at the NRF24, which is technically more complicated.

[ercoleg]

Is the ESP32 supporting the BLE advertising data retrieve or connects the device to get the data? is this support integrated in tasmota 8.5.0? is there any specific configuration to enable or just comment the define: #define USE_MI_DECRYPTION

For NRF24 the approach could be similar to the actual approach, just getting the payload and convert it without decrypting.

Thank you for your support

[Staars]

Tasmota (latest self compiled development version from today) on the ESP32 supports all possible configs for the LYWSD03MMC:

original FW:

define USE_MI_DECRYPTION

-> You need to pass the bind_key as described in the DOCS.

//#define USE_MI_DECRYPTION -> Direct connection to the device periodically as described in the DOCS. (MI32PERIOD)

custom ATC FW: -> Automatic finding/reading of the sensor. No further configuration needed.

NRF24 is way more complicated than you seem to think ;)

[ercoleg]

I will try all the different combinations on ESP32 tonight, and I'll come back to you soon.

With NRF24 I didn't succeed decrypting the payload even with the bind_key configured (is the MAC address case sensitive?). The sensor appears on the web UI but all the data appear as null. do I have to enable #define USE_MI_DECRYPTION also in NRF24 configuration or other?

Thank your for your superquick answers!

[Staars]

define USE_MI_DECRYPTION is enabled by default for the NRF24.

You know, that the original FW sends only every 10 minutes? So you might have to wait a bit. I will test with current version ASAP, but can not promise a time.

BTW, the hard part for the NRF24 is to catch the BLE-packets, because it simply is not a BLE-device. Parsing the payload is a piece of cake in comparison.

[ercoleg]

I have tested the NRF24 for hours with serial line debug, LYWSD03MMC was recognized but the payload wasn't decrypted. Anyway I wait for your test results, and I'll perform the tests on ESP32 with latest development version soon. Thank you for your time!

[Staars]

After a day of strange hardware failures (a Wemos cooked up, a NRF-module was dead on arrival, ...) I can confirm that:

1. The ATC-webflasher really does generate a valid bind_key, which is totally amazing.
2. The current NRF24-driver does work flawlessly with this key. Did you provide the key+MAC-string in uppercase letters? (I will probably make this case insensitive in a new version).
3. After flashing the custom firmware, the LYWSD03 becomes invisible to the NRF24. I can not explain this ATM as my NRF24 can still see other BLE devices. Maybe it's a coincidence, I will do more tests later.

[ercoleg]

today I have performed some tests: 1) cloned latest today version of Tasmota FW 2) configured user_config_override.h in order to enable NRF24 `#define USE_SPI // Hardware SPI using GPIO12(MISO), GPIO13(MOSI) and GPIO14(CLK) in addition to two user selectable GPIOs(CS and DC)

ifndef USE_NRF24

define USE_NRF24 // Add SPI support for RF24L01(+) (+2k6 code)

define USE_MIBLE // BLE-bridge for some Mijia-BLE-sensors (+4k7 code)

endif`

3) got with ATC-webflasher the bind_key and configured it in tasmota console 14:50:14 CMD: NRFKey 024b0c6508c864af69e68302f025e20da4c1388c6a32 14:50:14 RSL: stat/tasmota_489752/RESULT = {"NRFKey":"024b0c6508c864af69e68302f025e20da4c1388c6a32"} 4) got the following information on the web_UI NRF24L01+ 1 / 1 LYWSD03 MAC Address a4:c1:38:8c:6a:32 LYWSD03 Temperature null °C LYWSD03 Humidity null % LYWSD03 Dew point null °C and this one on the console 14:57:54 MINRF: new LYWSD03 at slot: 0 14:57:55 MINRF: new LYWSD03 at slot: 1 15:04:24 RSL: tele/tasmota_489752/SENSOR = {"Time":"2020-09-17T15:04:24","LYWSD03-8c6a32":{}}

do have any hint to make it working?

thank you for your time

[Staars]

Yes, for the current driver you must provide key+MAC in uppercase, not lowercase characters.

[ercoleg]

Thank you! Problem Solved, I submitted a mod to tasmota documentation in order to share the lesson learnt with the community. during the weekend I'll do some tests with ATC FW, in order to confirm your results.

[ercoleg]

@Staars I have done some tests today and I can confirm that: Flashed ATC Custom FW configured with the following configurations: 1) send Mi Like advertising -> UUID: 0xFE95 2) send advertising every minute The advertising is cached by NRF24L01, in the console you receive the following message: 15:01:36 MINRF: new LYWSD03 at slot: 0 The payload is not decoded (it is not encrypted I think): 15:03:56 RSL: tele/tasmota_489752/SENSOR = {"Time":"2020-09-18T15:03:56","LYWSD03-8c6a32":{}} performing an NRFScan the device is not discovered

configured with the following configurations: 1) send Custom advertising -> UUID: 0x181A 2) send advertising every minute The advertising is not cached by NRF24L01, performing an NRFScan the device is not discovered

Flashed with Original FW everything works as expected, advertising is cached by NRF24L01 and the payload is decrypted performing an NRFScan the device is discovered

I hope that these test can help you understanding the driver behavior.

I have an additional question, is there any possibility to send an MQTT tele topic only when a new advertising message is received?

Thank you for your time!

[Staars]

Thanks, for reporting. I will try to implement all 3 options, knowing that:

1. Original FW with encryption already works On my machine
2. Custom FW in Mijia mode should work, according to your finding
3. ATC „mode“ will probably never work for unknown reasons, but I will add some code, which could work in theory. Maybe the riddle gets solved later.

That would be 2 of 3, which is better than 0 of 3.

[Staars]

Little change in the plan: I just got the ATC packet and it is already working!

In order to save code space, I will not include the Mijia-mode of the custom FW, because there is no additional benefit.

[ercoleg]

I Agree, please let me know when you have a pre-release to test, I will be glad to support.

[Staars]

Look here: https://github.com/arendst/Tasmota/pull/9339

[jonslilbro]

I Agree, please let me know when you have a pre-release to test, I will be glad to support.

I think I might be having the same issue you were. Trying to get my ATC sensors reporting in Tasmota, the devices show up on the main page with only Mac addresses and RSSI and according to console the actual values are null. Version 9.2.0 of ESP32. What did you do to make them work?