Support for HEM-7144T2

[TreeviewGera]

Hey. I'd like to get support added for version 7144T2. I've been trying to use the script with it but even getting it to recognize a successful pairing hasn't been possible.

Here's the output from service_explorer.py:

2025-08-14 16:23:28,950 __main__ INFO: starting scan...
2025-08-14 16:23:29,331 __main__ INFO: connecting to device...
2025-08-14 16:23:29,586 __main__ INFO: connected to BLESmart_000000BCF95D33C7649F (F9:5D:33:C7:64:9F)
2025-08-14 16:23:29,586 __main__ INFO: [Service] 00001800-0000-1000-8000-00805f9b34fb (Handle: 1): Generic Access Profile
2025-08-14 16:23:29,943 __main__ INFO:   [Characteristic] 00002a00-0000-1000-8000-00805f9b34fb (Handle: 2): Device Name (read), Value: bytearray(b'HEM-7144T2')
2025-08-14 16:23:30,002 __main__ INFO:   [Characteristic] 00002a01-0000-1000-8000-00805f9b34fb (Handle: 4): Appearance (read), Value: bytearray(b'\x81\x03')
2025-08-14 16:23:30,092 __main__ INFO:   [Characteristic] 00002a04-0000-1000-8000-00805f9b34fb (Handle: 6): Peripheral Preferred Connection Parameters (read), Value: bytearray(b'\x10\x00\x18\x00\x00\x00\xc8\x00')
2025-08-14 16:23:30,093 __main__ INFO: [Service] 00001801-0000-1000-8000-00805f9b34fb (Handle: 8): Generic Attribute Profile
2025-08-14 16:23:30,152 __main__ INFO:   [Characteristic] 00002a05-0000-1000-8000-00805f9b34fb (Handle: 9): Service Changed (read,indicate), Value: bytearray(b'\x01\x00\xff\xff')
2025-08-14 16:23:30,212 __main__ INFO:     [Descriptor] 00002902-0000-1000-8000-00805f9b34fb (Handle: 11): Client Characteristic Configuration, Value: bytearray(b'\x02\x00')
2025-08-14 16:23:30,212 __main__ INFO: [Service] 0000180a-0000-1000-8000-00805f9b34fb (Handle: 12): Device Information
2025-08-14 16:23:30,272 __main__ INFO:   [Characteristic] 00002a29-0000-1000-8000-00805f9b34fb (Handle: 13): Manufacturer Name String (read), Value: bytearray(b'OMRONHEALTHCARE')
2025-08-14 16:23:30,332 __main__ INFO:   [Characteristic] 00002a24-0000-1000-8000-00805f9b34fb (Handle: 15): Model Number String (read), Value: bytearray(b'HEM-7144T2')
2025-08-14 16:23:30,392 __main__ INFO:   [Characteristic] 00002a25-0000-1000-8000-00805f9b34fb (Handle: 17): Serial Number String (read), Value: bytearray(b'0000021F0200C730D816')
2025-08-14 16:23:30,452 __main__ INFO:   [Characteristic] 00002a26-0000-1000-8000-00805f9b34fb (Handle: 19): Firmware Revision String (read), Value: bytearray(b'SI.S01.16.02')
2025-08-14 16:23:30,512 __main__ INFO:   [Characteristic] 00002a28-0000-1000-8000-00805f9b34fb (Handle: 21): Software Revision String (read), Value: bytearray(b'0000000000105001')
2025-08-14 16:23:30,573 __main__ INFO:   [Characteristic] 00002a23-0000-1000-8000-00805f9b34fb (Handle: 23): System ID (read), Value: bytearray(b'\xff\xff\xff\xff\xff\xff\xff\xff')
2025-08-14 16:23:30,573 __main__ INFO: [Service] 0000fe4a-0000-1000-8000-00805f9b34fb (Handle: 25): OMRON HEALTHCARE Co.: Ltd.
2025-08-14 16:23:30,632 __main__ INFO:   [Characteristic] b305b680-aee7-11e1-a730-0002a5d5c51b (Handle: 26): Unknown (read,write-without-response,notify,write), Value: bytearray(b'\x11\xacy\x9e\xa7\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'), Max write w/o rsp size: 64
2025-08-14 16:23:30,722 __main__ INFO:     [Descriptor] 00002902-0000-1000-8000-00805f9b34fb (Handle: 28): Client Characteristic Configuration, Value: bytearray(b'\x00\x00')
2025-08-14 16:23:30,722 __main__ INFO:   [Characteristic] db5b55e0-aee7-11e1-965e-0002a5d5c51b (Handle: 29): Unknown (write-without-response,write), Max write w/o rsp size: 64
2025-08-14 16:23:30,842 __main__ INFO:   [Characteristic] 49123040-aee8-11e1-a74d-0002a5d5c51b (Handle: 31): Unknown (read,notify), Value: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
2025-08-14 16:23:30,902 __main__ INFO:     [Descriptor] 00002902-0000-1000-8000-00805f9b34fb (Handle: 33): Client Characteristic Configuration, Value: bytearray(b'\x00\x00')
2025-08-14 16:23:30,902 __main__ INFO: [Service] 00001805-0000-1000-8000-00805f9b34fb (Handle: 34): Current Time Service
2025-08-14 16:23:30,962 __main__ INFO:   [Characteristic] 00002a2b-0000-1000-8000-00805f9b34fb (Handle: 35): Current Time (read,write,notify), Value: bytearray(b'\xd0\x07\x01\x01\x00\x01;\x00\x00\x01')
2025-08-14 16:23:31,022 __main__ INFO:     [Descriptor] 00002902-0000-1000-8000-00805f9b34fb (Handle: 37): Client Characteristic Configuration, Value: bytearray(b'\x00\x00')
2025-08-14 16:23:31,022 __main__ INFO: [Service] 00001810-0000-1000-8000-00805f9b34fb (Handle: 38): Blood Pressure
2025-08-14 16:23:31,022 __main__ INFO:   [Characteristic] 00002a35-0000-1000-8000-00805f9b34fb (Handle: 39): Blood Pressure Measurement (indicate)
2025-08-14 16:23:31,082 __main__ INFO:     [Descriptor] 00002902-0000-1000-8000-00805f9b34fb (Handle: 41): Client Characteristic Configuration, Value: bytearray(b'\x00\x00')
2025-08-14 16:23:31,142 __main__ INFO:   [Characteristic] 00002a49-0000-1000-8000-00805f9b34fb (Handle: 42): Blood Pressure Feature (read), Value: bytearray(b'\x07\x00')
2025-08-14 16:23:31,142 __main__ INFO: disconnecting...
2025-08-14 16:23:31,259 __main__ INFO: disconnected

And here's a btsnoop log, filtered to only include communication between my phone and the device:
hem_7144t2.log

Right off the bat you can see there doesn't seem to be a service matching with

parentService_UUID        = "ecbe3980-c9a2-11e1-b1bd-0002a5d5c51b"

so I had to remove the check for that during my tests.

I'm using Windows 10 by the way. I'd appreciate any help you can provide on this.

[userx14]

Hi @TreeviewGera ,

the communication log still looks very simmilar to the other omron devices.

[Service] 0000fe4a-0000-1000-8000-00805f9b34fb (this one is different for some reason)
->[Characteristic] b305b680-aee7-11e1-a730-0002a5d5c51b (key/unlock channel)
->[Characteristic] db5b55e0-aee7-11e1-965e-0002a5d5c51b (tx channel)
->[Characteristic] 49123040-aee8-11e1-a74d-0002a5d5c51b (rx channel) 

Just try to replace:

omblepy/omblepy.py

Line 14 in a4e6acf

parentService_UUID = "ecbe3980-c9a2-11e1-b1bd-0002a5d5c51b"

with
parentService_UUID = "0000fe4a-0000-1000-8000-00805f9b34fb"
and see if it fixes the problem.

In your log there is a readout of records from the omron, starting from packet 116 to packet 137.
From this I can already tell that for the device driver you will likely need:

deviceEndianess           = "big"
settingsReadAddress       = 0x260
userStartAdressesList     = [0x2e8]
perUserRecordsCountList   = [30]
transmissionBlockSize     = 0x38
recordByteSize            = 0x0e

Some raw hexadecimal records in your hem_7144t2.log:

624c5e199621d41a800001004bb4
50453f19ae61c91a80200200817e
49473e19ae212a1b800003007e81
5b474519ae611f1c804004000ef1

Probably the front three bytes are sys, dia and bpm, after this probably the year (0x19 + 2000 = 2025), and rest of the date:

year                   = self._bytearrayBitsToInt(singleRecordAsByteArray, 24, 31) + 2000

Maybe you can figure the rest out by comparing it to the displayed values on the device. The other device drivers could share some similarities as well.

Please let me know if you have further questions,
Benjamin

[TreeviewGera]

Hey Benjamin, thank you so much for your quick response.

I did as you suggested and wrote the file as such:

import sys
import datetime
import logging
logger = logging.getLogger("omblepy")

sys.path.append('..')
from sharedDriver import sharedDeviceDriverCode

class deviceSpecificDriver(sharedDeviceDriverCode):

    deviceEndianess           = "big"
    userStartAdressesList     = [0x2e8]
    perUserRecordsCountList   = [30]
    recordByteSize            = 0x0e
    transmissionBlockSize     = 0x38

    settingsReadAddress       = 0x260
    #settingsWriteAddress            = 0x0286

    #AsettingsUnreadRecordsBytes      = [0x00, 0x08]
    #AsettingsTimeSyncBytes           = [0x14, 0x1e]

    def deviceSpecific_ParseRecordFormat(self, singleRecordAsByteArray):
        #recordDict["mov"]      = self._bytearrayBitsToInt(singleRecordAsByteArray, 32, 32)
        #recordDict["ihb"]      = self._bytearrayBitsToInt(singleRecordAsByteArray, 33, 33)

        recordDict             = dict()
        recordDict["sys"]      = self._bytearrayBitsToInt(singleRecordAsByteArray, 0, 7) + 25
        recordDict["dia"]      = self._bytearrayBitsToInt(singleRecordAsByteArray, 8, 15)
        recordDict["bpm"]      = self._bytearrayBitsToInt(singleRecordAsByteArray, 16, 23)
        year                   = self._bytearrayBitsToInt(singleRecordAsByteArray, 24, 31) + 2000
        month                  = self._bytearrayBitsToInt(singleRecordAsByteArray, 32, 35)
        day                    = self._bytearrayBitsToInt(singleRecordAsByteArray, 36, 40)
        hour                   = self._bytearrayBitsToInt(singleRecordAsByteArray, 41, 45)
        minute                 = self._bytearrayBitsToInt(singleRecordAsByteArray, 50, 55)
        second                 = self._bytearrayBitsToInt(singleRecordAsByteArray, 56, 61)
        second                 = min([second, 59])
        recordDict["datetime"] = datetime.datetime(year, month, day, hour, minute, second)
        return recordDict

    def deviceSpecific_syncWithSystemTime(self):
        raise ValueError("Not supported yet.")

This may be correct or not, the issue is I can't get the pairing to fully complete to test.
I'm running the following command:

python313 omblepy.py -d HEM-7144T2 -p -m F9:XX:XX:XX:XX:XX

But the script hangs indefinitely after printing omblepy - INFO - Attempt connecting to F9:XX:XX:XX:XX:XX. The device stays in pairing mode, with the blinking "P".

Adding some more print calls to check where exactly this happens, I find out that execution reaches this line:

        await bleClient.write_gatt_char(self.deviceUnlock_UUID, b'\x02' + b'\x00', response=True)

but the while loop right after never finishes. Indeed adding a print statement to the _callbackForUnlockChannel methods confirms that it never does get called. I'm not very familiar with bluetooth protocols so I'm not sure why this happens. Do you have any ideas on what could the issue be?

Thanks again.

[userx14]

Do you get a pairing dialog in windows?
In my past tests being quick when accepting the dialog was essential for it working.
If it freezes when writing to a characteristic I would guess it is a problem with bluetooth pairing not working.
For my tests I always delete the device out of the list of previously paired devices, have the bt-settings open so the pairing dialog comes up more quickly and accept within 1-2 seconds.

There would be an option to either test it with esp32 or an android phone to rule out windows or bluetooth hardware issues.
For esp32: https://github.com/userx14/omblepy/tree/esp32bridge
For android with nrfconnect: #16 (comment) .

[TreeviewGera]

Yes, the pairing dialog does appear, and I do accept it really fast, within 1 or 2 seconds.

Sadly I do not have an esp32 to test with.

I tried nrfconnect. First I replaced all instances of ecbe3980-c9a2-11e1-b1bd-0002a5d5c51b with 0000fe4a-0000-1000-8000-00805f9b34fb in the xml. This allowed me to run the macro. All write steps seemed to work fine and displayed a checkmark when run, but the read steps showed an alert icon.

[userx14]

Does the blinking -P- disapear after you try the nrfconnect script?
Maybe the pairing process is different for this device, would it be possible to record a hcilog of this?

[TreeviewGera]

The blinking P does not disappear, no.
The log I shared above should start with the pairing process, via the official app. Is that what you mean?

[userx14]

Oh, thanks for pointing out that the log is from a pairing process, I did miss that in the log.
So the device seems to be using a slightly different pairing process:

In packet 112 I see a only a single write to the unlock characteristic with 115f9469fc00...00 as the data.
I would guess that 5f9469fc is a shorted 4 byte pairing key. Then as a response one gets: 91005f9469fc00...00

So this code here needs to be modified:

omblepy/omblepy.py

Lines 210 to 236 in a4e6acf

	async def writeNewUnlockKey(self, newKeyByteArray = examplePairingKey):
	if(len(newKeyByteArray) != 16):
	raise ValueError(f"key has to be 16 bytes long, is {len(newKeyByteArray)}")
	return
	#enable key programming mode
	await bleClient.start_notify(self.deviceUnlock_UUID, self._callbackForUnlockChannel)
	self.rxFinishedFlag = False
	await bleClient.write_gatt_char(self.deviceUnlock_UUID, b'\x02' + b'\x00'*16, response=True)
	while(self.rxFinishedFlag == False):
	await asyncio.sleep(0.1)
	deviceResponse = self.rxDataBytes
	if(deviceResponse[:2] != bytearray.fromhex("8200")):
	raise ValueError(f"Could not enter key programming mode. Has the device been started in pairing mode? Got response: {deviceResponse}")
	return
	#program new key
	self.rxFinishedFlag = False
	await bleClient.write_gatt_char(self.deviceUnlock_UUID, b'\x00' + newKeyByteArray, response=True)
	while(self.rxFinishedFlag == False):
	await asyncio.sleep(0.1)
	deviceResponse = self.rxDataBytes
	if(deviceResponse[:2] != bytearray.fromhex("8000")):
	raise ValueError(f"Failure to program new key. Response: {deviceResponse}")
	return
	await bleClient.stop_notify(self.deviceUnlock_UUID)
	logger.info(f"Paired device successfully with new key {newKeyByteArray}.")
	logger.info("From now on you can connect omit the -p flag, even on other PCs with different bluetooth-mac-addresses.")
	return

Untested proposed code:

async def writeNewUnlockKey(self, newKeyByteArray = examplePairingKey): 
     if(len(newKeyByteArray) != 16): 
         raise ValueError(f"key has to be 16 bytes long, is {len(newKeyByteArray)}") 
         return 
     await bleClient.start_notify(self.deviceUnlock_UUID, self._callbackForUnlockChannel) 
     self.rxFinishedFlag = False 
     newKeyByteArray[4:] = 12*[0] #erase everything but first 4 bytes
     await bleClient.write_gatt_char(self.deviceUnlock_UUID, b'\x11' + newKeyByteArray, response=True) 
     while(self.rxFinishedFlag == False): 
         await asyncio.sleep(0.1) 
     deviceResponse = self.rxDataBytes 
     if(deviceResponse[:2] != bytearray.fromhex("9100")): 
         raise ValueError(f"Failure to program new key. Response: {deviceResponse}") 
         return 
     await bleClient.stop_notify(self.deviceUnlock_UUID) 
     logger.info(f"Paired device successfully with new key {newKeyByteArray}.") 
     logger.info("From now on you can connect omit the -p flag, even on other PCs with different bluetooth-mac-addresses.") 
     return 

What would also be interesting is a hcilog recording when the device was already paired, to see what codes it sends in this case.
I guess that the unlocking function when paired async def unlockWithUnlockKey(self, keyByteArray = examplePairingKey) also needs some modification.

[TreeviewGera]

Unfortunately that hangs in the same spot as before... I tried ensuring the data sent is exactly 16 bytes but it didn't make a difference.

Some random thoughts:

• Could the "Write Request" packets that come before that "Write Command" packet be important or necessary?
• Packet 112 says the handle is 0x001b, which is 27 in decimal. According to the service_explorer dump, characteristic b305b680-aee7-11e1-a730-0002a5d5c51b has handle 26, and there is no entry with handle 27. I'm assuming this is normal somehow?

I'll get another pairing log and a log with the device already paired soon. Thank you once again for your help so far.

[userx14]

From the 0x11 start of the message to total message should be 17 bytes long, and the key should be 16 bytes long.
Not sure why this does not work. The message in the hci log has a total length of 20 bytes which is also strange.

The "Write Request" you see in the log is the same as bleClient.start_notify(self.deviceUnlock_UUID, ...). This will notify the client when there is a change in the characteristic and generate a callback, this happens in packet 115 "Value Notification". I also see this happening for the other omron devices, where the communication works. You can try removing the start_notify and just repeatedly read the characteristic instead as a test if this is the part of the code where it freezes the python script.

The nrfconnect app was very helpful in my testing, you can connect to the device without having to quickly confirm the pairing dialog, enable "notify on change" on the unlock characteristic and try writing the values to it. Testing on windows is not super reliable, as you cannot tell easily if the problem is just some windows pairing issue, some older bluetooth version that the adapter is using or you doing something wrong in the communication commands.

[TreeviewGera]

I tried writing 17 bytes, 16 bytes and 20 bytes, but was never able to get a response.

I also tried using the nrfconnect app. I enable notifications on the characteristic and write to it, but get no notifications back...

I got some more logs as well. I tried getting another pairing log, but it seems it came out almost exactly the same as last time. I also got a log with the device already paired. And I also noticed that the omron app lets me choose between 3 "device registering methods", so I got pairing logs with the second and third registering methods just in case they could be useful... They do seem somewhat different at least.

Pairing with method 1 log: hem_7144t2 pair_1.log
Already paired log: hem_7144t2 read.log
Pairing with method 2 log: hem_7144t2 pair_2.log
Pairing with method 3 log: hem_7144t2 pair_3.log

[userx14]

So from the logs I would say we can draw the following conclusions:

• for all the other omron device I've seen so far the process is that a pairing key is programmed once and can then be used in a modified message for unlocking, this does not seem to be the case for this device.
• the writing process to the deviceUnlock_UUID looks the same in the paired and unpaired state. The four bytes that are sent as "key" seem to be different each time

I'm not sure how the four bytes are generated, maybe it uses some infromation from previous reads from the device.
Could you try writing the bytes from one of the previous captured messages (0x11 + 0x348bba2 or 0x11 + 0x8b6a20b6) with nrfconnect and see if they do something?

[TreeviewGera]

I've tried it. If I do it over and over on nrfconnect, eventually I do get a response and the first square appears on the device, replacing the P. But nothing else happens. And I haven't been able to replicate that with the python script for some reason...

I've now pivoted to try reverse engineering the official .apk. I believe I identified a function that constructs the byte array in question:

public static synchronized byte[] e(byte[] bArr) {
    DebugLog.eLogKind elogkind = DebugLog.eLogKind.S;
    if (bArr != null && bArr.length == 4) {
        byte[] bArr2 = new byte[20];
        bArr2[0] = 17;
        System.arraycopy(bArr, 0, bArr2, 1, bArr.length);
        DebugLog.eLogKind elogkind2 = DebugLog.eLogKind.E;
        return bArr2;
    }
    DebugLog.r("[OHQ]", "OHQSysCommand", "createTransactionCommand", DebugLog.eLogKind.M, "illegal argument");
    return null;
}

It seems you were correct, there is a 4 byte key, and the 0x11 (17 in decimal) is prepended to it. The final array is defined to be 20 bytes long as well as you can see. The 4 byte key is randomly generated earlier with java's SecureRandom().

Anyway I was gonna investigate more but something came up so I'll have to pause this for now. I'll leave you with a file I found that may help with info on this and all other models as well:

Memory_Map.zip

[userx14]

If I do it over and over on nrfconnect, eventually I do get a response and the first square appears on the device, replacing the P. But nothing else happens.

That's as expected, I mean the freeze on the square display not the unreliability 😄 . After writing to the unlock characteristic it waits for the rest of the commands on the tx and rx channel to read the actual data, the rotating squares start when the start transmission message 0800000000100018 is sent to the rx channel. The device freezing with one square when not recieving the follow up communication also happens on the other omron devices.

I don't get why it is random if it works or not. Did you just write to the unlock characteristic and always the same code?
Could it be some timing thing? I mean the original code reads some manufacturer strings like device name and version number which takes some time.

[TreeviewGera]

Yeah the random thing is weird. I just keep writing to the unlock characteristic over and over, switching around between different codes. Eventually one of them will produce a response, usually after 5-10 writes. It's quite weird but yeah. I also thought it could be a timing thing but haven't been able to identify any pattern so far. Good to know the square thing is expected.

On the script if I remove the while loops and associated checks, I do eventually see the first square appear. With a few more changes some subsequent squares appear as well, but eventually the script crashes. I'm not sure if that's progress or not. The main issue seems to be that the device just refuses to send reply notifications for some reason...

Would it be possible to get data relying only on direct reads rather than notifications?