New milight bulb - different protocol

[woodster]

Hi there,

I have just bought a new MiLight bulb, that supports both color and warm/cold white.
http://www.aliexpress.com/item/Tanbaby- ... 33965.html

The problem is, that it uses a new remote and protocol.
So far I have found the sync words and channels, and also found some of the sent frames. Now it looks like 9bytes are used, but it also looks like the frame is being encrypted.

Syncword:0x1809000000007236 -> Sync0 = 0x7236, Sync3 = 0x1809
Channels used:70,39,8
Same repeat pattern as the old protocol is used - channel hopping acound 130 times in total.


Are there any, that can find a pattern in the frames below - they have been sent in the order, they are listed?
Taking the old protocol into account that used a frame-id, it seems this one is using a random id instead, that might be used for encryption/decryption.


Group 1, on

Frame: 0xff 0xed 0xc3 0xac 0xa3 0x81 0x60 0xb7 0x6d

Frame: 0xef 0xfd 0x93 0xdc 0x73 0x51 0x73 0x87 0x6c

Frame: 0xf1 0xc6 0x4d 0x16 0x89 0x68 0x0e 0x8a 0x2a

Frame: 0xe0 0xfb 0xc0 0x13 0x46 0xb1 0x28 0x46 0x97


Group 1, off

Frame: 0x64 0x6f 0x34 0xa7 0xba 0x26 0xbd 0xba 0x71

Frame: 0x17 0xd5 0x6b 0x94 0x4b 0x30 0x2f 0x5f 0x97

Frame: 0x7d 0x32 0xf9 0x62 0x35 0x17 0x5e 0x36 0x89

Frame: 0x1b 0xd9 0x6f 0x98 0x4f 0x2c 0x2d 0x63 0x91

[pietromoscetta]

Hi Wood,

thank you for the news.
How did you find the new sync words and radio channels?
Did you analyze the SPI transmission between the micro and the PL1167 with a protocol analyzer?
We will try to buy a couple of new units and make some test.

Ciao,

Pietro

[woodster]

Hi Pietro,

Yep, I monitored the spi to the PL1167.
The uC in the remote has had its ID/type either sanded off or painted over, so can't tell anything about it.

Then I used the modified milight library with the right settings as a scanner to pick up the frames.

But I can't find the pattern in the frame. I would think that one or two bytes are random used as a frame ID, but also used for the encryption.

[pietromoscetta]

Hi Wood,

is the new remote (in some way) compatible with previous MiLight med bulbs?
Do you have any possibilities to test it?

P.

[woodster]

Hi Petro,

No - it uses a different syncword and different channels, so can't see how it should work.
The frame length is also longer, and the remote has more buttons/functions.

I think the protocol is based on the "old" protocol, but it seems to be "encrypted" - if i press the same button several times, the frames changes completely, instead of the old one, where the frame id just got incremented.
The reason why I think it is more or less like the old protocol, is how the frames are being retransmitted, and because it is still one-way.

So I think the bulb either uses a "decryption" function, or uses one of the random bytes as a key to decrypt the frame.

Looking forward to see if you can find the "key" to decrypt the messages.

Martin

[pietromoscetta]

Ok Martin,

thanks for the clarifications.
It sounds strange to me that they use encrypt to send their commands.
By the way never say never.
I'll make some test when I'll have one unit in my hands.

Pietro

[woodster]

Hi Pietro,

any progress regarding the new bulb/protocol?

I have been in contact with Futlight - which manufactures the bulbs I think - but they say they cannot tell anything about the protocol, as it is a private protocol.... doh.

I hope you can see some pattern in the frames.
Martin

[pietromoscetta]

Martin,

unfortunately I was been traveling in China to close some agreements.
I hope that my guys ordered a couple of new units from Futlight (yes they are the manufacturer for MiLight and LimitlessLed) to make some test.
Will come back to you ASAP.

Regards,

Pietro

[woodster]

Hi Pietro,

I know these bulbs are a bit out of your company area, but you seem to share the same interest in combining different things together to achieve a higher level of automation.

By the way excellent service from you ; )

Have a nice day/weekend
Martin

[woodster]

Hi Pietro,

I have looked further into the data being sent - and it seems there is a pattern as long as the first byte (index 0) is the same.

The following frames has been picked up when pressing on channel 1 on a LOT of times.
It still seems to be scrambled somehow - but it looks like the bytes at index 6 and eight are the only ones changing when the byte at index 0 is the same. So when looking at the old protocol, these bytes might be the "frameID".

As it is still oneway - and the bulb learns the remoteID when using different remotes, then the "key" has to be sent in the frame.

A long press also changes another byte, index 4, and that is also a bit like the old protocol.

0xb1 0x06 0x8d 0x56 0xc9 0xa8 0xcd 0xca 0xa9
0xb1 0x06 0x8d 0x56 0xc9 0xa8 0xcb 0xca 0xa7
0xb1 0x06 0x8d 0x56 0xc9 0xa8 0xff 0xca 0x4b
0xb1 0x06 0x8d 0x56 0xc9 0xa8 0xea 0xca 0x46
0xb1 0x06 0x8d 0x56 0xc9 0xa8 0xdb 0xca 0x37
0xb1 0x06 0x8d 0x56 0x49 0xa8 0x42 0xca 0x9e long press / repeat


0xb3 0x41 0xd7 0x20 0x37 0x95 0xf0 0xcb 0x31

0xb4 0x1f 0x24 0x37 0xaa 0x15 0xf3 0xaa 0xfe
0xb4 0x1f 0x24 0x37 0xaa 0x15 0x30 0xaa 0x33
0xb4 0x1f 0x24 0x37 0xaa 0x15 0xdc 0xaa 0xef
0xb4 0x1f 0x24 0x37 0xaa 0x15 0xb6 0xaa 0xc1
0xb4 0x1f 0x24 0x37 0xaa 0x15 0xac 0xaa 0xbf

Any ideas?
Martin