BEKEN iLedBlub

Aus FHEMWiki
Version vom 14. Januar 2018, 12:32 Uhr von AndreasMohr (Diskussion | Beiträge) (Describe MAC ID specifics, misc.)

These are LED lamps E27 with Bluetooth BLE, in variants of RGB color (7W combined), and without (8W main lamp).

Manufacturer/distributor Hama/Xavax.

Product number 00111973 (case marking: 001119730001).

Currently (2018-01-09) sold at http://pollin.de for 4,95 Euro ([1] , [2]).

And, since these are called iLedBlub (sic!), I chose to use the same name for this page.


http://www.instructables.com/id/Reading-Values-From-a-BLE-Device-Using-CSR1010-and/

LabNotes: Reverse Engineering Sex Toys (ermm ;))

# hcitool lescan

[MAC] LED

[MAC] (unknown)


# gattool -I

connnect [MAC]

characteristics

char-read-hnd 0x3

Characteristic value/descriptor: 69 4c 65 64 42 6c 75 62 --> iLedBlub (https://rainerpeffm.wordpress.com/2016/01/18/installation-mit-i-eurolamp-und-brille-%C2%B7-im-eiscafe/)

char-read-hnd 0x5

Characteristic value/descriptor: 03

Characteristic value/descriptor: 00

char-read-hnd 0x7

Characteristic value/descriptor: 64 00 c8 00 00 d0 07

char-read-hnd 0x9

Characteristic value/descriptor: 00

char-read-hnd 0xb

Characteristic value/descriptor: 00 00 00 00 00 00

char-read-hnd 0x12

Characteristic value/descriptor: 42 45 4b 45 4e 00 00 00 00 00 --> BEKEN

(BEKEN likely is http://www.bekencorp.com/en/index.Asp - that page contains text "BK326X is qualified by SIG by Bluetooth", so......)

char-read-hnd 0x14

Characteristic value/descriptor: 42 54 20 34 2e 30 --> BE 4.0

char-read-hnd 0x16

Characteristic value/descriptor: 31 32 78 30 37 78 32 30 31 32 --> 12x07x2012 (probably a default date of a Bluetooth base/reference controller platform?)

char-read-hnd 0x18

Characteristic value/descriptor: 53 4d 2d 31 --> SM-1

char-read-hnd 0x1a

Characteristic value/descriptor: 30 31 2e 31 --> 01.1

char-read-hnd 0x1c

Characteristic value/descriptor: 30 31 2e 31 --> 01.1

char-read-hnd 0x1e

Characteristic value/descriptor: de bc 9a fe ff 56 34 12

char-read-hnd 0x20

Characteristic value/descriptor: 89 ab cd ef

char-read-hnd 0x22

Characteristic value/descriptor: 01 0e 00 12 34 01 67

char-read-hnd 0x25

Characteristic value/descriptor: 00 00 01 00 00 00 00 00 01 ff (this is the power-up value of the data word)

Characteristic value/descriptor: 01 f9 01 00 01 ff 01 f3 01 ff (sample)

Characteristic value/descriptor: 01 00 01 00 01 00 01 63 01 00 (sample)

Characteristic value/descriptor: 00 00 00 00 00 00 00 00 00 00 (this zeroing happens directly at char-write-req 0x28 0x0 - however while usually these values indicate the data word, that 0 result then is NOT equal to the data word: 0 would be OFF, which isn't the case here - hmm...)

char-read-hnd 0x2c (this seems to provide - well, store... - the MAC ID, in reverse)

Characteristic value/descriptor: ZZ YY XX a2 b1 00 (MAC vendor prefix 00:B1:A2; RGB LEDs) Characteristic value/descriptor: ZZ YY XX fa cc 00 (MAC vendor prefix 00:CC:FA; white non-RGB LEDs)

A total of four RGB LEDs and two white LEDs reliably followed this pattern, so I guess that the MAC ID (and unfortunately only that! I haven't found any other characteristic bits differing anywhere) fortunately can be used to programmatically tell apart the different models.

This will provide NOTIFYs (of current settings):

char-write-req 0x28 0x0

Notification handle = 0x0025 value: 00 00 00 00 00 0f 01 ff 01 15 (current setting of the data word)

Notification handle = 0x002c value: 8e 03 f8 a2 b1 00


char-write-req 0x28 e3105811111111 --> max. 7 bytes value allowed

char-write-req 0x2a 112233445566778899aa --> max. 10 bytes value allowed

char-write-req 0x2a

01f9010001ff01f301ff --> IMMEDIATELY WHITE!! (woohoo!!)

00000000000000000000 --> OFF!!

00000000000f01ff0030 --> RED!

0000017001ff01000030 --> BLUE!


data word format

agGG????abBBarRRalLL

aX = activate sub component (value usually: "01")

R = red

G = green

B = blue

L = Brightness

? = unknown


char-write-req 0x28 <any_val>

(or char-write-cmd)

will:

  • provide value NOTIFYs of the writable handles
  • update handle 0x25 to contain the value that has been written to 0x2a (readout done via char-read-hnd 0x25)


https://developer.android.com/reference/android/bluetooth/BluetoothGattCharacteristic.html

characteristics

handle: 0x0002, char properties: 0x08, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb 0x2a00 org.bluetooth.characteristic.gap.device_name

handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb 0x2a01 org.bluetooth.characteristic.gap.appearance

handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb 0x2a04 org.bluetooth.characteristic.gap.peripheral_preferred_connection_parameters

handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002a02-0000-1000-8000-00805f9b34fb 0x2a02 org.bluetooth.characteristic.gap.peripheral_privacy_flag

handle: 0x000a, char properties: 0x02, char value handle: 0x000b, uuid: 00002a03-0000-1000-8000-00805f9b34fb 0x2a03 org.bluetooth.characteristic.gap.reconnection_address

handle: 0x000d, char properties: 0x22, char value handle: 0x000e, uuid: 00002a05-0000-1000-8000-00805f9b34fb 0x2a05 org.bluetooth.characteristic.gatt.service_changed

handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a29-0000-1000-8000-00805f9b34fb 0x2a29 org.bluetooth.characteristic.manufacturer_name_string

handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a24-0000-1000-8000-00805f9b34fb 0x2a24 org.bluetooth.characteristic.model_number_string

handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a25-0000-1000-8000-00805f9b34fb 0x2a25 org.bluetooth.characteristic.serial_number_string

handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a27-0000-1000-8000-00805f9b34fb 0x2a27 org.bluetooth.characteristic.hardware_revision_string

handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a26-0000-1000-8000-00805f9b34fb 0x2a26 org.bluetooth.characteristic.firmware_revision_string

handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a28-0000-1000-8000-00805f9b34fb 0x2a28 org.bluetooth.characteristic.software_revision_string

handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a23-0000-1000-8000-00805f9b34fb 0x2a23 org.bluetooth.characteristic.system_id

handle: 0x001f, char properties: 0x02, char value handle: 0x0020, uuid: 00002a2a-0000-1000-8000-00805f9b34fb 0x2a2a org.bluetooth.characteristic.ieee_11073-20601_regulatory_certification_data_list

handle: 0x0021, char properties: 0x02, char value handle: 0x0022, uuid: 00002a50-0000-1000-8000-00805f9b34fb 0x2a50 org.bluetooth.characteristic.pnp_id

handle: 0x0024, char properties: 0x10, char value handle: 0x0025, uuid: 0000ee01-0000-1000-8000-00805f9b34fb

handle: 0x0027, char properties: 0x0c, char value handle: 0x0028, uuid: 0000ee02-0000-1000-8000-00805f9b34fb

handle: 0x0029, char properties: 0x0c, char value handle: 0x002a, uuid: 0000ee03-0000-1000-8000-00805f9b34fb

handle: 0x002b, char properties: 0x10, char value handle: 0x002c, uuid: 0000ee04-0000-1000-8000-00805f9b34fb

https://www.bluetooth.com/specifications/gatt/characteristics


I managed to figure these access details out relatively easily (~2 hours), without actually doing Bluetooth sniffing. If someone has a Bluetooth sniffing environment easily available, then it would be useful to gather potentially remaining additional commands sent by the XAVAX II app. Or simply infer some additional details by modifying device state via XAVAX II app, and then reconnecting via gatttool and reading out the (now changed) NOTIFY values.


I'm currently working on a FHEM module, taking 74_XiaomiFlowerSens.pm as a reference. I will thus possibly use gattool interfacing (or perhaps interfacing to MQTT, but this would require an extra MQTT provider component), and Color.pm (FHEM's color picker wheel).

Legal disclaimer: no warranties - "if it breaks, then you get to keep both pieces." etc.pp.