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 https://github.com/domints/ESP-Ruuvi-Collector/issues/3#issuecomment-480545015, 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 https://github.com/domints/ESP-Ruuvi-Collector/issues/3#issuecomment-483565914, 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 https://github.com/domints/ESP-Ruuvi-Collector/issues/3#issuecomment-484280391, or mute the thread https://github.com/notifications/unsubscribe-auth/AAILTYP4PAEAYH3MLZVQFCLPQ6N75ANCNFSM4HD76SWQ .

[salleq]

I'm a bit confused, so sorry in advance.

I have a couple of weeks old Ruuvi Tags, which I assume are by default transmitting V3 (RAWv1) data, which should include acceleration data as well. In the code there's though only acceleration data for V5.

Anyway, I'm getting weird readings some of the time - here's two examples of the same tag (I'm using Serial.printf("Advertised Device: %s \n", advertisedDevice.toString().c_str()); from above to see the mac address: ruuvi,device=esp_test temperature=58.320,pressure=61296,humidity=50,milivolts=29498 ruuvi,device=esp_test temperature=25.350,pressure=100325,humidity=44,milivolts=3115

The latter row is the "correct" reading while the first one is incorrect. It's not the tag itself sending wrong information since it never shows those readings on the Ruuvi Station app. I'm wondering, if it somehow combines the readings of multiple tags (I have three) into one output?

[Quas7]

I fiddelt around with my ruuvis lately and made this collector ID aware to process multiple ruuvis and not pushing all in one DB together.

While doing this I noticed, that the issue from salleq is most likely just a change of the pointer content by a second update. I have around 40 BT devices around my place and the pointer content gets updated quite often even while doing only a simple if-else compare on the esp32 in between.

I therefore copy the pointer with its content to a second pointer for further processing first. Another way would be disabling the BT updates after finding a valid ruuvi manufacturer ID and enabling it afterwards - maybe this is a bit better.

I will upload my code after commenting it a bit more. edit: I uploaded to my forked repo

Also note, that this kind of data transmission from ruuvi tags has no integrity checking at all by design afaik.