Connect OMG to bluetooth pulse oximeter

I have a (cheap) bluetooth-enabled pulse oximeter (PC-60FW).
I am running OMG on an ESP32 with esp32dev-ble firmware.

I can “see” the device in MQTT explorer as follows:

{
  "id": "00:00:00:03:10:C4",
  "name": "PC-60F_SN200900",
  "rssi": -69
}

Presumably this is just the basic “here I am” advertising message.

Based on Theengs Compatible BLE devices, its seems like this device is not (yet) officially supported.

How do I “pair” with this device and “decode” the heart-rate and 02-sat data that it presumably broadcasts regularly?

I have played a fair bit with the RTL-433 codebase in OMG but am new to BT devices so any pointers would be appreciated.

Note that the device doesn’t seem to require any explicit pairing since when I downloaded an app it simply scanned and connected without any manual pairing or approval.

Based on pc-60fw/arduino-proxy/oximeter-bt-proxy/oximeter-bt-proxy.ino at main · pythag/pc-60fw · GitHub and Bluetooth ESP32 gateway | Theengs OpenMQTTGateway v1.8.1, I tried the following but it gave no response beyond the usual continued, intermittent advertising messages stating the id/name/rssi values:

 mosquitto_pub -h homeassistant -u MQTT -P $PASSWD -t "home/OMG_ESP32_BLE/commands/MQTTtoBT/config" -m '{
    "ble_read_address":"00:00:00:03:10:C4", 
    "ble_read_service":"6e400001-b5a3-f393-e0a9-e50e24dcca9e",
    "ble_read_char":"6e400003-b5a3-f393-e0a9-e50e24dcca9e", 
    "value_type":"STRING",
    "ttl": 2 
}'

where 00:00:00:03:10:C4 is the id mentioned in the original post.
I get the same lack of response regardless of what I use for ble_read_address or indeed any of the ble_read_ parameters.

I also tried substituting _sub_ for _read_ to no avail.
Similarly changing ‘STRING’ to ‘HEX’
Similarly to preceding with a write:

 mosquitto_pub -h homeassistant -u MQTT -P $PASSWD -t "home/OMG_ESP32_BLE/commands/MQTTtoBT/config" -m '{
    "ble_write_address":"00:00:00:03:10:C4", 
    "ble_write_service":"6e400001-b5a3-f393-e0a9-e50e24dcca9e",
    "ble_write_char":"6e400002-b5a3-f393-e0a9-e50e24dcca9e", 
    "value":"0200",
    "value_type":"STRING",
    "ttl": 2 
}'

Do you monitor the serial log in parallel to analyze any feedback from the command response ?

Yes - strangely, I do not get any meaningful response on the serial monitor
Specifically, the response is always of form:

T: MQTT Msg topic: home/OMG_ESP32_BLE/commands/MQTTtoBT/config
T: MQTTtoBT json set
T: update WorB
T: update WorB
T: Announce Device number on  homeassistant-BLE/number/08A6F7BD1128-interval/config
T: Enqueue JSON
T: Queue length: 1
T: Announce Device number on  homeassistant-BLE/number/08A6F7BD1128-intervalacts/config
T: Enqueue JSON
T: Queue length: 2
T: Announce Device number on  homeassistant-BLE/number/08A6F7BD1128-presenceawaytimer/config
T: Enqueue JSON
T: Queue length: 3
T: Enqueue JSON
T: Queue length: 4
T: Dequeue JSON
N: [ OMG->MQTT ] topic: homeassistant-BLE/number/08A6F7BD1128-interval/config msg: {"stat_t":"home/OMG_ESP32_BLE/BTtoMQTT","avty_t":"home/OMG_ESP32_BLE/LWT","unit_of_meas":"s","name":"BT: Interval between scans","uniq_id":"08A6F7BD1128-interval","val_tpl":"{{ value_json.interval/1000 }}","cmd_tpl":"{\"interval\":{{value*1000}},\"save\":true}","pl_avail":"online","pl_not_avail":"offline","cmd_t":"home/OMG_ESP32_BLE/commands/MQTTtoBT/config","device":{"ids":["08A6F7BD1128"],"name":"OMG_ESP32_BLE","mdl":"[\"WebUI\",\"BT\"]","mf":"OMG_community","cu":"http://192.168.1.117/","sw":"JJK [Apr 25 2025 12:09:38]"}}
T: Dequeue JSON
N: [ OMG->MQTT ] topic: homeassistant-BLE/number/08A6F7BD1128-intervalacts/config msg: {"stat_t":"home/OMG_ESP32_BLE/BTtoMQTT","avty_t":"home/OMG_ESP32_BLE/LWT","unit_of_meas":"s","name":"BT: Interval between active scans","uniq_id":"08A6F7BD1128-intervalacts","val_tpl":"{{ value_json.intervalacts/1000 }}","cmd_tpl":"{\"intervalacts\":{{value*1000}},\"save\":true}","pl_avail":"online","pl_not_avail":"offline","cmd_t":"home/OMG_ESP32_BLE/commands/MQTTtoBT/config","device":{"ids":["08A6F7BD1128"],"name":"OMG_ESP32_BLE","mdl":"[\"WebUI\",\"BT\"]","mf":"OMG_community","cu":"http://192.168.1.117/","sw":"JJK [Apr 25 2025 12:09:38]"}}
T: Dequeue JSON
N: [ OMG->MQTT ] topic: homeassistant-BLE/number/08A6F7BD1128-presenceawaytimer/config msg: {"stat_t":"home/OMG_ESP32_BLE/BTtoMQTT","avty_t":"home/OMG_ESP32_BLE/LWT","unit_of_meas":"min","name":"BT: Presence/Tracker timeout","uniq_id":"08A6F7BD1128-presenceawaytimer","val_tpl":"{{ value_json.presenceawaytimer/60000 }}","cmd_tpl":"{\"presenceawaytimer\":{{value*60000}},\"save\":true}","pl_avail":"online","pl_not_avail":"offline","cmd_t":"home/OMG_ESP32_BLE/commands/MQTTtoBT/config","device":{"ids":["08A6F7BD1128"],"name":"OMG_ESP32_BLE","mdl":"[\"WebUI\",\"BT\"]","mf":"OMG_community","cu":"http://192.168.1.117/","sw":"JJK [Apr 25 2025 12:09:38]"}} 
T: Dequeue JSON
N: [ OMG->MQTT ] topic: home/OMG_ESP32_BLE/BTtoMQTT msg: {"bleconnect":true,"interval":55555,"adaptivescan":true,"intervalacts":55555,"intervalcnct":3600000,"scanduration":10000,"hasspresence":false,"prestopic":"presence/","presuseuuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","pubuuid4topic":false,"ignoreWBlist":false,"forcepscn":false,"tskstck":1676,"crstck":3056,"enabled":true,"scnct":7,"onlysensors":false,"randommacs":false,"filterConnectable":false,"pubadvdata":false,"presenceawaytimer":120000,"movingtimer":60000}

Not sure what it should be though…

Looking more through the logs, I noticed that when scanning, the log seems to say that no eligible device is found:

N: BT Device detected: 00:00:00:03:10:C4
T: getDeviceByMac 00:00:00:03:10:C4
T: Processing BLE data 00:00:00:03:10:C4
T: No eligible device found 
T: Origin: /BTtoMQTT/0000000310C4
T: Enqueue JSON
T: Queue length: 1
T: Dequeue JSON
N: [ OMG->MQTT ] topic: home/OMG_ESP32_BLE/BTtoMQTT/0000000310C4 msg: {"id":"00:00:00:03:10:C4","name":"PC-60F_SN200900","rssi":-59} 

I then tried to remove filters by sending:

mosquitto_pub -h homeassistant -u MQTT -P $PASSWD -t "home/OMG_ESP32_BLE/commands/MQTTtoBT/config" -m '{
    "onlysensors": false,
    "filterConnectable": false,
    "ignoreWBlist": true,
    "save": true
}'

But I still get no eligible device found:

N: BT Device detected: 00:00:00:03:10:C4
T: getDeviceByMac 00:00:00:03:10:C4
T: Processing BLE data 00:00:00:03:10:C4
I NimBLEScan: New advertiser: 6a:09:d8:79:f7:70
I NimBLEScan: Updated advertiser: 6a:09:d8:79:f7:70
T: No eligible device found 
T: Origin: /BTtoMQTT/0000000310C4
T: Enqueue JSON
T: Queue length: 1
T: Dequeue JSON
T: Creating BLE buffer: home/OMG_ESP32_BLE/BTtoMQTT/0000000310C4 msg: {"id":"00:00:00:03:10:C4","name":"PC-60F_SN200900","rssi":-55}

Note: the device does not require any explicit pairing…

You should remove the config at the end of your topic:

Ahhh… not sure why I had ‘config’ but now when I remove ‘/config’, and type:

mosquitto_pub -h homeassistant -u MQTT -P $PASSWD -t "home/OMG_ESP32_BLE/commands/MQTTtoBT" -m '{
    "ble_write_address":"00:00:00:03:10:C4",
    "ble_write_service":"6e400001-b5a3-f393-e0a9-e50e24dcca9e",
    "ble_write_char":"6e400002-b5a3-f393-e0a9-e50e24dcca9e",
    "value":"0200",
    "value_type":"HEX",
    "ttl": 4

I get the error:

T: MQTT Msg topic: home/OMG_ESP32_BLE/commands/MQTTtoBT
E: BLE mac address missing
T: BLE ACTION TTL = 4

I can make the error go away by adding:

"id":""00:00:00:03:10:C4",

but that then just yields the response:

T: MQTT Msg topic: home/OMG_ESP32_BLE/commands/MQTTtoBT
T: BLE ACTION TTL = 4

And doesn’t do anything!
Also, based on the documentation, “id” should be part of the response, not the command – and I don’t get any response (beyond the occasional advertising message)

I also keep coming back to the fact that scans, seem to say that no eligible device found:

I NimBLEScan: Updated advertiser: 00:00:00:03:10:c4
T: Creating BLE buffer
N: BT Device detected: 00:00:00:03:10:C4
T: getDeviceByMac 00:00:00:03:10:C4
T: Processing BLE data 00:00:00:03:10:C4
T: No eligible device found 
T: Origin: /BTtoMQTT/0000000310C4
T: Enqueue JSON
T: Queue length: 1
T: Dequeue JSON
N: [ OMG->MQTT ] topic: home/OMG_ESP32_BLE/BTtoMQTT/0000000310C4 msg: {"id":"00:00:00:03:10:C4","name":"PC-60F_SN200900","rssi":-75}

Do I need to set up an external decoder or other custom configuration for this device before I can g any responses beyond advertising?

I have been playing around with this all day and am stuck!

Is it possible that your device is already connected to another, like your smartphone and hence not visible in the scan ?

I don’t think so.

  • It doesn’t show as connected on the device screen
  • I turned off bluetooth on my phone and restarted the device
  • I even tried removing the batteries on the device for a couple of minutes
  • I can connect via the standalone Arduino sketch I linked to above

I’m really stuck here.

  • Is the problem that the scan says “No eligible device found” or is the problem that I am not sending the right command to manually connect to the device?

Looking at the serial log, it seems that the vast majority of the bluetooth devices advertised, say T: No eligible device found showing something like:

I NimBLEScan: New advertiser: 66:4e:d7:40:c9:6f
I NimBLEScan: Updated advertiser: 66:4e:d7:40:c9:6f
T: Creating BLE buffer
N: BT Device detected: 66:4E:D7:40:C9:6F
T: getDeviceByMac 66:4E:D7:40:C9:6F
T: Get services data number: 1
T: Converted service data (22) to 01b70eb77b4bbd400388e88ed8c880b9b00000000003
T: Service data: 01b70eb77b4bbd400388e88ed8c880b9b00000000003
T: Service data UUID: 0xfdf7
T: Processing BLE data 66:4E:D7:40:C9:6F
T: No eligible device found 
T: Origin: /BTtoMQTT/664ED740C96F
T: Enqueue JSON
T: Queue length: 1
T: Dequeue JSON
N: [ OMG->MQTT ] topic: home/OMG_ESP32_BLE/BTtoMQTT/664ED740C96F msg: {"id":"66:4E:D7:40:C9:6F","rssi":-95} 

Only a couple of devices say instead T: Random MAC or iBeacon device filtered, showing something like:

I NimBLEScan: New advertiser: 3f:75:18:54:6a:b0
T: Creating BLE buffer
N: BT Device detected: 3F:75:18:54:6A:B0
T: getDeviceByMac 3F:75:18:54:6A:B0
T: Processing BLE data 3F:75:18:54:6A:B0
T: Random MAC or iBeacon device filtered
T: Origin: /BTtoMQTT/3F7518546AB0
T: Enqueue JSON
T: Queue length: 1
T: Dequeue JSON
N: [ OMG->MQTT ] topic: home/OMG_ESP32_BLE/BTtoMQTT/3F7518546AB0 msg: {"id":"3F:75:18:54:6A:B0","rssi":-96,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"4c00","uuid":"2686f39cbada4658854aa62e7e5e8b8d","major":1,"minor":0,"txpower":-55}

Am I correct in assuming that ineligible devices are not connected automatically?
If so, what do I need to do to either:

  1. Specify my device as an eligible device so it connects automatically (?)
  2. Manually force a connection despite the device being ineligible

H @puterboy

Have you had a look at the mac_type of your Pulse-Oximeter? Turn on Advanced and Advertising Data to be included in the regular broadcasts of your device to see which mac_type it has, and if it is not the default "mac_type": 0 you will need to specify it with every READ and WRITE command.

Thanks.
Setting "pubadvdata":true, gives:

T: Creating BLE buffer: home/OMG_ESP32_BLE/BTtoMQTT/0000000310C4 msg: {"id":"00:00:00:03:10:C4","mac_type":0,"adv_type":0,"name":"PC-60F_SN200900","rssi":-64}

And since the docs say mac_type=0, is the default, I assume this is not the problem.

That’s not it then, but always good too double check, not that it’s just a missing mac_type :wink:

Have you checked the service/char with nRFConnect at all, to see if you can connect, access and read it at all there?

Or could it be that it is actually a NOTIFY service/char, which AFAIK is not possible with the direct READ and WRITE commands of OMG?

Does you Pulse-Oximeter also have a battery level service/char, possibly the default 180f/2a19, and if so, does this work READing directly, or at least give any response, even if a failed one?

Also have a look in MQTT Explorer if any responses might be mistakenly coming in under other topics, possibly malformed topics.

I have been using MQTT Explorer and it just shows me the id, name, and rssi.
I downloaded nRFConnect Mobile and it is really cool.

First, after scanning, I see:

Then, after connecting, I see:

Then, if I press on TX Characteristic for the Nordic UART Service (the one with the Notify property), I get a stream of string values varying in length from 7 to 11 bytes (most being 11 bytes).
All the strings begin with AA 55 0F.
I’m not sure what they all encode, but from the Arduino Sketch, pc-60fw/arduino-proxy/oximeter-bt-proxy/oximeter-bt-proxy.ino at main · pythag/pc-60fw · GitHub, I know that the 11 byte strings beginning with AA 55 0F 08 01 have the O2_sat and pulse encoded in the next 2 bytes respectively.

So, bottom line I can read from the BT Pulse Ox using nRF Connect

The question is now how do I do this in OMG?
Specifically, how do you read (and potentially write) to BLE devices with the Nordic UART (NUS) GATT Service which emulates a UART over BT.

Perhaps the problem why it doesn’t connect has to do with:
Flags: LE Limited Discoverable, BR\EDR Not Supported???

OR is OpenMQTTGateway the wrong tool for this and I really shoreuld just be using a dedicated ESPHome to read the BLE data? (though this seems wasteful and I would prefer to figure out how to do this in OMG)

AFAIK the reception of the NOTIFY streams is not handled in OMG currently, but someone more familiar with that part of the code might be better suited to state the reasons.

While for any other characteristics under other services which have WRITE or READ defined, like the top two Device Name and Appearance should be READable fine.

For the NOTIFY it looks like you currently need to find a different solution.

Ahhh I didn’t realize that. Too bad.
@1technophile is it correct that NOTIFY is not handled?
If so, are there any plans to handle it?
Thanks.

Not sure how difficult it would be @h2zero what do you think ?

Doable to some degree, would be like the LWYS sensors where we would connect and wait for a notification to get the battery level then disconnect. Maintaining a constant connection to it to get all the data is not really within the scope of OMG though and would be better to have a second device that stays connected and rebroadcasts the info for OMG to receive from advertisements.

Could also be a different build of OMG I suppose ?

Could be, though it would really just be a BLE device broadcasting data read from devices that require connection.