MIBLE does not get data from MJ_HT_V1

[markusb68]

PROBLEM DESCRIPTION

MIBLE does not get data from MJ_HT_V1

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• [x ] Read the Contributing Guide and Policy and the Code of Conduct
• [x ] Searched the problem in issues
• [ x] Searched the problem in the docs
• [x ] Searched the problem in the forum
• [ x] Searched the problem in the chat
• [x ] Device used (e.g., Sonoff Basic):nodemcu
• [ x] Tasmota binary firmware version number used: _____
  • Pre-compiled
  • [x ] Self-compiled
    • [ x] IDE / Compiler used: 1.8.11
• [ x] Flashing tools used: esptool2.8
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:
D2 GPIO4 spi dc
D1 GPIO5 spics

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:

• Provide the output of the Console log output when you experience your issue; if applicable:
  (Please use weblog 4 for more debug information)

  Console output here:

TO REPRODUCE

See bleow

EXPECTED BEHAVIOUR

No sensor data at all

SCREENSHOTS

ADDITIONAL CONTEXT

dicdussed it with christian - he asked me to open the issue

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

Hello Christian,

here are the results for step one you requested:
1)
Change line 836 to:
MIBLEinitBLE(0);
and line 619 to:
MIBLEinitBLE(0);

Step1.txt

[markusb68]

And here is Step 2:

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

Step2.txt

Step3: No, not with this hardware. Do you have an example - known working?
But I got date from THIS MJ_HT_V1 with a ESP32 (internal BLE)

[Staars]

Okay, you receive something (obviously) but I see no traces of MIJIA-packets.
I created a minimal working example based on an original example (unrelated to TASMOTA):
https://gist.github.com/Staars/224653f8b887644e5bb0ce61d7dbcf56

This should at least rule out hardware problems.

[markusb68]

Your minimal working example dis not compile with the RF24 out of the tasmota LIB folder.
Got the recent master from github and it compiled.
But now tasmota dos not compile any more:
xdrv_33_nrf24l01:59:6: error: no matching function for call to 'RF24::RF24()' RF24 NRF24radio;
Here is the minimal working examples output:
Step3.txt

[Staars]

Yes, that was the meaning of

(unrelated to TASMOTA):

But it is working and the hardware setup seems to be intact. To be honest, I have no good idea ATM, because I never have seen this problem. The "packetmode 0" is the old method from the example above and should give the same output. I left it for debugging purposes.
The only difference is:
NRF24radio.setPALevel(RF24_PA_MIN); in TASMOTA
NRF24radio.setPALevel(RF24_PA_MAX); in the base example
Maybe you can try this.

Another thing to try is to:

      case FUNC_EVERY_100_MSECOND:
        MIBLE_EVERY_100_MSECOND();

change to

      case FUNC_EVERY_50_MSECOND:
        MIBLE_EVERY_100_MSECOND();

(to reduce packet losses)

And always be sure, that the sensor has no active BT-connection to master device.

[markusb68]

Sorry, this also does not help to solve it.
Still no data.
The sensor was never connected to a xiaomi bridge or master device. Only to the MI Home app on my mobile. But the mobiles bluetooth is OFF.

I never see it switching to mode 0. Only 1, 2 and 3:
11:51:15 MIBLE: Change packet mode after 60 seconds, MIBLE.timer: 601 11:51:15 MIBLE chip connected 11:51:15 MIBLE: Change Mode to 1 11:51:46 MIBLE: Change packet mode after 60 seconds, MIBLE.timer: 601 11:51:46 MIBLE chip connected 11:51:46 MIBLE: Change Mode to 2 11:52:17 MIBLE: Change packet mode after 60 seconds, MIBLE.timer: 601 11:52:17 MIBLE chip connected 11:52:17 MIBLE: Change Mode to 3

[ascillato2]

Hi, any news on this?

[Staars]

I took a look at your output from post 1 and there we see all MJ_HT_V1-packets as expected. Also the result of the next logs makes sense too.
It seems to me, that in your setup, the NRF24L01 does not capture the packets with the „special“ PDU-type and I have no idea why.

Just to be sure, can you send me your compiled binary (with no code changes) to rule out a problem on this side.
In the meantime I got another NRF-module with a big antenna, which I will test.

[markusb68]

Here is the binary.
these are the code changes in my user config:
#define USE_SPI
#define USE_NRF24
#define DEBUG_TASMOTA_SENSOR

tasmota.ino.generic.zip

[Staars]

Thanks, I will look into it (even if I do not really have doubts about your compilation).

But besides I am in the middle of re-working the driver and maybe I can improve it.

In the worst case I could re-implement the "old" reading method of the whole BLE-packet, because your "Step1.txt" showed that these packets are succesfully captured on your setup. This would only work with the MJ_HT_V1, because the packets of this sensor are short enough.

Stay tuned ...

[Staars]

You may want to try a new version with some improvements (I hope):
https://gist.github.com/Staars/16c8c45edfee4a4f97787dd753474786

Just replace the file in the tasmota folder.

[markusb68]

Wow, now it works! Many thanks.
Markus

[Staars]

That are good news!
I still can not explain, why I had no problems in the past, but the new thing is, that I added PDU-types for every possible channel (37-39) and not only for one. Maybe an "unholy" synchronization between the channel and an undefined PDU-type has happened in your setup all the time.

I will cleanup the code and maybe do a little bit of refactoring in the next few days and I still believe, that the NRF24L01-BLE-hack has some advantages, like complete passive scanning:
https://support.digitalmatter.com/support/solutions/articles/16000100684-active-vs-passive-bluetooth-scanning

It is planned to add the features to the HM-10-driver too, but this will produce more data traffic, which I personally will not use in real-life.

[Staars]

#7736

I hope, I did not introduce new bugs in the last refactoring session.

[markusb68]

Hello Christian,

just compiled it with the today's sourced: Still works here .
Thanks

Markus

[Staars]

Very nice.
You can close this issue now.

[vMeph]

@Staars cant find the bin, could you share the file
and if you could share the connections to use with nRF24L01+PA+LNA with the ESP
thanks

[Staars]

What does PA and LNA stand for?

[vMeph]

is the model with antena
PA stands for Power Amplifier
LNA stands for Low-Noise Amplifier

[vMeph]

so i have SPI_DC conected to MOSI and SPI_CS to MISO
the SCK (Serial Clock) not sure what entry and GPIO to use in tasmota config any toughs?
in console so far no luck

19:30:57 CMD: Group 0, Index 1, Command "NRFSCAN", Data "0"
19:30:57 RSL: stat/tasmota_19A63D/RESULT = {"Command":"Unknown"}