Added support for RGB remote FUT098!

[itProfi]

I have remote FUT098 for controller for RGB LED strips - http://futlight.com/productdetails.aspx?id=175&typeid=143 Where i can put config for it (i sniff SPI analizer) ? SYNC_WORD Data length is 6 byte, it's not scrambled.

const uint8_t RGB_CHANNELS[] = {3, 38, 73}; static MiLightRadioConfig MilightRgbConfig( 0x9AAB, 0xBCCD, 6, RGBCCT_CHANNELS, 3, new RgbCctPacketFormatter(6), RGB_CCT);

[sidoh]

That's mostly right. You'd need to add a new type and not reuse RGB_CCT. Are the packets 6 bytes long? Is it different than the RGBW protocol?

[itProfi]

I analyze it's and put into table, like henrik It's has 6 byte in packets long Data was after point 0,7 ms and long was 6 byte

[sidoh]

Ah okay. That's a different kind of protocol than the other three I've reversed. We'd need to figure out the structure and write a PacketFormatter for it as well.

[itProfi]

A you help me with it? :)

[sidoh]

Yeah, I can poke at it. I think I wanna wrap up support for the RGB+CCT bulbs first, though.

[sidoh]

Added to the new_protocol branch. Looks to be working in that it's receiving and sending packets that appear to be correctly formatted. Not sure if I got the brightness stuff right. It has up/down commands instead of a direct value, so I just copied what the CCT protocol did.

Can you test it out?

[itProfi]

It's amazing! Hi Chris! It's decode and descramble work!!!!! This is my index page - this is 1 packet on phisical remote this is 2 packet on phisical remote But when i try control via RGB+CCT mode with any device ID's nothing happens...I try use like 2 id's of my own remotes and any virtual ID's..When i try pair it with lamps n othing happens....(( Is LED on NodeMCU be blink or no when library send packets, like when it's receive it? FUT091_RAW_PACKETS.xlsx

[sidoh]

I meant to say that RGB (FUT098) should work, not v2 CCT (FUT091 - that's #16).

I'll need to make some changes to make FUT091 work.

[itProfi]

Ups..my mistake! (for RGB FU098)..It's amazing decode, but not contorl led controller (with my phisical remote ID and virtual ID - not pair)..I try many times with correct mode (RGB) send.

You right about brightness - only step UP and DOWN.. Next Button (S) - UP and DOWN (Speed of effect) Next Button (M) - UP and DOWN (Switching of 30 effects in a circle)

[sidoh]

Gotcha. Can you paste a few packet captures from your remote?

[itProfi]

FUT_098_packets.xlsx

[sidoh]

Are you able to control the strip if you give the ESP the same ID as your remote and skip pairing? I bet the pair command is different with this remote.

[itProfi]

Unfortunately, i try 0x3CDA, like of my remote...nothing.. I use this module 1100-meter long-distance NRF24L01

[sidoh]

Hmm, I'm having a hard time understanding why this would happen. I can see that the packets getting sent are what I intend for them to be on another ESP.

Do you happen to have another ESP/NRF24L01 you could set up to listen to the original one? Might be good to verify that the packets are being received by it.

[itProfi]

Ok , i try this tomorrow..In my city is GMT+3...

[itProfi]

Hello, Chris! New experiments with you new release 1.0.0.: Screen from my phisical remote: Screen from virtual remote (other ESP with same remote ID):

1. As I understand it, no color code is transmitted
2. As you wrote: "It has up/down commands instead of a direct value, so I just copied what the CCT protocol did" .
3. Whether it is possible to replace in the RGB mode the brightness slider on the brightness buttons + and - ?
4. Whether it is possible to create on web interface new 4 buttons: Speed + and - , Mode + and - ?
5. Is it normally, when I send first command from ESP, internal LED lights up and never goes out?

[sidoh]

Mm, yeah. Looks like the one from the remote is persisting the color code across commands. Maybe that's it. I'll check in the morning.

The slider should still work as expected. It sets brightness to minimum by sending 10x down commands, then presses up a number of times proportional to the value of the slider.

Adding buttons makes sense. Haven't actually added support mode at all yet.

This happens on one of my nodemcus as well. Think the LED is tied to D0 (GPIO 16). You can try using a different pin.

[itProfi]

Chris! It's work! Amazing! You wrote: "The slider should still work as expected. It sets brightness to minimum by sending 10x down commands, then presses up a number of times proportional to the value of the slider."

May i ask rebuild this mehanism of brightness: it's vissualy not gracefully :) ?

"Mm, yeah. Looks like the one from the remote is persisting the color code across commands. Maybe that's it. I'll check in the morning."

It's not working (send only 00 color).

About remote code matching (pair): after swith power led on (within 3 sec) must press once pair button. For code clearing after swith power led on (within 3 sec) must press TWICE unpair button.

Sniffing Speed + and Speed - command:

Packet received (6 bytes): b0 : A4 ID : 3CDA Color : ED Command : 06 (speed -) Sequence : 1D

Packet received (6 bytes): b0 : A4 ID : 3CDA Color : ED Command : 05 (speed +) Sequence : 1C

Sniffing Mode + and Mode - command:

Packet received (6 bytes): b0 : A4 ID : 3CDA Color : ED Command : 08 (Mode -) Sequence : 22

Packet received (6 bytes): b0 : A4 ID : 3CDA Color : ED Command : 07 (Mode +) Sequence : 21

As variant, but i not profi in HTML :)

[itProfi]

Are you plan support this (RGB) command in UDP server?

enum MiLightRgbButton { RGB_OFF = 0x01, RGB_ON = 0x02, RGB_BRIGHTNESS_UP = 0x03, RGB_BRIGHTNESS_DOWN = 0x04, RGB_SPEED_UP = 0x05, RGB_SPEED_DOWN = 0x06, RGB_MODE_UP = 0x07, RGB_MODE_DOWN = 0x08, RGB_PAIR = RGB_SPEED_UP }; And if yes, what commands wiil be set for udp?

[sidoh]

I'm not clear on what's working. Are any commands working? It sounds like you're either saying that nothing is working, or it's behaving weirdly because color is not being retransmitted.

May i ask rebuild this mehanism of brightness: it's vissualy not gracefully :) ?

Yeah, it's fair. I think it's important to have the "set brightness" feature for all bulbs, because it's really useful for home automation purposes (e.g., having routines that dim all lights), but that doesn't mean the UI needs to work that way. Honestly I don't really use the UI, so I've not spent very much time on it.

About remote code matching (pair): after swith power led on (within 3 sec) must press once pair button. For code clearing after swith power led on (within 3 sec) must press TWICE unpair button.

I think that's what it's doing (it re-transmits to make it less likely that the bulb misses the packet):

void RgbPacketFormatter::pair() { 
  for (size_t i = 0; i < 5; i++) {
    command(RGB_SPEED_UP, 0);
  }
}

void RgbPacketFormatter::unpair() { 
  for (size_t i = 0; i < 5; i++) {
    command(RGB_SPEED_UP | 0x10, 0);
  }
}

Yeah, can definitely add support for UDP commands.

[itProfi]

I'm not clear on what's working. Are any commands working? It sounds like you're either saying that nothing is working, or it's behaving weirdly because color is not being retransmitted.

Yes, I probably incorrectly expressed. Again, at the moment: only sending the color code does not work (code 00 is always sent). On, Off, pair, unpair (twice press) work correct. Although the code of the last set color is always sent from the remote (on, off). The color code from the remote is always transmitted .. And with the ECP8266 only 00. Therefore, the color of the controller does not change with the ECP.

I also wanted to remind you about the possibility of adding buttons with speed commands and mode selection, if possible.

Sniffing Speed + and Speed - command:

Packet received (6 bytes): b0 : A4 ID : 3CDA Color : ED Command : 06 (speed -) Sequence : 1D

Packet received (6 bytes): b0 : A4 ID : 3CDA Color : ED Command : 05 (speed +) Sequence : 1C

Sniffing Mode + and Mode - command:

Packet received (6 bytes): b0 : A4 ID : 3CDA Color : ED Command : 08 (Mode -) Sequence : 22

Packet received (6 bytes): b0 : A4 ID : 3CDA Color : ED Command : 07 (Mode +) Sequence : 21

[sidoh]

Again, at the moment: only sending the color code does not work (code 00 is always sent). On, Off, pair, unpair (twice press) work correct. Although the code of the last set color is always sent from the remote (on, off). The color code from the remote is always transmitted .. And with the ECP8266 only 00. Therefore, the color of the controller does not change with the ECP.

Gotcha, I see.

So does selecting a color with the ESP work, but other commands unset it? Or is it just that it never changes color?

I also wanted to remind you about the possibility of adding buttons with speed commands and mode selection, if possible.

Sure, makes sense. There's actually no backend support for these commands right now, so would need to do that in addition to adding buttons to the UI.

[itProfi]

it just that it never changes color?

Yes, it's never changes color. As i understand, alwayes send color code 00.

Although the code of the last set color is always sent from the Mi remote (on, off). The color code from the Mi remote is always transmitted ..

From my ESP: Packet received (6 bytes): b0 : A4 ID : 3CDC Color : 00 Command : 00 Sequence : 0C

Packet received (6 bytes): b0 : A4 ID : 3CDC Color : 00 Command : 00 Sequence : 0B

Packet received (6 bytes): b0 : A4 ID : 3CDC Color : 00 Command : 00 Sequence : 0A

Packet received (6 bytes): b0 : A4 ID : 3CDC Color : 00 Command : 00 Sequence : 09 Color always 00.

[sidoh]

Haha, oops.

Can you see if the change I just made in this branch fixes it?

https://github.com/sidoh/esp8266_milight_hub/tree/fix_rgb

[itProfi]

Can you see if the change I just made in this branch fixes it?

Yes, work!

Sure, makes sense. There's actually no backend support for these commands right now, so would need to do that in addition to adding buttons to the UI.

And if possible buttons, like this: :)

[sidoh]

Can you try the v1.1.0 branch? You'll need to update the web UI as well.

[itProfi]

Yes, all work well! Thank you so much! There remains one petiton on the RGB protocol -

Yeah, can definitely add support for UDP commands.

[sidoh]

I took a stab at it. Added it to the v6 UDP protocol. I sniffed the UDP packets from my milight wifi box.

Should be easy enough to add support for the v5 protocol if you know what the packets look like.

[sidoh]

@Lstt2005 - are you able to test this out? I don't have an RGB device to test with unfortunately. Also HomeAssistant doesn't seem to support RGB.

[itProfi]

Chris! To be honest, I did not understand eight, is there any support for the RBG in the version of the v6 protocol? IF there is, where to look at the description - http://www.limitlessled.com/dev/ ?

[sidoh]

There is support, but it's not documented. I found the codes by sniffing UDP packets from the app on my phone. Do you have a way to test it?

[itProfi]

You mean version 3 - https://play.google.com/store/apps/details?id=com.irainxun.wifilight or versuion 2 - https://play.google.com/store/apps/details?id=com.lierda.wifi ?

[sidoh]

Version 3.

Unfortunately I don't think you can get the app to recognize the ESP right now. That's sort of what #15 is about.

I was under the impression you had something that was using the UDP protocol that you could test with, but sounds like maybe that's not right.

[sidoh]

I don't think the official tools will work with the ESP right now.

The handler code for the RGB commands is here: https://github.com/sidoh/esp8266_milight_hub/blob/v1.1.0/lib/Udp/V6MiLightUdpServer.cpp#L129

It's roughly the same protocol outlined in the docs with a few minor differences. Instead of commands being like this for RGB+CCT bulbs:

31 00 00 08 04 01 00 00 00

They're like this for RGB bulbs:

31 00 00 05 AA BB BB BB BB

Where AA and BB specify a command. AA = 02 is everything but color with BB being one of these things. AA = 01 is the color command with BB being the color.

Could you use the HTTP API instead of UDP? The HTTP API is way easier to use (it's what the UI uses).

[itProfi]

I use this tools - http://www.limitlessled.com/download/LimitlessLEDv6.zip When i try send commands for UDP server v6 - it's work (for my FUT035 LED STRIP CCT port 48899)! In addition, it seems to me that you have in your library confused extreme positions in this mode: FULL_WARM_WHITE and FULL_COLD_WHITE.

When i try send commands for other UDP srver v6 - it's NOT work (for NEW RGB LED controller port 48889)..and i try sniff packet from other ESP - it's nothing found..

[sidoh]

Oh cool, this is a pretty sweet tool.

I've seen conflicting accounts for whether 0x00 should be max or min for white temperature. The way it is now works with HomeAssistant, but it's possible that the HomeAssistant UDP library has it backwards.

In your second screenshot, it looks like the ESP is successfully receiving and responding commands, but you're commands meant for RGB+CCT bulbs. Notice the label "Wifi Bridge v6 - RGBW/WW/CW"

Basically the UDP protocol selects which radio config to use by some of the values in the commands you're sending, and 31 00 00 08 is selecting RGB+CCT. It ought to be 31 00 00 05, and the commands are different (e.g., ON is 31 00 00 05 02 09 00 00 00).

What does "Show Light Commands" do? Does it allow you to select different device types?

[sidoh]

Is there something preventing you from using the HTTP API? You could, for example, just send this HTTP request to control your RGB bulbs (using curl to demonstrate, but it can be anything capable of sending an HTTP request):

curl -vvv -X PUT --data-binary '{"status": "on"}' -H 'Content-Type: application/json' http://<esp>/gateways/0x3CDA/rgb/1

[itProfi]

Chris! With commands, that you Indicated that work with this tools via UDP!! I mean RGB! You are Profi!

[sidoh]

Awesome. Sounds like everything is working as expected, then?

[sidoh]

Here's an example of a client using the HTTP API:

https://github.com/sidoh/ha_gateway/blob/master/drivers/light/esp8266_milight.rb#L60

[itProfi]

Awesome. Sounds like everything is working as expected, then?

Probably yes! Thank you so much!!!

Here's an example of a client using the HTTP API:

Thank, but for me the protocol of the UDP is preferable, as it is more faster .. I just found BiLight application - https://play.google.com/store/apps/details?id=com.jaspergoes.bilight&hl=ru If i set on ESP ID for my CCT FUT035 and 5987 port v6 UDP it's work with my WW/CW (not RGB) lamps! Cool! P.S. Amazing! It has a github repo! - https://github.com/JasperG/bilight

[sidoh]

Really glad to hear it's working! Gotcha - makes sense to use UDP if you're optimizing for latency.

Nice, that looks like a cool project.

Was there anything else you had in mind for this ticket?

[itProfi]

Was there anything else you had in mind for this ticket?

No, i think no for this ticket. Tnanks.

[sidoh]

Sweet :)

Thanks for helping me make this better!