New milight bulb - different protocol

[pietromoscetta]

Hi Martin,

I'm so sorry but it is a very busy time for me.
The new bulbs from Futlight are on the way so I'll come back after some test of my guys.
I'm quite sure the protocol should be very similar to the previous because I know how chinese use to manage this stuff.
The only thing I don't understand is if you sniffed the SPI communication through the PL1167 or just some commands.
Most probably they also changed the 4 SyncWords on PL1167 so if you don't know them you cannot speak with the new bulbs.
Normally we use an SPI analyzer with probes connected to the remote to capture the full SPI communication between Micro and PL1167.

Hope to come back you asap.

Pietro

[woodster]

Hi Pietro,

I used a spi analyzer between the micro and the PL1167, see first post for sync word and channels used.
It uses the same amount of repeats and channel hops, but the frames changes.

As the previous post startes there is a pattern if the first byte is the same.

Don't get stressed, I appreciate your assistance.
Martin

[krulkip]

I have modified the openmili software from Henryk to work on the new protocol.
This allows me to read the packets in the same way woodster has done without the need to solder anything.
I used the nRF24L01 wireless transmitter attached to an arduino.
I can confirm that the channels used are indeed 8, 39 and 70 and that 9 bytes are used.
Also the syncword of 0x72361809 worked for me.
The CRC is also calculated in the same way as before with of course the two extra bytes taken into account.
I also found the output bytes to be scrambled and have not managed to resolve this so far.
Looking at a lot of key presses i did discover some patterns.
The LS nibble seems to be the same for bytes 0,1,2,3,4,5 and 7 irrespective of the MS nibble for most key presses.
As only bytes 6 and 8 change when the rest are identical these must contain the indexing and encryption part.
Here is an example.
B0 2B F0 61 76 DD 39 75 31
B0 2B F0 61 76 DD E4 75 F0
By comparing the fixed nibbles when pressing different buttons you also notice that only one nibble changes which must then refer to the key button number.
So when the second nibble is zero the second nibble in the 5th byte is as follows:
on 4, off 1,
group 1 off 2, group 2 off 3, group 3 off C, group 4 off D,
group 1 on 5, group 2 on 6, group 3 on 7, group 4 on 0,
S+ E, S- F,
Not clear how the other buttons work but lower nibble of previous byte 4 is involved.
I also can confirm woodsters findings on the high bit on byte 4 being impacted at long key presses. ie clear when active.
I looked to see if there was any logic in bytes 6 and 8 regarding increments but could not find it.
Also could not find logic connecting bytes 6 and 8 and either nibble.
Enclosed a file with some output.
Hope someone can find a solution.

[woodster]

Hi Pietro,

I just found this info:
https://github.com/moosd/ReverseEnginee ... tBluetooth

I know it is for a bluetooth bulb, but I think they might use a similar method for the new bulb.
They use the first byte as a key, and then perform some additions plus multiply, and finally a crc calculation for the last byte.

What do you think?
Martin

[pietromoscetta]

Hi Martin,

I just realized that one post (the one from Krulkip) has been lost in the approval queue.
I apologize with Krulkip but sometime this happen with the big quantity of spamming incoming every day.
Still need to read carefully both messages so I'll be back ASAP.
Regarding the new Mi-Light bulbs I'm expecting a couple of them within this week so we can work on them (also here long delay).

Pietro

[woodster]

Hi Krulkip and Pietro,

I think byte 0 is part of the scramble key, and byte 6 is the frame ID, and byte 8 is a crc.

Krulkip: the crc you mention is used as part of the RF driver I think, and is used due to the nrf24l01. I don't think it is part of the milight protocol.

I have ordered another remote, and when it arrives I should be able to tell which bytes are used as the remote Id.

[woodster]

Hi Krulkip,

If you could capture a ch1 on, that starts with 0xb1 then we should be able to tell the remote Id.

E. G.
0xb1 0x06 0x8d 0x56 0xc9 0xa8 0xcb 0xca 0xa7

[krulkip]

On holiday at the moment without my toys.
@Pietro: I enclosed an excel file with many data captures. Maybe this would be useful to others to help.
@woodster I will try to capture a oxb1.
In my observations the on signal can be many values as explained in previous post.
I would expect the device ID will be 2 bytes long (minimum) and that there would be a a counter maintaining repeat transmits.
Are you referring to this counter as the packet ID. The repeat transmits should be the same decoded except this packet ID and maybe because of that also the key.
The interesting part of the transmission which a PL1167 transmits starts with the length and ends with a two byte CRC.
It is this CRC i referred to and matches the old bulb protocol. In between are the 9 bytes with the actual code.
It would not be needed for this 9 byte sequence to contain another CRC. The nRF24L01 simply emulates the PL1167 and also reads/transmits these bytes.

[pietromoscetta]

Hi Krulkip,

I cannot find your excel file.
Can you please double check if something is not working when you post it on the forum?
In a few days I would be able to play with new remote and new mi-light bulbs so to be aligned with you.

Pietro

[woodster]

@Krulkip:

I think the 2byte crc is handled by the be PL1167 as a hardware setup, and this validates the transmission of data, but not the content of the frame. When using the nrf24l01 the crc has to be handled by software hence the extra bytes. This crc is part of the transmission, but isn't part of the milight protocol I think.