The collector incorrectly tries to parse certain BLE packets that are similar to those sent by ruuvi about ruuvicollector

[Scrin]

Alright so technically the collector works, but throws annoying warnings as it erroneously detects non-ruuvi packets as such, I will improve the detection logic based on this to get rid of the warnings, hopefully I find time for this already this weekend, latest next weekend (as that's when my vacation starts).

You can see the source MAC address from the bytes at offset 7-12 backwards, for example:

> 04 3E 2A 02 01 03 01 BC 7C 37 C4 4A F7 1E 02 01 06 1A FF 4C

is a packet originating from a device with MAC address of F7:4A:C4:37:7C:BC (the bytes are in reverse order). The 7 bytes before the MAC address is what the current logic uses to "detect" the data from ruuvi, which are in order:

• Packet type (04 = event)
• Event code (3E = LE Meta)
• Packet length
• Sub event (02 = LE Advertising Report)
• Number of Reports
• Event Type (03 = Non-Connectable undirected advertising)
• Peer Address Type (01 = Random Device Address)

[enbochen]

Is this related to data format?

[Scrin]

Thanks for reporting this, I haven't seen this before. It is possible that this is related to the data format, or that some other nearby Bluetooth LE device is broadcasting data that is really similar to the ruuvi data and then it's erroneously getting parsed as such.

The error happens when it attempts to read the sixth byte of the measurement, which is the other half of the pressure reading on all current data formats (2, 3 and 4) so likely the data is getting truncated for some reason if it's originating from a ruuvitag.

Can you send a sample of the BLE traffic you are getting so that I can investigate what causes this? You can do this by running the ruuvicollector (and see the errors coming), and at the same time in another terminal on the same machine, run hcidump --raw >> ble_dump.txt let it run for a little time (5-10 seconds should be plenty enough with the default ruuvi broadcast interval) and stop it with ctrl + C and send the ble_dump.txt

[enbochen]

Thanks for the quick reply!

Here is the ble_dump.txt:

HCI sniffer - Bluetooth packet analyzer ver 5.41
device: hci0 snap_len: 1500 filter: 0xffffffff

BLE dump:(deleted for not messing around)

[enbochen]

There is another noticeable thing: LED of RuuviTag doesn't blink as once a second as RAW mode. So I'm not sure if it's the problem of switching between modes.

[Scrin]

Thanks for the BLE dump. It seems that there are multiple devices that are broadcasting with the exact same packet type, event code, packet length, number of reports and event type, which is what the current logic uses to "detect" packets from Ruuvitags, this explains the error you are getting.

However I am not able to detect any other recognizable packets from ruuvitags.. which firmware are you using? and have you found out the MAC address of your ruuvitag(s)? for example with nRF Connect mobile application.

[enbochen]

I'm using the original firmware (protocolVersion = 2) and I find their MAC address of ruuvitags. Actually, I got the formatted data in my influxDB. I just do not know where is the source of those exact same packet type, which makes Java throw those uncaught exceptions.

[Scrin]

The immediate warnings (based on the provided BLE dump) should be gone now. Additionally I added support for blacklisting or whitelisting tags based on their MAC address in case something still causes issues, check the ruuvi-collector.properties.example for more information in case you need it