Can't pair FUT104 bulb

[quentin-legraverend]

Hi there,

• I have run through the troubleshooting guide.
• I'm using a NodeMCU board (Lolin v3)
• I'm using those RF Modules : https://www.amazon.fr/gp/product/B06XJN417D/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
• I'm using the last version of the firmware : 1.10.0-rc.1 (nodemcuv2) and also tried dev-7
• For RC-1 I used the binary (using update firmware from UI), for dev-7 I built it myself and also tried the binary
• I'm trying to control FUT104 bulb
• I tried using RGB+CCT and FUT089/B8 remote type

/settings

{  
   "admin_username":"",
   "admin_password":"",
   "ce_pin":4,
   "csn_pin":15,
   "reset_pin":0,
   "led_pin":-2,
   "radio_interface_type":"nRF24",
   "packet_repeats":50,
   "http_repeat_factor":1,
   "auto_restart_period":0,
   "mqtt_server":"",
   "mqtt_username":"",
   "mqtt_password":"",
   "mqtt_topic_pattern":"",
   "mqtt_update_topic_pattern":"",
   "mqtt_state_topic_pattern":"",
   "mqtt_client_status_topic":"",
   "simple_mqtt_client_status":false,
   "discovery_port":48899,
   "listen_repeats":3,
   "state_flush_interval":10000,
   "mqtt_state_rate_limit":500,
   "packet_repeat_throttle_sensitivity":0,
   "packet_repeat_throttle_threshold":200,
   "packet_repeat_minimum":3,
   "enable_automatic_mode_switching":false,
   "led_mode_wifi_config":"Fast toggle",
   "led_mode_wifi_failed":"On",
   "led_mode_operating":"Slow blip",
   "led_mode_packet":"Flicker",
   "led_mode_packet_count":3,
   "hostname":"lolin2",
   "rf24_power_level":"MAX",
   "rf24_listen_channel":"MID",
   "wifi_static_ip":"",
   "wifi_static_ip_gateway":"",
   "wifi_static_ip_netmask":"",
   "packet_repeats_per_loop":10,
   "home_assistant_discovery_prefix":"",
   "wifi_mode":"n",
   "rf24_channels":[  
      "MID"
   ],
   "device_ids":[  
      9830,
      13107,
      17476
   ],
   "gateway_configs":[  

   ],
   "group_state_fields":[  
      "state",
      "brightness",
      "mode",
      "color_temp",
      "bulb_mode",
      "computed_color"
   ],
   "group_id_aliases":{  

   }
}

/about

{  
   "firmware":"milight-hub",
   "version":"1.10.0-rc.1",
   "ip_address":"192.168.1.92",
   "reset_reason":"Software/System restart",
   "variant":"nodemcuv2",
   "free_heap":18864,
   "arduino_version":"2_4_2",
   "queue_stats":{  
      "length":0,
      "dropped_packets":0
   }
}

The problem is : I can't pair the bulb. What I'm doing : power of the bulb, power it on, pressing "Pair" button (within 5 seconds) on UI after picking a random Device ID (also tried with the real one : 0x2666) & a Group.

I successfully paired my bulb with a FUT089 remote I bought for debug purpose. The instructions for pairing are : "Turn off the power, then turn on again after 5 seconds, press "|" 3 times within 3 seconds". This works fine.

I observed (by sniffing) that the remote sends 3 packets (press "|" 3 times) for pairing while Milight-hub sends 5.

I've bought everything for debug purpose :

• I have a remote FUT089 (working)
• I should receive an iBox today (hope I won't have to connect it to my network).
• I have everything double or triple (NodeMCU, NRF and so on)

I can make all the test you need.
I think I missed something evident or I might have misunderstood something on the UI.

Hope anyone could help me.

[sidoh]

Hi @Kuaaaly, thanks for including all the details.

Is this a new setup? Has it worked before or with different bulbs? If it's new, please check out the Troubleshooting Guide. It's not uncommon to be able to sniff packets, but not send them. Double-check the wiring, try moving the nRF further away or in a different orientation from the ESP, etc.

Another suggestion based on something you said:

The problem is : I can't pair the bulb. What I'm doing : power of the bulb, power it on, pressing "Pair" button (within 5 seconds) on UI after picking a random Device ID (also tried with the real one : 0x2666) & a Group.

Since the bulb is paired with the remote already, can you try controlling it with espMH using the remote's ID (e.g., try turning it on or off)?

Some bulbs don't allow you to pair with more than one device. Most of the newer ones do, so I'd expect that to be the case with FUT104. But maybe not. Milight is pretty inconsistent :)

[quentin-legraverend]

Hi @sidoh,

This is a new setup. I'm new to all of this :-). As I said in the first message, I tried everything I found in the Troubleshooting Guide (including building a new NodeMCU/NRF pair for sniffing purpose). This setup never worked and this FUT104 is the only bulb I have.

It seems that once the bulb is paired with a remote + group you can't pair it with another group on the same remote (I have only one remote). So it's possible that this bulb can only be paired with one remote (can't try a second remote as I don't have one)...

Obviously, I unpaired with the remote before trying again espMH.

Since the bulb is paired with the remote already, can you try controlling it with espMH using the remote's ID (e.g., try turning it on or off)?

Am I supposed to be able to do this with the Web UI ? How can I "fake" the remote ID ? What inputs should I give ?

[sidoh]

Ah, sorry I missed that you said you ran through the troubleshooting guide.

If you've unpaired the bulb with the remote, and you're still unable to pair with espMH, it's likely that sends aren't working at all. The troubleshooting guide mentions a few ways to determine whether this is the case.

Am I supposed to be able to do this with the Web UI ? How can I "fake" the remote ID ? What inputs should I give ?

Yeah. If you enable sniffing in the UI (click the "Start Listening") button, and click some buttons on the remote, packets should show up. These will include the ID of your remote.

If they're not showing up, it's likely you've got something wrong with the setup.

[quentin-legraverend]

I tried everything I found in the Troubleshooting guide. I'm stuck in the If all else fails... part :-)

I built 2 NodeMCU / NRF : sending and sniffing work on both. This means I see packets on Lolin 2 when I send command (with the UI) on Lolin 1. Same thing, with sniffing on, I see all the commands I send using the Remote.

Yeah. If you enable sniffing in the UI (click the "Start Listening") button, and click some buttons on the remote, packets should show up. These will include the ID of your remote.

Sure, sure, here's what I receive by sniffing a global OFF with the FUT089 remote :

fut089 packet received (9 bytes):
Raw packet: AC 2C 0F 11 72 E5 32 71 0A 

Decoded:
Key      : AC
b1       : 25
ID       : 2666
Command  : 01
Argument : 09
Sequence : EC
Group    : 00
Checksum : 6B

Here is what I send if I do a OFF on 0x2666 device using the UI :

fut089 packet received (9 bytes):
Raw packet: 00 D8 BB 3D 66 D6 B6 66 30 

Decoded:
Key      : 00
b1       : 25
ID       : 2666
Command  : 01
Argument : 0A
Sequence : 04
Group    : 01
Checksum : 79

My question is how can I send command from the UI like if I were the remote (faking I'm the remote).

EDIT (add) :

• I do not understand where is the remote ID (fut089 may be ? but it can't be only this)
• I do not understand what is the "Key"... And why it's always 00 in the case of the espMH

[sidoh]

Remote ID is the ID field in the sniffed packet. In your case, 0x2666.

Bulbs are addressed with a Device ID and a Group ID (and more implicitly, a remote type). In the packet sent by your remote, the Group ID is 0, which is the "all" group. The packet sent for ESPMH is for Group ID 1.

If you want to replicate the command sent by your remote, set Group ID to 0.

re: Key -- Milight added some unbelievably convoluted scrambling routine to packets for their newer line of devices. I reverse-engineered it a few years ago (link to code espMH here). The scrambling algorithm takes a one-byte parameter that determines some constants. This is Key. It's always 0x00 with espMH because there's no utility in varying it. Milight introduced it to obscure the packet structure, but considering espMH is open-source... :)

[JeremyLG]

@Kuaaaly can you follow up on this please, this is interesting if it worked for you

[quentin-legraverend]

Hi there,

I've been pretty busy those days sorry for the delay !
I made different tests but my problems still the same :

• Can't pair FUT1054 bulb with espMH
• Can't command (with the UI) the already paired bulb by substituting the Device ID of the remote.

Here is a trace of the following operations (bulb paired with the remote) :

1. Global OFF on paired remote (OK)

fut089 packet received (9 bytes):
Raw packet: F3 FC B4 0E 77 5D 21 8C 7D 

Decoded:
Key      : F3
b1       : 25
ID       : 2666
Command  : 01
Argument : 09
Sequence : 5A
Group    : 00
Checksum : 9C

2. Global ON on paired remote (OK)

fut089 packet received (9 bytes):
Raw packet: CD E5 8E E4 E5 C5 90 E7 24 

Decoded:
Key      : CD
b1       : 25
ID       : 2666
Command  : 01
Argument : 00
Sequence : 5B
Group    : 00
Checksum : F2

3. Global OFF on UI (NOK)

fut089 packet received (9 bytes):
Raw packet: 00 D8 BB 3D 66 D9 C2 65 2E 

Decoded:
Key      : 00
b1       : 25
ID       : 2666
Command  : 01
Argument : 09
Sequence : 08
Group    : 00
Checksum : 7B

4. Global ON on UI (NOK)

fut089 packet received (9 bytes):
Raw packet: 00 D8 BB 3D 66 D0 C3 65 26 

Decoded:
Key      : 00
b1       : 25
ID       : 2666
Command  : 01
Argument : 00
Sequence : 09
Group    : 00
Checksum : 73

Here are the steps I use to try to pair the bulb with espMH :

1. Unpair from remote
2. Pick a random Device ID in espMH UI + pick a group
3. Power off the bulb
4. Power on the bulb
5. Within 5 seconds click on the pair button on the UI

=> this is unsuccessful, is this the correct approach ?

With the remote :

• Succesful pairing => the bulb flash slowly 3 times green
• Successful unpairing => the bulb flash quickly ten times red

Do you see anything I'm doing wrong or any test I could do for debug ?
Anyone here successfully paired espMH with FUT104 ?

[sidoh]

Have you tried moving the espMH right next to the bulb and/or cranking up the number of repeats?

You could experiment with the raw packet functionality esp MH exposes. I would try:

1. Get an "OFF" packet from a remote
2. Physically remove power to the bulb. This is important -- devices ignore packets with a sequence number close to the one in the last packet they saw, but only have volatile memory.
3. After a few seconds of waiting, power the bulb back on. It should turn on.
4. Manually send the same OFF packet to the bulb from espMH using the route I mentioned above.

If you can get it the bulb to respond this way, it'll be interesting. If it still doesn't respond, it's probably either a range or interference issue.

[quentin-legraverend]

Hi @sidoh,

I tried your method and sent the following raw packet (sniffed from the remote itself) after physically power off the bulb, waiting about 3 minutes and power it on again:

curl -XPOST http://lolin2.local/raw_commands/fut089 -H "Content-Type: application/json" -d '
{
    "packet": "96 11 E1 48 F6 C1 17 B5 03",
    "num_repeats": 50
} '

This didn't worked. I have absolutely no guess on how to keep debugging...
One question: is this NRF24L01 supposed to work with espMH?

Have you tried moving the espMH right next to the bulb and/or cranking up the number of repeats?

Yes & yes

[sidoh]

I can at least confirm that the command you pasted:

1. Results in a FUT089 packet being sent
2. The same packet is picked up from a different device ~20 meters away and through several walls

the decoded packet, for reference:

fut089 packet received (9 bytes):
Raw packet: 96 11 E1 48 F6 C1 17 B5 03 

Decoded:
Key      : 96
b1       : 25
ID       : 2666
Command  : 01
Argument : 09
Sequence : 7E
Group    : 00
Checksum : 13

if your bulbs are not responding to exactly the commands sent by your remote, the only reasonable theory i have without further data is that they're not being received. that doesn't make a lot of sense if you've got a different device receiving the packets, but don't have a lot to go off of.

I'm afraid we're running into a dead-end. I don't have a way to reproduce this problem with the gear I have. I'm afraid we're running into a dead-end. I'm happy to help, but I'm out of ideas.

[sidoh]

The next thing I'd do if I were you is tap the SPI pins on your remote and see if there's anything fucky going on.