Reverse engineering of a bluetooth sensor I have a problem.
I'm trying to trigger some events with Arduino using some bluetooth LE sensor by a chinese manufacturer, Kaipule. I buy this sensor on Alibaba and I'm trying to understand how can I interface them in my sketch. 

They are magnetic contact sensors and I know that they have just the BLE broadcasting mode (no GATT, profile etc): they send information when I open the contact or I close the contact. 

I try to scan them with a BLE scanner and this is the log

kCBAdvDataIsConnectable : 0
Local Name : iSensor 
Manufacturer Data : &lt;beca2c02 4602f9f7&gt;


I know that:

1) the scanner can see the sensor just when I open/close the contact to save battery, so the sensor broadcast data just when it need.

2) every hour the sensor send a status signal

3) every time I open and close the contact the code change a little. Here is a sequence

&lt;beca2c02 46025856&gt; - &gt; open
&lt;beca2c02 46005955&gt; - &gt; close
&lt;beca2c02 46025a58&gt; - &gt; open
&lt;beca2c02 46005b57&gt; - &gt; close
&lt;beca2c02 46025c5a&gt; - &gt; open
&lt;beca2c02 46005d59&gt; - &gt; close
&lt;beca2c02 46025e5c&gt; - &gt; open
&lt;beca2c02 46005f5b&gt; - &gt; close


etc

4) The first part of the code is the identification of the sensor.



3) From the changing code I assume that 2 is the status open, 0 is the status close and I see also a pattern for other bytes but I cannot understand why for example there is a rolling code.

I have the paper the company send to me, but I cannot find any useful reference.

Wireless sensor 1
Wireless sensor 2
Looking at the datasheet, I interpreted it as:

Byte 1 - 0x46

Indicating this is a unidirectional device (bit7=0) that uses fixed time sending (bit 6=1 which doesn't seem correct) and it is of type 'door contact' (bits 0-5=0x06)

Byte 2 - 0x00/0x02

Indicating that the door is open or closed (bit 1 = 0 or 1). I also think that it indicates there is 'enough battery power' (bit 2 = 0), and the 'anti-tamper' has not been activated (bit 0 = 0)

Byte 3 - 0xXX

This is the 'Frame ID' - counting up for 0x40, to 0x5F then looping ?

Byte 4 - 0xXX

Checksum.

I'd do three things to test this theory:


Run the battery down a lot and see if the battery power indicator changes (byte 2, bit 2).
Open the case and see if the 'anti-tamper' bit changes (byte 2, bit 0)
Do sufficient switching to determine if byte 3 loops around as expected.


This these don't work out then you're likely looking at a different model.