BLE read Int problem

I can't for the life of me get AI2 to read the BLE output correctly. My Arduino Nano 33 Sense is sending sensor data as Int. The only thing AI2 will respond to is Byte. If I change Register for Bytes to Register for Integers, I get nothing. I must be do something wrong but I have yet to find what I am doing wrong.BLE02_read.aia (192.7 KB) BLE_PTH_Indicator.txt (3.9 KB)
I've interfaced my Arduino to LightBlue and everything comes across exactly as intended.

How many bytes are being sent by the Arduino? The BLE extension expects that there should be 4 bytes when reading an integer. If the device only sends 1 byte because the value is <= 255, that would explain why it goes through with read bytes but not read ints.

Arduino is declared as an Int. So if the temperature x 100 is 2700, LightBlue shows it as 4 bytes 8C 0A 00 00. Telling it it is Little Endian, it shows it as 2700. Reading in AI2 as Byte, I get 4 numbers -116 10 0 0. This is equivalent to the hex values but in signed decimal.
So the data is coming across but is that as good as it gets? Can't I tell it it is an integer?

Hmm. If you're seeing four bytes coming in via ReadBytes (which would be expected for a 4-byte wide int), then there is potentially a bug in how the ReadInt function is (isn't) working. We'll have to take a look on our end.

This is another report from ReadInt. Someone has already reported this problem and we haven't found a solution. I think it's a problem with the extension.

Great. Many hours later....

Next question, just to get it straight - I see some people use Register then immediately do a Read rather that a wait for it to be received. The Read is not required, right?

Register sets up notifications, but if your data are not changing frequently then often you want to read the value as well so you have what's currently there.

Got it.

Elsewhere there is a thread (which I think @Patryk_F is alluding to) where I provided a function that would convert the result of ReadBytes / RegisterBytes from a 4-tuple to an integer. You may want to consider using that as a workaround until we can better understand why the extension doesn't seem to be doing the right thing.

So it turns out I misremembered. The original thread was for parsing short values instead of int values. However, the concept is fairly extensible: