BM2 fails to decode

[mhaberler]

BM2 decoder fails to decode this "BM2 Monitor": https://www.amazon.de/dp/B09MJ4PL72 using OMG heltec-ble with decoder @5f7dca59d5cfe14d4b45f7f44d5797f455e8638d

log from OMG:

N: Device detected: 50:54:7B:22:2F:20 N: Send on /BTtoMQTT/50547B222F20 msg {"id":"50:54:7B:22:2F:20","mac_type":0,"adv_type":0,"name":"Battery Monitor","manufacturerdata":"e18911ed76d18e5ba793d5574f205b61","rssi":-53,"txpower":0}

nrfConnect says this:

and this:

@DigiH where did you take the decoding instructions from?

thanks, Michael

[DigiH]

Hi @mhaberler,

The decoding for the VM2 is taken from its iBeacon broadcast for the percentage - in your case it should be 93%, is that correct? And once recognised as such a BM2 battery monitor the actual voltage OMG gets from directly connecting to the device and reading the service/characteristic.

Unless I messed something up with the commit before you should get decoded values from the iBeacon broadcasts. Or do you see undecoded iBeacon broadcasts by any chance, in addition to the non-iBeacon broadcast you listed in your issue?

What is your intervalacts set to? With the BM2 requiring active scanning to get the decodable iBeacon broadcast.

[mhaberler]

yes, 93% sounds about right

no undecoded iBeacon broadcasts AFAICT

I think the issue is active scanning which I might have turned off in OMG due to battery drain

this is my OMG snapshot: https://github.com/mhaberler/OpenMQTTGateway/tree/v1.6.0-mah

[DigiH]

Well, the

; '-DTimeBtwActive=72000000' # active scan every 20hrs # was 55555

looks commented out, so should take the default 55 seconds from config_BT.h

Otherwise with 72000000 you should see the decoded message from your BM2 only every 20 hours ;)

due to battery drain

Active scanning does not take that much a toll on the battery as a connection does, which is being used for getting the voltage value, so TimeBtwConnect is more important in regards to the battery.

Maybe setting both values to the default connection every hour will be good idea for you, unless you have other devices with decoders which require active scanning more frequently.

You might also want to look into creating your own portable config file, instead of always having to amend the default environments in environments.ini

https://docs.openmqttgateway.com/upload/builds.html#option-a-creating-a-portable-config-file

A portable config files can be easily carried over to every new OpenMQTTGateway development and release version.

[mhaberler]

a few builds later I suddenly do get the values. Frankly, I do not understand what caused this; maybe some stale build artefacts.

{"id":"50:54:7B:22:2F:20","mac_type":0,"adv_type":0,"name":"Battery Monitor","manufacturerdata":"4c000215655f83caae16a10a702e31f30d58dd82f5c100005c","rssi":-84,"txpower":0,"brand":"GENERIC","model":"BM2 Battery Monitor","model_id":"BM2","type":"BATT","acts":true,"track":true,"batt":92,"device":"BM2 Tracker"}

actually I think there should be a temperature value in the announcement (or is this via service/characteristic only?), and having the raw voltage instead of some made-up percentage would be better; not sure if this is possible.

so issue resolved. Pretty arcane device.

[DigiH]

actually I think there should be a temperature value in the announcement (or is this via service/characteristic only?)

I do not know, I don't have a BM2 device. If you spot the temperature also being included encoded in the iBeacon data let us know and we can include it in the decoder.

and having the raw voltage instead of some made-up percentage would be better

Please re-read my posts above …

And once recognised as such a BM2 battery monitor the actual voltage OMG gets from directly connecting to the device and reading the service/characteristic.

… connection does, which is being used for getting the voltage value, so TimeBtwConnect …

[mhaberler]

I'll see if I can find an example. I have two more different devices I can test with beyond the one mentioned above: https://www.amazon.de/dp/B00ZETXNAQ https://www.amazon.de/dp/B0BLG9Z462

I worked with Beacon-only sensors mostly so far, and not that familiar with service/characteristic reading. Sorry.

[DigiH]

Thanks, would be interesting to see if the other two battery monitors also broadcast some of their information for some possible decoder inclusions.

[DigiH]

Hi @mhaberler,

Were you able to get any data for your other two battery monitors or only undecoded advertising data so that the decoder might need extending for these models?

Thanks

[mhaberler]

cannot get at the OMG serial right now for the first device (BatteryGuard) I get:

{"id":"38:3B:26:B4:6D:27","mac_type":0,"adv_type":0,"name":"Battery Guard","manufacturerdata":"d48464dda32f85451fd20f04a57f5fe5","rssi":-91,"txpower":0}

nrfConnect raw data:

0x0201060302F0FF11FFD48464DDA32F85451FD20F04A57F5FE50E0942617474657279204775617264051206000C00020A00

[mhaberler]

for the second device ("Battery Monitor") I get:

{"id":"38:3B:26:BE:20:F9","mac_type":0,"adv_type":0,"name":"BM6","manufacturerdata":"6382abf671dc54a2a8687f1ce98b7fc0","rssi":-90,"txpower":0}

nrf Connect raw data:

0x0201061AFF4C0002153BA29CD9A42C894856BADAF2606EF77712110000CD0409424D36051206000C00020A00

[DigiH]

Thanks

cannot get at the OMG serial right now

No need for any serial monitoring for this.

Undecoded OMG messages with advertising data switch on, as you have, is all that is required to see if any new devices might contain decodable data.

for the first device (BatteryGuard) I get:

{"id":"38:3B:26:B4:6D:27","mac_type":0,"adv_type":0,"name":"Battery Guard","manufacturerdata":"d48464dda32f85451fd20f04a57f5fe5","rssi":-91,"txpower":0}

for the second device ("Battery Monitor") I get:

{"id":"38:3B:26:BE:20:F9","mac_type":0,"adv_type":0,"name":"BM6","manufacturerdata":"6382abf671dc54a2a8687f1ce98b7fc0","rssi":-90,"txpower":0}

Do these two devices also advertise in the iBeacon format? At least for the second BM6 I can see the iBacon format in the nRFConnect screenshots with the manufacturerdata starting with "4C00…".

I suspect they alternate between these two advertising formats, which you can see in the message history when monitoring the output in MQTT Explorer.

As the iBeacon format was the one reported by other users with BM2 devices it is the one being used to decode the battery percentage.

[mhaberler]

I see I'd have to check for that but it will take two weeks until I get my hand on them again want a .pcap ?

[DigiH]

No .pcap, just the different undecoded messages received and published by OpenMQTTGateway, along with the percentage and voltage values for the devices' app, to see if any useful information is encoded in their advertising data as well.

Thanks

[mhaberler]

new wart:

sensor bat-bm2: {"id":"50:54:7B:22:2F:20","manufacturerdata":"4c000215655f83caae16a10a702e31f30d58dd82f5b100005b","rssi":-34,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"4c00","uuid":"655f83caae16a10a702e31f30d58dd82","major":-2639,"minor":0,"volt":9.1}

I measured the battery at 12.82V

9.1V is a bit beyond my tolerance limit for chinese devices ;)

[1technophile]

Don't take this value into account for iBeacon advertisements. Unfortunately, we have iBeacons advertising voltages like that, but the BM2 is also doing it with the wrong value. The tip is to ignore the BM2 messages with the model_id IBEACON A proper message following a connection should be published regularly with OpenMQTTGateway

[DigiH]

And I suppose we'd need to add the additional name variants for your other battery monitor devices to be recognised and decoded correctly.

In the above example the name "BatteryGuard", so that the battery percentage will be 91%, and only then with the correct device recognition can OMG connect to the device to get the actual voltage.

Adding "BatteryGuard" now, and with your second (third) device broadcasting the name BM6, this also needs to be added.

Could you just confirmation that the BM6 also dos advertise with the iBeacon protocol, or only ever with the above shown non-iBeacon manufacturerdata?

{"id":"38:3B:26:BE:20:F9","mac_type":0,"adv_type":0,"name":"BM6","manufacturerdata":"6382abf671dc54a2a8687f1ce98b7fc0","rssi":-90,"txpower":0}

[DigiH]

Just looking at the several iBacon data sets we have collected by now from different users and with different advertising names, it slowly becomes clear that these battery monitors seem to have identical iBeacon data parts.

4c00 0215655f83caae16a10a702e31f30d58dd82 f644000064
4c00 0215655f83caae16a10a702e31f30d58dd82 f441423144
4c00 0215655f83caae16a10a702e31f30d58dd82 f441423157
4c00 0215655f83caae16a10a702e31f30d58dd82 f441423149
4c00 0215655f83caae16a10a702e31f30d58dd82 f5c100005c
4c00 0215655f83caae16a10a702e31f30d58dd82 f5b100005b
4c00 0215655f83caae16a10a702e31f30d58dd82 f641514164

         655f83caae16a10a702e31f30d58dd82 - iBeacon uuid

so likely best - and pretty safe by now with all the different collected data - to change the Battery Monitor model condition to this.

This would also allow the Battery Monitor decoder to work with passive scanning only, which should also avoid iBeacon recognition, decoding and publishing as seen above.

Available for testing and verification with branch

https://github.com/DigiH/decoder/tree/BM-new

[mhaberler]

yes, the BM6 alternates between iBeacon and another format

app says:

ibeacon ad:

I think this is the non-iBeacon ad:

Name: BM6 Address: 38:3B:26:BE:20:F9 RSSI: -80 dBm Last advertisement packet: Raw data: 0x0201060302F0FF11FF8F9C3ACC86DA6960C38AA55B32E643B90409424D36051206000C00020A00

OMG serial says:

N: Send on /BTtoMQTT/383B26BE20F9 msg {"id":"38:3B:26:BE:20:F9","mac_type":0,"adv_type":0,"name":"BM6","manufacturerdata":"4c0002153ba29cd9a42c894856badaf2606ef777120b0000cd","rssi":-73,"txpower":-51,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"4c00","uuid":"3ba29cd9a42c894856badaf2606ef777","major":4619,"minor":0}

[mhaberler]

inTact Battery Guard:

non-iBeacon ad:

the two different ads by Battery Guard:

Name: Battery Guard Address: 38:3B:26:B4:6D:27 RSSI: -67 dBm Last advertisement packet: Raw data: 0x0201060302F0FF11FF98391E4A15E56D597B0A56F45E6FF5AB0E0942617474657279204775617264051206000C00020A00

Name: Battery Guard Address: 38:3B:26:B4:6D:27 RSSI: -69 dBm Last advertisement packet: Raw data: 0x0201061AFF4C0002153BA29CD9A42C894856BADAF2606EF77711430000CD0E0942617474657279204775617264051206000C00020A00

[DigiH]

Thanks for some more info @mhaberler.

It looks clear now that the BM6 and Battery Guard do not fit into the newly found Battery Monitor iBeacon format model condition, which is good, as their last octet "cd" does not indicate their battery level percentage - at least with a quick look for any possible shifting or masking possibilities.

All other name variants, including your BM2 should all be fine with the new model condition.

The BM6 and Battery Guard won't be decodable with the existing Battery Monitor decoder for the percentage and the subsequent voltage connection retrieval, but their non-iBeacon data might contain more information. Their iBeacon data does also have the same uuid section though, so they're likely similar variants of a different battery monitor hardware.

…
4c00 0215655f83caae16a10a702e31f30d58dd82 f5b100005b
4c00 0215655f83caae16a10a702e31f30d58dd82 f641514164

         655f83caae16a10a702e31f30d58dd82 - iBeacon uuid

Battery Guard
4c00 02153ba29cd9a42c894856badaf2606ef777 11430000cd
BM6
4c00 02153ba29cd9a42c894856badaf2606ef777 120b0000cd

For that though I would like to ask you to provide undecoded, but with advertising and advanced data turned ON, data from OpenMQTTGateway if you're interested in further investigating the BM6 and Battery Guard together to also create a decoder for these.

This would be more helpful than the above Raw Data postings and nRFConnect screenshots. Also there might have been a small mixup with the app screenshots, as both seem to show and have the same 383B26B46D27 MAC address for the Battery Guard, but no BM6 screenshot.

As for the second Battery Guard Raw Data I would have also expected it to be recognised as an iBeacon currently, so OMG undecoded advertising data will make it clearer what the issue is and how to go forward with possible decoders.

Raw data: 0x0201061AFF4C0002153BA29CD9A42C894856BADAF2606EF77711430000CD0E0942617474657279204775617264051206000C00020A00

[mhaberler]

will do

[mhaberler]

ok, so the OMG config is

N: Send on /BTtoMQTT msg {"bleconnect":true,"interval":55555,"adaptivescan":true,"intervalacts":55555,"intervalcnct":3600000,"scanduration":10000,"onlysensors":false,"randommacs":false,"hasspresence":false,"presenceTopic":"presence/","presenceUseBeaconUuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":true,"pubBeaconUuidForTopic":false,"ignoreWBlist":false,"presenceawaytimer":120000,"movingtimer":60000,"btqblck":4,"btqsum":71,"btqsnd":58,"btqavg":1.224138,"bletaskstack":1424,"blecoretaskstack":3112,"blestarts":1}

i.e pubadvdata == true

for the Battery Guard (383B26B46D27) I get:

N: Send on /BTtoMQTT/383B26B46D27 msg {"id":"38:3B:26:B4:6D:27","mac_type":0,"adv_type":0,"name":"Battery Guard","manufacturerdata":"4c0002153ba29cd9a42c894856badaf2606ef777123e0000cd","rssi":-71,"txpower":-51,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"4c00","uuid":"3ba29cd9a42c894856badaf2606ef777","major":4670,"minor":0}

N: Send on /BTtoMQTT/383B26B46D27 msg {"id":"38:3B:26:B4:6D:27","mac_type":0,"adv_type":0,"name":"Battery Guard","manufacturerdata":"b6ecd6127f6c86fa73c2943fdc5fdc26","rssi":-70,"txpower":0}

for the BM6 (383B26BE20F9) I get:

N: Send on /BTtoMQTT/383B26BE20F9 msg {"id":"38:3B:26:BE:20:F9","mac_type":0,"adv_type":0,"name":"BM6","manufacturerdata":"8f9c3acc86da6960c38aa55b32e643b9","rssi":-81,"txpower":0}

N: Send on /BTtoMQTT/383B26BE20F9 msg {"id":"38:3B:26:BE:20:F9","mac_type":0,"adv_type":0,"name":"BM6","manufacturerdata":"4c0002153ba29cd9a42c894856badaf2606ef777120b0000cd","rssi":-75,"txpower":-51,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"4c00","uuid":"3ba29cd9a42c894856badaf2606ef777","major":4619,"minor":0}

for the BM2 (50547B222F20) I get:

N: Send on /BTtoMQTT/50547B222F20 msg {"id":"50:54:7B:22:2F:20","mac_type":0,"adv_type":0,"name":"Battery Monitor","manufacturerdata":"4ddc321bd4a76b7ff85c9f4de57e2d83","rssi":-74,"txpower":0}

N: Send on /BTtoMQTT/50547B222F20 msg {"id":"50:54:7B:22:2F:20","mac_type":0,"adv_type":0,"name":"Battery Monitor","manufacturerdata":"4c000215655f83caae16a10a702e31f30d58dd82f581000058","rssi":-82,"txpower":0,"brand":"GENERIC","model":"BM2 Battery Monitor","model_id":"BM2","type":"BATT","acts":true,"track":true,"batt":88,"device":"BM2 Tracker"}

hope this is what you need/wanted

[mhaberler]

can confirm the development branch now reports battery status via BM2 with same value as the app (88% in my case)

[DigiH]

Great, thanks @mhaberler, this gives a nice overview and confirms my above findings, that the BM2 Battery Monitor has identical iBeacon data/uuid parts, even if it come along with broadcasting under many different names, like "Battery Monitor", "BM2", "ZX-1689", "Li Battery Monitor" - those just being the ones we have encountered so far.

So unifying the decoder to recognise the model by the identical data part will recognise them all, regardless of their name, as you confirmed for your BM2 88%. You should also get the actual voltage now with every "intervalcnct", currently 3600000 (ms) in your BTtoMQTT settings, or however more or less frequent you want to set it to.

The BM6 and Battery Guard however definitely do not fit into the BM2 decoder scheme. They have a different uuid part of their iBeacon advertising, but again identical for both, and the last octet, which gives the BM2 battery percentage, never changes.

If and how they might still freely broadcast some information in their advertising data would now require the same two manufacturerdata only and iBeacon protocol samples as you gave for them above, but now with app screenshots at the same time, to see which encoded data might warrant a separate decoder for the BM6/Battery Guard battery monitors. Or it could be that their values can only be retrieved by connecting and reading the relevant service/characteristic, which would also be possible through the OpenMQTTGateway READ command.

[DigiH]

@mhaberler

Closing this, as your BM2 is being correctly recognised and de coded now, from your above statement.

If you are still interested in looking at the BM6/Battery Guard together to see if any useful data might be encoded in their advertising data for a possible decoder, please open a separate discussion or issue.

[DigiH]

Hi @mhaberler

I have a test branch for the battery level decoder of the BM6.

If you want you can try it at

https://github.com/DigiH/decoder/tree/bm6

[mhaberler]

will do, but might take a bit

[JeffWDH]

The BM6 uses a slightly different encryption key than the BM2. Details (and the key) can be found here: https://www.tarball.ca/posts/reverse-engineering-the-bm6-ble-battery-monitor/

[mhaberler]

@DigiH sorry I guess I dropped the ball on the BM6 branch

here's what is currently reported by OMG:

{"id":"38:3B:26:BE:20:F9","name":"BM6","rssi":-95,"txpower":0}