FUT035 CCT LED Controller Issue

[joshdinsdale]

So i have one FUT035 paired with button 2 on a remote, i can sniff this as follows:

cct packet received (4 bytes): Request type : 5A Device ID : 2621 b1 : 02 b2 : 0D b3 : 1D Sequence Num. : D4

Which turns the light on.

If i then try and emulate this with Web interface i get this:

cct packet received (4 bytes): Request type : 5A Device ID : 2621 b1 : 02 b2 : 0D b3 : 0E Sequence Num. : 0E

But the light doesnt respond.

I have an older model CCT LED controller (no model designation) that works perfectly, so it would seem that the FUT035 is ignoring the packets/not responding to the protocol.

Let me know if you need any more information, im sure i can probably compile with debug flags if necessary.

[sidoh]

Thanks, Josh.

This just occurred to me -- could you try restarting the LED controller and sending a command from the ESP without first sending one from the remote? Wondering if it's using b3 as a sequence, and ignoring values that are too close to the last packet ID.

If not I think verifying that raw packets sent from the ESP would be the next most useful debugging step.

[joshdinsdale]

Hi

Tried restarting and sending first command from the ESP, no dice im afraid. I've also had a go at sending raw packets, but having much success with that either. That said, i cant even get the working LED controller to turn on that way either, so I'm probably doing something wrong.

I've tried:

curl -vvv -X PUT -d '{"packet":"5A 26 21 03 07 52 04","num_repeats":50}' 192.168.7.171

but this gives me a 404, I then tried:

curl -vvv -X POST -d '{"packet":"5A 26 21 03 07 52 04","num_repeats":50}' 192.168.7.171/raw_commands/cct

The second one seems to adhere to the instructions on the git readme and i get 200 with this, however the light doesnt switch on.

[sidoh]

The second example is the correct usage. Does the packet you'd expect show up in sniffed packets? Try increasing the value of the last packet (i.e., 04 -> 05).

If you do the following

1. You can send a packet to the controller via a remote and intercept said packet
2. You reboot the controller
3. You send the same packet via the ESP after the controller reboots

and the controller is still not responding, then something very screwy is going on.

[joshdinsdale]

Hi Chris

OK so I've followed your instructions carefully and i am now able to operate the known working LED controller via the API, however I am having no such luck with the FUT035 using the same process as outlined above. They show up identically to the remote if i turn packet sniffing on but just have no effect on the LED controller, very weird!

[sidoh]

Do you happen to know the model number for the remote you're using?

[joshdinsdale]

There are no identifying numbers on the remotes casing, it just says 2.g RF on the front and led logic on the back. It's definitely a cct version of some sort due to the button configuration. I will attempt to crack it open and see if it says anything on the circuit board.

[garmck]

@joshdinsdale are you able to get it working by using rgb_cct ?

[sidoh]

Good call, @garmck. I think the newer CCT remotes use the same protocol as FUT092 (RGB+CCT). There's some relevant discussion in #16.

It's sort of curious that the packets @joshdinsdale is seeing while sniffing are CCT packets, but perhaps the remote sends both types of packets, but FUT035 only responds to the newer ones?

In any case, trying RGB+CCT (instead of CCT) sounds like the right thing to try at this point.

[garmck]

@sidoh @joshdinsdale I had the same issue with the official Milight V6 gateway. Using the MiLight app I had to use the RGB CCT remote in the app in order to get it to work, when using the apps CCT remote, nothing would happen.

[joshdinsdale]

So do i send the same packet detail but just send it to the rgb_cct url?

[sidoh]

No, rgb+cct has a different protocol structure. Probably easiest to just try selecting RGB+CCT in the UI.

[joshdinsdale]

Hi Chris

Yeah I've tried that already, no dice...

[joshdinsdale]

ok so heres another development. I've just tried sending some packets to the All Lights address for CCT and I've managed to turn off the FUT65, but weirdly it didnt turn off the working CCT controller! However i cant use the all lights packet to turn either back on.

Something is totally f*%$ed up here! :D LOL

[joshdinsdale]

Just repeated the same operation and can confim that sending:

curl -vvv -X POST -d '{"packet":"5A 26 21 00 09 67 18","num_repeats":10}' 192.168.7.171/raw_commands/cct (All Lights command)

Turns off the FUT35 but not the known working controller!

Also, if i use the all lights command via the web gui, it does nothing for either controller when sending an on or off command. :S

[sidoh]

Can you spam buttons on your remote and see if anything that's not CCT shows up in sniffed packets? If nothing is, try requesting this URL:

http://milight-hub.local/gateway_traffic/rgb_cct

and spamming the remote a bit. If the request just hangs just cancel/close.

ok so heres another development. I've just tried sending some packets to the All Lights address for CCT and I've managed to turn off the FUT65, but weirdly it didnt turn off the working CCT controller! However i cant use the all lights packet to turn either back on.

FUT035, not FUT065, right?

curl -vvv -X POST -d '{"packet":"5A 26 21 00 09 67 18","num_repeats":10}' 192.168.7.171/raw_commands/cct (All Lights command)

10 repeats is probably too few. Bulbs are probably going to miss commands and it'll make it confusing to keep track of what's working and what's not. I'd keep it at 50 or more, especially while trying to figure out what's going on.

Are you changing the value of the last byte when sending raw commands?

What group are you using on the remote? From your packet captures it looks like both 2 and 3?

[joshdinsdale]

Hi Chris

The spamming doesnt seem to raise anything significant, i certainly dont see any cct_rgw packets, requesting http://182.168.7.171/gateway_traffic/rgb_cct doesnt see any packets either. I've tied all of the buttons on the remote.

i will fiddle with upping the repeats tomorrow, but im fairly sure its not going to make much of a difference, as the stuff that does work is repeatable 100% of the time with 10 retries.

Yes I am changing the last byte value, either that or rebooting the device and using the same value again if u see what i mean?

I am using 3 groups on the remote for 3 LED controllers, group 1 is the known working controller and groups 2 and 3 are the two FUT035's (Yes I meant FUT035's before) :D Obviously except when im using the all lights command (is that called group 0?).

Regards

Josh

[sidoh]

Alright. If your FUT035s are responding to group 0 (yes, that's the "all" group) commands sent from the ESP, it means they're using the same RF config that the ESP is. So we can rule that out that sort of funny business.

i will fiddle with upping the repeats tomorrow, but im fairly sure its not going to make much of a difference, as the stuff that does work is repeatable 100% of the time with 10 retries.

Fair enough. Shouldn't matter as long as you can be super sure that the controller isn't responding due to missed packets.

I am using 3 groups on the remote for 3 LED controllers, group 1 is the known working controller and groups 2 and 3 are the two FUT035's (Yes I meant FUT035's before) :D Obviously except when im using the all lights command (is that called group 0?).

And sending the raw packet produced by the remote when controlling group 3 doesn't work? This doesn't make any sense to me. :/

Might be helpful to get a sample of 10-20 packets from the remote.

I ordered a FUT035 a few days ago, so will hopefully be able to reproduce.

Another thing to try - unpair the controller with the remote, and try pairing with the ESP using the RGB+CCT protocol. I'm pretty sure FUT035 is supposed to work with the FUT092 (RGB+CCT) remote, or at least a remote with a very similar protocol.

[joshdinsdale]

Hi Chris, I will try the pairing process when I get home later but I'm not holding out much hope!

Really appreciate your help with this. Do you have any way of accepting donations towards your work on this project? Even if it's just to cover the cost of the FUT035 or just a beer or two! 😀

[joshdinsdale]

Right I've made some serious progress! Tried to link on of the FUT035's to the ESP using CCT and RGB+CCT and that didnt work. However I then unpaired from the remote and then tried again and it paired using RGB+CCT! I Sent the commands using the same ID as the remote, however the remote didnt work, so i then manually repaired to the remote and I can now operate the FUT035 from the ESP and the Remote. Commands from the ESP are sent using RGB+CCT and commands from the remote are sent via CCT (I have confirmed this via packet capture), go figure!

Anyway, after all of this I've now taken a massive step backwards! I think I may have somehow broken the FUT035. I accidentally send the white command from the ESP web interface, the led strip briefly flashed and then went off and now i cant get it to turn back on via the remote or ESP! I initially thought id broken the led strip, however if i plug the strip direct to the DC adapter it works.

Does anyone know if this is a known thing?

[joshdinsdale]

OK So tried the same process o the other FUT035 and cant make it work on that one, just doesnt respond to the pairing request at all, on CCT or RGB+CCT. Its totally nuts.

[sidoh]

Really appreciate your thoughtfulness, but this project is just for fun.

Huh, interesting.

It really sounds like you've got some bad/malfunctioning hardware. Given that the remote works, I'd suspect the nRF24L01. Do you have others you can try? It seems like 10-20% of the ones I have are next to useless.

[khmann]

I ordered a FUT035 a few days ago, so will hopefully be able to reproduce.

I think the problem is you use the wrong packet length for DualWhite. In the past I wrote some code based on your CCT implementation. I noticed that you use a length of 7 (was it? I forget...), that there was a completely "undefined" byte after sequence, but as long as the CRC worked the DualWhite bulbs would accept either your length or a length one smaller.

Probably the "new" dual-white controller firmware (Protocol 5A and 21) is more picky.

[joshdinsdale]

Hi, I will try another nrf, ive got loads knocking about from some of my 'mysensors' projects. As you say, I've had a hell of a lot of trouble with the NRF's myself so I dont know which of mine are good or bad (apart from the ones i have in use and i dont really want to mess about with those).

I will try soldering a cap across as well see if that helps, I've had mixed results with that as well!.

Any idea on the FUT035 that i seem to have broken? That's really weird, i cant see how its possible to brick it via remote packets, but then again I've seen stranger things in my IT Support career! :D

[sidoh]

I think the problem is you use the wrong packet length for DualWhite. In the past I wrote some code based on your CCT implementation. I noticed that you use a length of 7 (was it? I forget...), that there was a completely "undefined" byte after sequence, but as long as the CRC worked the DualWhite bulbs would accept either your length or a length one smaller.

Yes, as far as I've been able to tell CCT packets are length 7. Is that not consistent with your observations?

Any idea on the FUT035 that i seem to have broken? That's really weird, i cant see how its possible to brick it via remote packets, but then again I've seen stranger things in my IT Support career! :D

I'm not sure offhand. Perhaps try sending color or white temp from the ESP?

[joshdinsdale]

Hmm, so fuxing about with the white temp slider from the esp has sorted it! (Its just a basic 2-wire white strip). I'm getting weird behavior with how it functions after a reboot. If the FUT035 is On and light is on, if i reboot it, the light turns back on automatically. If i screw it up by sending it the white command, if i then reboot it, it doesnt turn back on automatically and I have to fux with the white temp to bring it back. Weird or what?

[sidoh]

I think FUT035 is a dual-white controller. "Set White" for RGB+CCT sets the color temperature to the coolest value, which I'm guessing directs the controller to turn off the WW line and max the duty cycle for the CW line.

[joshdinsdale]

Ah I see, that makes 100% sense 😀

[garmck]

ok, I have setup my Milight V6 gateway and paired using the milight app (iOS) I have paired FUT035 with the FUT005, FUT006 and FUT007 app remotes and CCT works as expected. Now the ESP is not controlling the FUT035 either CCT or RGB_CCT ESP: cct packet received (4 bytes): Request type : 5A Device ID : 06FD b1 : 01 b2 : 08 b3 : 2B Sequence Num. : 2B cct packet received (4 bytes): Request type : 5A Device ID : 06FD b1 : 01 b2 : 0B b3 : 2A Sequence Num. : 2A

MiLight App: cct packet received (4 bytes): Request type : 5A Device ID : 06FD b1 : 01 b2 : 0B b3 : 61 Sequence Num. : D1 cct packet received (4 bytes): Request type : 5A Device ID : 06FD b1 : 01 b2 : 08 b3 : 60 Sequence Num. : CD

If you need me to do anything specific, let me know.

[garmck]

@sidoh interestingly, I have unpaired the FUT035 and paired via MiLight App using the FUT092 app remote this time and RGB_CCT via ESP works 100%

[khmann]

Yes, as far as I've been able to tell CCT packets are length 7. Is that not consistent with your observations?

My dual white bulbs support omitting your second sequence number and work the same, so I think maybe it's not "supposed" to be there. (I don't have any remotes for them or a wifi box yet so I have nothing to sniff)

That's the only thing I can think would account for the packet appearing otherwise "normal": He's got new 2016/2017 firmware controllers and they've gotten stricter about the protocol 5A (because they also now support protocol 21 derivatives).

I've got an LS2 on order myself, though I know that's a slightly different animal...

[khmann]

My dual white bulbs support omitting your second sequence number and work the same, so I think maybe it's not "supposed" to be there.

Uh, aparantly I was drunk because I'm unable to reproduce this.

[sidoh]

Interesting. I suppose it'd be a little surprising because I think there's a packet length byte that indicates there should be 7 bytes. Not sure if that byte is in the payload or whatever wraps it, but I think it's the byte right before the raw packet.

I still think you're right about the newer controllers being stricter about the protocol. I'm guessing that maybe one of the last two bytes is a checksum or something along those lines.

[joshdinsdale]

So I've come back to this after a week away and its inexplicably working! No idea what has changed (i anything), however the FUT035's are working via RGB_CCT. The only issue I have now is making this work in Domoticz, their implementation doesn't appear to support RGB_CCT.

[Erriez]

This problem is probably related to an incorrect CCT checksum. See my merge request #182 with a fix.

[sidoh]

Should be fixed in 1.6.3 thanks to @Erriez!

https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.6.3