Question regarding the support of HEM-7380T1-EBK

[vdemcak]

I recently came across Omrons new-ish blood pressure monitor model - HEM-7380T1-EBK - and I was wondering about its compatibility, specifically:

1. Does anyone have experience with this model and it's protocol?
2. Does it use the same Bluetooth-LE protocol as the other supported devices, or is there a new, proprietary protocol involved?
3. Are there plans to add official support for this device, or guidance on how to reverse-engineer its data format if it’s not yet supported?

I've tried tinkering with it a bit and from what I can tell, it uses something totally different from the other models.

Any insights or pointers would be greatly appreciated.

Thanks in advance.

[userx14]

I do not have experience with this model, and it seems quiet new.

Some things that would be helpful to try:

• Get a log of the communication with an android phone (hci_log) while syncing the data with the official app
• If you have this log you can either share it here, or if you prefer, I can give you some hints for analysis
• Check what bluetooth characteristic the device has, check if has 49123040-aee8-11e1-a74d-0002a5d5c51b, db5b55e0-aee7-11e1-965e-0002a5d5c51b and b305b680-aee7-11e1-a730-0002a5d5c51b
• When basic communication is working, there is also the need to reverse engineer the record format. You can either compare some of your records with the bits and try to identify them, or try to use information from MemoryMap.zip here:
  Support for HEM-7144T2 #55 (comment)

Any work on integrating new models is greatly appreciated.

[LazyT]

Looks like newer devices doesn't require pairing and use UUID 0000fe4a-0000-1000-8000-00805f9b34fb instead of ecbe3980-c9a2-11e1-b1bd-0002a5d5c51b now.

The rest works like before in UBPM.

[userx14]

In this issue I had some discussion about support for HEM-7144T2 which also seems to follow this new UUID ending on ...9b34fb.
From what I can tell there are the following differences:

• the main UUID is different
• only one rx and tx channel instead of four tx and four tx channels, the new channels support longer messages
• The unlock UUID still exists, but I'm not sure what it is used for. The app seems to send a 4 byte sequence to the device. The message has the same starting byte, irrespective if it is paired or not. @LazyT do you know if one can just ignore this?

I have not included the changes in my main branch, but there exists a testing branch

[LazyT]

I've no idea, sorry.

Added only 7146T / 7380T last month, after tester confirmed that they worked without any pairing.