OnResult with incorrect Data

[PAk-CatchFire]

Hello.
I am trying to read a RuuviTag with your program but I get the folllowing info from BLE, where I mostly read the Data[0] field as 85 and not 99 as expected:

[D][main.cpp:183] setup(): This shows
[D][BLEScan.cpp:204] start(): >> start(duration=1)
[D][FreeRTOS.cpp:165] take(): Semaphore taking: name: ScanEnd (0x3ffdfda0), owner: <N/A> for start
[D][FreeRTOS.cpp:174] take(): Semaphore taken:  name: ScanEnd (0x3ffdfda0), owner: start
[D][BLEScan.cpp:236] start(): << start()
[D][BLEAdvertisedDevice.cpp:424] setRSSI(): - setRSSI(): rssi: -61
[D][BLEAdvertisedDevice.cpp:253] parseAdvertisement(): Type: 0x01 (), length: 1, data: 06
[D][BLEAdvertisedDevice.cpp:253] parseAdvertisement(): Type: 0x03 (), length: 2, data: aafe
[D][BLEAdvertisedDevice.cpp:453] setServiceUUID(): - addServiceUUID(): serviceUUID: 0000feaa-0000-1000-8000-00805f9b34fb
[D][BLEAdvertisedDevice.cpp:253] parseAdvertisement(): Type: 0x16 (), length: 22, data: aafe10f9037275752e76692f2342484155414d4b492d
BLEAdvertisedDeviceCallbacks:
Advertised Device: Name: , Address: df:4c:f2:f3:25:8d, serviceUUID: 0000feaa-0000-1000-8000-00805f9b34fb 
Data:
85
0
0
[D][BLEScan.cpp:106] handleGAPEvent(): Ignoring df:4c:f2:f3:25:8d, already seen it.
[W][BLEScan.cpp:78] handleGAPEvent(): ESP_GAP_SEARCH_INQ_CMPL_EVT
Dumping: 
[D][BLEScan.cpp:287] dump(): >> Dump scan results:
[D][BLEScan.cpp:289] dump(): - Name: , Address: df:4c:f2:f3:25:8d, serviceUUID: 0000feaa-0000-1000-8000-00805f9b34fb
 BLE devices: 1
Scan done!

Is there anything I can do?
Thank you

[domints]

To be honest, I am pretty sure that if the first byte is 0x85 and not 99 the message didn't came from the Ruuvi Tag (or you do have different firmware loaded onto it).
I just merged pull request from one guy with support for V3 protocol and some stability fixes, but both V3 and V5 protocols start with 0x99 0x04 to indicate Ruuvi packet.

Do you see your tag in Ruuvi Station app?
https://lab.ruuvi.com/ruuvi-station/

[PAk-CatchFire]

Thank you for your answer @domints .

Actually I am pretty sure that what i am receiving is the Ruuvi tag itself. I am attaching you an image with the offical ruuvi app, and it is the same Mac address that I am reading with your code....but I do receive the 85 (0x55) in the data[0] field. (Sorry about not giving you the HEX display before).

[domints]

What's the app you're using? Also, what's the firmware you're using?

Also, by the documentation, two first bytes for Ruuvi firmware must be 0x99 0x04. Different bytes mean different manufacturer. Is your tag legit? Maybe it's some chinese counterfeit?

Or, the third solution. I am not sure how the frame would look for Eddystone URL packet, but your tag might be in URL mode. Please press 'B' button and look if it works now.
https://lab.ruuvi.com/ruuvitag-fw/

[PAk-CatchFire]

It's the official Ruuvi Station app.

I bought them from Ruuvi directly!!

When I click on B data changes, however I have noticed that depending on the printf I use on the onResult function I see different data. I am using this for debug purposes.

class AdvertisedDeviceCallbacks : public BLEAdvertisedDeviceCallbacks
{
  void onResult(BLEAdvertisedDevice advertisedDevice)
  {
    byte *mData = (byte *)advertisedDevice.getManufacturerData().data();
    if (mData[0] = 0x99 && mData[1] == 0x04)
    {
      if (mData[2] == 0x05)
        DecodeV5(mData);
    }
    else
    {

      Serial.println("BLEAdvertisedDeviceCallbacks:");
      Serial.printf("Advertised Device: %s \n", advertisedDevice.toString().c_str());

      Serial.println("");
      Serial.println("Data:"); /**/
      Serial.println(mData[0]);
      Serial.println(mData[1]);
      Serial.println(mData[2]);
    }
  }
};

[PAk-CatchFire]

Ok, I changed my onResult creating a global variable for printing it on the loop cicle, and I read now
0x99 0x04 0x03....so V3 is here!!
When will you add support for it?
Regards

advertisedDevice_global=advertisedDevice;

  byte *mData = (byte *)advertisedDevice.getManufacturerData().data();
  ok_rx_ble=1;

  if (mData[0] = 0x99 && mData[1] == 0x04)
  {
    if (mData[2] == 0x05)
      DecodeV5(mData);
  }

[domints]

I just accepted PR to my code and fixed it, so when you get latest version you should have V3 available. I can’t however test it because I don’t have v3 Ruuvi tag handy, but looks ok, s I believe PR author tested it. W dniu niedz., 7.04.2019 o 01:18 Pak <notifications@github.com> napisał(a):

…

Ok, I changed my onResult creating a global variable for printing it on the loop cicle, and I read now 0x99 0x04 0x03....so V3 is here!! When will you add support for it? Regards advertisedDevice_global=advertisedDevice; byte *mData = (byte *)advertisedDevice.getManufacturerData().data(); ok_rx_ble=1; if (mData[0] = 0x99 && mData[1] == 0x04) { if (mData[2] == 0x05) DecodeV5(mData); } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABC54ea_-MzXRynwJLIrOLLv0xnsfk7Xks5veStTgaJpZM4cf_St> .

[PAk-CatchFire]

Thank you @domints
How could I change Ruuvi to v5? Is it a firmware update?

[PAk-CatchFire]

I found an error in V3 decoding....my phone says 22.88 and ruuvicollector says 20.88, also 23.18 to 21.18.

It seems to be a wrong range.

Sometimes the phone and the ESP32 match....many other times there is that 2 degree constant difference

[domints]

Ok, I fixed the temperature readings. I am not sure why author of the PR subtracted 2 from the temp value and I didn't dig deep into the code earlier. I checked it now and it looks like all of the values are coded exactly like the Ruuvi docs say.
Please pull the changes and confirm.

Thank you very much for your help :)

[domints]

And in the matter of updating to v5 protocol, please read this article: https://lab.ruuvi.com/dfu/

[PAk-CatchFire]

Thank you.
I had already updated it yesterday...V5 working as a champ!!
Thank you for all the support

[Quas7]

Sorry for the -2°C temperature offset in the code.
My early Kickstarter RuuviTag is not very precise regarding temperature and I just corrected the offset around room temperature for this device.

[domints]

No problem ;) arę you sure it’s the RuuviTag that’s imprecise? I’m not sure what temp measuring device it’s using, but if it’s the same Bosch’s sensor, I doubt you’d find any more precise device in an ordinary household :) W dniu wt., 16.04.2019 o 10:36 Till <notifications@github.com> napisał(a):

…

Sorry for the -2°C temperature offset in the code. My early Kickstarter RuuviTag is not very precise regarding temperature and I just corrected the offset around room temperature for this device. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABC54YR6H3XxOfTUxCnJQXSkLMiSFyu9ks5vhYuAgaJpZM4cf_St> .

[Quas7]

Hehe, yes - it is a special case.
Unfortunately, I am quite sure that this is the tag itself (at least compared to a PT100 class A).

I have four RuuviTags flying around but the "bad" one is from the kickstarter campaign (rev. B4) and it does not feature all sensors (see this thread).

Therefore, this tag only has +/-5°C accuracy from nRF52 on-chip temperature sensor like discussed here.

But, not a big issue for monitoring my freezer for now. ;)

If I find time, I will check how to make use of UID to get all four sensors pushed to my influxdb.

[domints]

Ok, that makes sense :D I didn’t know about the kickstarter tags :) W dniu czw., 18.04.2019 o 00:11 Till <notifications@github.com> napisał(a):

…

Hehe, yes - it is a special case. Unfortunately, I am quite sure that this is the tag itself (at least compared to a PT100 class A). I have four RuuviTags flying around but the "bad" one is from the kickstarter campaign (rev. B4) and it does not feature all sensors (see this thread <https://f.ruuvi.com/t/different-temperatures/212/8>). Therefore, this tag only has +/-5°C accuracy from nRF52 on-chip temperature sensor like discussed here <https://f.ruuvi.com/t/whats-causing-incorrect-temp-measurements/1222>. But, not a big issue for monitoring my freezer for now. ;) If I find time, I will check how to make use of UID to get all four sensors pushed to my influxdb. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAILTYP4PAEAYH3MLZVQFCLPQ6N75ANCNFSM4HD76SWQ> .