I’m rather surprised by your report that using read/register for bytes returned nothing. The bytes representation is the most basic and essentially gives you access to the underlying packet without any interpretation of the values. Every other type requires some interpretation as each type is larger than 1 byte (other than bytes, of course).
I also want to point out that the heart rate service and heart rate measurement characteristic are a bit more sophisticated than just reading a value off the wire. In particular, the first byte of the packet is a bitfield containing flags that are used to interpret the remainder of the packet (Bluetooth SIG reference).
If we look at the underlying representation of your data, it will look like this (hex):
The first byte is the flag byte, and the important bit here (pun intended) is that it indicates that there is only a single byte of data in the remainder of the packet. The second byte is the data byte. Your sketch mimics a heart rate monitor by simply counting from 100 to 175 and then resetting back to 100 ad infinitum and we can see that behavior exhibited here in your data.
When you attempt to interpret the data as short (16-bit) values, they are interpreted least-significant bit first, so the first value will be 0x6600, or 26112, the second will be 0x6700 (26368), etc. Likewise, with the interpretation as strings you end up seeing the ASCII interpretation of these values (f, g, h, …).
To facilitate working with this type of data, I’ve created the following extension:
It requires this version of the BLE extension and will not work with earlier versions of the extension:
And here is a test app that I used to test with an Arduino using a similar sketch to the one you showed above.
HeartRateTest.aia (196.5 KB)