egold555
Notes on H61F6 Strip Light 2 Pro
This is a 10 m, 20 segment RGBWW strip.
The 33 01 00/01 works for power
RGB color is 33 05 15 01 rr gg bb 00 00 00 00 00 ff ff ff (the three ff discussed later)
K color is 33 05 15 01 00 00 00 kh kl 00 00 00 ff ff ff kh -- high byte of 16-bit int kl -- low byte of 16-bit int Visually, it responds to a range of 2000 and up. The app allows a range of 2700-6500. I didn't explore the upper range visually.
The trailing ff ff ff bytes are a bitmap of which segments to change. The first byte is segments 1-8, numbered from the controller, the second byte is 9-16, and the third is confirmed 17-20 and likely through 24 if there are any such products. The lsb is the segment closest to the controller in the group.
The typical brightness control, 33 04 xx, seems to work for "scenes" with a range of 0-100. Values over 100 did not seem to visually impact the brightness. I haven't `scoped the data line. When used with RGB or K colors, it seems to only impact segments 17-20. I have not stumbled on a brightness control method that works with color-based control.
Here are my notes from poking at the strip that may illustrate the segment selection
10 segments (5 m) of H61F6 connected at this point
send 33 05 15 01 ff ff ff 0b b8 00 00 00 ff 74 -- sets CCT on first 8
send 33 05 15 01 ff ff ff 0b b8 ff ff 00 ff ff -- sets CCT on first 10 (only 5 m connected)
send 33 05 15 01 ff ff ff 0b b8 00 00 00 ff ff -- also sets first 10
send 33 05 15 01 ff ff ff 0b b8 00 00 00 00 00 -- didn't change any in first 10
send 33 05 15 01 ff ff ff 0b b8 00 00 00 00 01 -- changed second to last (9th) segment
send 33 05 15 01 ff ff ff 0b b8 00 00 00 00 02 -- changed 10th segment
send 33 05 15 01 ff ff ff 0b b8 00 00 00 01 00 -- changed 1st segment
send 33 05 15 01 ff ff ff 0b b8 00 00 00 02 00 -- changed second segment
send 33 05 15 01 ff ff ff 0b b8 00 00 00 0f 00 -- changes first four segments
send 33 05 15 01 ff ff ff 0b b8 00 00 00 0f f0 -- also changes first four segments
send 33 05 15 01 ff ff ff 0b b8 00 00 00 1f 00 -- changes first five segments
send 33 05 15 01 ff ff ff 0b b8 00 00 00 fe 00 -- changes 2-8
send 33 05 15 01 ff ff ff 0b b8 00 00 00 fe 03 -- changes 2-10
Connected second 5m, 4 segments not responding
send 33 05 15 01 ff ff ff 0b b8 00 00 00 ff ff -- confirmed 16 segments change
send 33 05 15 01 ff ff ff 0b b8 00 00 0f ff ff -- still only 16 change
send 33 05 15 01 ff ff ff 0b b8 00 00 ff ff ff -- still only 16 change
send 33 05 15 02 ff ff ff 0b b8 00 00 ff ff ff -- no change
send 33 05 15 01 ff ff ff 0b b8 ff ff ff ff ff -- only 16 change
send 33 05 15 02 ff ff ff 0b b8 ff ff ff ff ff -- no change
send 33 05 15 01 ff ff ff 0b b8 00 00 00 ff ff ff -- all 20 changed
send 33 05 15 01 ff ff ff 0b b8 00 00 00 ff ff 0f -- all 20 changed
send 33 05 15 01 ff ff ff 0b b8 00 00 00 ff ff 01 -- 16 + next changed
Edit:
Looking at PacketLogger captures in Wireshark, I don't recognize the "expected" packets from the iOS app installed on an iPad. For example, every two seconds I see
0000 4e 00 1b 00 17 00 04 00 52 16 00 c5 8d 98 ce 2f 0010 3c 4a 3e a7 49 77 15 c1 26 cd e7 54 4e 3b 10
which doesn't look anything like the 0xaa keep alive packet described for other devices. At least as I understand the Bluetooth packet, the data starts after the opcode and handle (52 16 00).
Wireshark filtering on (btatt.opcode == 0x52) && (btatt.value[0] == 0x33) didn't show any packets.
I'll hopefully see something more when I get my nRF52840 Dongle capturing from the app.
Edit: The on/off sequence captured off the air from the app seems to be three packets for each transition. They don't seem to be obvious in meaning. Values shown below in case this spurs an idea
Off:
e54dc9bb05018d4c8850716dfe3039fcd98f9003
1d5e01384fd2c9fd24c72ccd760dd43e3d0ba4ba
d00eabe04bab7f619fdee6d402752fd841ce015f
On:
5236d4ff8c54d351c3baa90d3e855b315c653ccd
b62f5e06123875af21e241ab6c21bd7c900a825b
421cdb139ed4fc1a194e9696d5f894e5d253f766
Off:
35b6cb666ce80dab7eae876a46166cd96c634a53
e0b7ee153039d43f671c2dfdf98ce05332bda31d
38f974955ecacd2c3faf972908c4a0399b464bf8
On:
837004d2e2443202a858be83d4f232131e1aa398
c9d94df9d0fee29caff97b315d12bce224013c26
89d3dbb4e30a2dbf0d1c5db6042dce9e66fc2d79
@jeffsf do you think this would mean some kind of encryption? I'm seeing similar command payloads for ON and OFF - entirely different each time - on the H60A1 (Round indoor down RGBWW light)
