Hi,
I wrote my own BLE scale to MQTT gateway on an ESP32 for the scale I use. It sends the data inside the advertised manufacturer data. Is there anyway to have this data sent in MQTT in hex rather than binary? Or do I have to learn the code and modify it and upload it myself?
Thanks
Hi,
You may convert it, but I don’t get your context. Are you using OpenMQTTGateway or a custom program?
I wanted to replace my custom program because I have stability problems sharing the radio between ble and wifi. But I noticed from other forums, that OpenMqttGateway may have those same problems.
And from your answer it appears that there is no binary that does hex for the manufacturer, but rather I need to look thru the code where this is output and turn it to hex myself, right?
It’s resolved now.
I find it strange to have the sensor data into the manufacturer data, do you have some scan to share of the advertised data, or maybe share your piece of code?
…and after re-reading my original post, I want to make clear. The weight scale sends the readings within the manufacturer data. So I need to be able to read this out of MQTT, which doesn’t work when it’s in binary as it seems to get cut off as a zero terminated strings or perhaps something like that. I see it nicely in hex in the serial terminal of openmqttgateway’s firmware.
actually, I guess I don’t see the hex nicely in the serial console in the openmqttgateway firmware, but rather in the code that is in the BLE examples folder. And I guess that code has nothing to do with openmqttgateway, but I’m not sure. In any case, I didn’t see any of the code in the example folder that passed it thru to the wifi.
May you post the example used and an extract of the hex code you are seeing nicely ?
Output from
…/OpenMqttGateway/ble/esp32dev-ble/ESP32_BLE_Arduino/examples/BLE_scan/BLE_scan.ino …
Advertised Device: Name: , Address: 39:95:09:d1:a8:a2, manufacturer data: 0600010f2002c2fa7d1fd778663ed44963f358f6dd7841a10512b46bdd
Advertised Device: Name: , Address: 5f:dc:3d:d1:d0:4b, manufacturer data: 4c001005531c649ac6, txPower: 12
Advertised Device: Name: , Address: 12:9d:15:06:83:b5, manufacturer data: 0600010920025e52415f1d01f98e38efeb16e3bcfcccf137f5e8354fbd
Advertised Device: Name: QN-S3, Address: ed:67:37:5e:9c:e3, manufacturer data: ffffed67375e9ce39400000000014c3e02d006
Devices found: 4
Scan done!
Advertised Device: Name: , Address: 39:95:09:d1:a8:a2, manufacturer data: 0600010f2002c2fa7d1fd778663ed44963f358f6dd7841a10512b46bdd
Advertised Device: Name: QN-S3, Address: ed:67:37:5e:9c:e3, manufacturer data: ffffed67375e9ce3948c050000014c3e02d606
Advertised Device: Name: , Address: 5f:dc:3d:d1:d0:4b, manufacturer data: 4c001005531c649ac6, txPower: 12
Devices found: 3
Scan done!
Advertised Device: Name: , Address: 39:95:09:d1:a8:a2, manufacturer data: 0600010f2002c2fa7d1fd778663ed44963f358f6dd7841a10512b46bdd
Advertised Device: Name: , Address: 5f:dc:3d:d1:d0:4b, manufacturer data: 4c001005531c649ac6, txPower: 12
Devices found: 2
Scan done!
Advertised Device: Name: , Address: 39:95:09:d1:a8:a2, manufacturer data: 0600010f2002c2fa7d1fd778663ed44963f358f6dd7841a10512b46bdd
Advertised Device: Name: , Address: 5f:dc:3d:d1:d0:4b, manufacturer data: 4c001005531c649ac6, txPower: 12
Devices found: 2
Scan done!
Advertised Device: Name: QN-S3, Address: ed:67:37:5e:9c:e3, manufacturer data: ffffed67375e9ce39432050000014c3e02e606
Advertised Device: Name: , Address: 39:95:09:d1:a8:a2, manufacturer data: 0600010f2002c2fa7d1fd778663ed44963f358f6dd7841a10512b46bdd
Advertised Device: Name: , Address: 5f:dc:3d:d1:d0:4b, manufacturer data: 4c001005531c649ac6, txPower: 12My Scale is (probably obviously) the QN-S3 output lines
Thanks for the infos, I’m checking
Got it:
{"id":"35:45:FF:AA:EE:AA","manufacturerdata":"060001092002f00665e39d79160404ff60bb0f6d3b6e21482e84061cd6","rssi":-55,"distance":0.495572}
You may test if OMG retrieve well your manufacturer data with this branch:
If yes, you may submit a Pull request or/and I can help you with the integration.
The PR must be submitted from the branch refactor-ble.
Thanks. Your sample looks perfect. I compiled everything and loaded the new esp32dev-ble firmware and parititions
I’m getting the manufacturer data as I had hoped now. I’ll write a small script to convert it to kg and let you know for success.
Is this the sort of thing that you wanted to convert and send in human readable? As I’m probably going to modify OMG to do that, now I’ve gotten into the code a bit.
Of course, as it may be usefull to have this type of scale integrated, you can submit a pull request or I will do it based on your script.
Here’s code that is working for me.
#define KG_TO_LBS_RATIO (2.2046226218488)
#define SCALE_BLE_MANUFACTURER_STRLEN (11)
if ( strcmp("QN-S3", (char *)advertisedDevice.getName().c_str()) == 0 ) {
const int slen = SCALE_BLE_MANUFACTURER_STRLEN;
uint8_t *manfData = (uint8_t*)advertisedDevice.getManufacturerData().data();
int kg = manfData[slen - 1] << 8 | manfData[slen - 2];
int isStableMeasurement = (advertisedDevice.getManufacturerData().c_str()[slen - 3] & 0x01);
if ( isStableMeasurement ) {
char strLbs[8];
sprintf( strLbs, "%.1f", (float) kg / 100.0 * KG_TO_LBS_RATIO );
BLEdata.set("weight", strLbs);
Log.notice(F("weight: %s lbs" CR), strLbs );
String lbsTopic = mactopic + String("/") + String("lbs");
pub((char *)lbsTopic.c_str(), strLbs);
}
}
I shoved it right after the
if (advertisedDevice.haveManufacturerData())
in ZgatewayBT.ino
But I’m guessing you have a prettier place to put it. And may not want to force lbs. So I’ll leave it to you to choose what to do with it.
Note that I can not leave the Scan_duration at 10, because the scale throws many readings immediately over and over again, and then when it finally settles in, then it sends that particular reading with a “stable” flag. But if you scan for a long time (multiple seconds), it only gets the first advertisement, which isn’t likely to be the stable reading. So I set my Scan_duration to 2 seconds (and even with that, I worry it may miss the stable reading). Maybe there is a more elegant way to solve that, as your note that reducing Scan_duration below 10 seconds scares me.
I suppose that these many readings are garbage isn’t it, or does these means something ?
We will have to do some test around these values to maybe tweak them. At maximum you may get to how much between 2s and 10s to get the stable data?
These are all valid measurements. The Android app that they offer with the scale shows a fun meter that has a semi-instant readout of what the scale is displaying, I don’t remember now, but I think it was like a 5 hz update or something pretty fast like that. That is why they distinguish between “UI” scale readings and a “stable” measurement.
My concern is that if the scale catches one of those UI measurements, then it waits 2 seconds, then it might miss getting the stable measurement. I’ve tried about 10 times at 2s Scan_duration without a problem. And 10 second I missed well over half of them
So I’ll try the long term test, and after that, I’ll maybe add a beep when it gets a stable measurement to ensure a proper reading.