BEKEN iLedBlub: Unterschied zwischen den Versionen
K (Add missing hcitool lescan etc.) |
K (cat) |
||
(5 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
These are LED lamps E27 | These are LED lamps E27 with Bluetooth BLE, in variants of RGB color (7W combined), and without (8W main lamp). | ||
Manufacturer/distributor Hama/Xavax. | Manufacturer/distributor Hama/Xavax. | ||
Zeile 61: | Zeile 61: | ||
char-read-hnd 0x16 | char-read-hnd 0x16 | ||
Characteristic value/descriptor: 31 32 78 30 37 78 32 30 31 32 --> 12x07x2012 | 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 | char-read-hnd 0x18 | ||
Zeile 89: | Zeile 89: | ||
char-read-hnd 0x25 | char-read-hnd 0x25 | ||
Characteristic value/descriptor: 01 | 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 | Characteristic value/descriptor: 01 f9 01 00 01 ff 01 f3 01 ff (sample) | ||
Characteristic value/descriptor: 00 00 00 | Characteristic value/descriptor: 01 00 01 00 01 00 01 63 01 00 (sample) | ||
char-read-hnd 0x2c | 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 0x28 e3105811111111 --> max. 7 bytes value allowed | ||
Zeile 118: | Zeile 132: | ||
agGG????abBBarRRalLL | agGG????abBBarRRalLL | ||
aX = activate sub component (value usually: "01") | |||
R = red | R = red | ||
Zeile 126: | Zeile 140: | ||
B = blue | B = blue | ||
L = Brightness | |||
? = unknown | ? = 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) | |||
Zeile 191: | Zeile 215: | ||
I managed to figure these access details out relatively easily, '''without''' actually doing Bluetooth sniffing. | 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. | 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 <code>74_XiaomiFlowerSens.pm</code> 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). | |||
I'm currently working on a FHEM module, taking <code>74_XiaomiFlowerSens.pm</code> 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 <code>Color.pm</code> (FHEM's color picker wheel). | |||
'''Legal disclaimer:''' no warranties - "if it breaks, then you get to keep both pieces." etc.pp. | '''Legal disclaimer:''' no warranties - "if it breaks, then you get to keep both pieces." etc.pp. | ||
[[Kategorie:Lichteffektgeräte]] | |||
[[Kategorie:Bluetooth]] |
Aktuelle Version vom 29. Januar 2018, 12:48 Uhr
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.