search

sidoh / esp8266_milight_hub

Replacement for a Milight/LimitlessLED hub hosted on an ESP8266
MIT License
934 stars 220 forks source link

Can't pair FUT104 bulb #498

Closed quentin-legraverend closed 5 years ago

quentin-legraverend commented 5 years ago

Hi there,

/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 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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) :

sidoh commented 5 years ago

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 commented 5 years ago

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

quentin-legraverend commented 5 years ago

Hi there,

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

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.

quentin-legraverend commented 5 years ago

I do not understand what you want me to do... I have the following points to keep going :

sidoh commented 5 years ago

I don't think I know what I want you to do, which is why I said I think we're running into a dead-end. (twice, I guess. i was tired :).

Can you confirm that my NRF24L01 is supposed to be OK?

Should be fine. Especially if you have another install picking up packets.

Which models of bulbs do you have at home? I will order one of them to try it. I couldn't have a confirmation of someone using successfully FUT104 with espMH (I was about to order a FUT014 or a FUT013, are they devices you worked with?)

Have quite a few bulb types in a test box, but FUT104 isn't one of them. In my actual setup, I use a mix of FUT105 and FUT015.

There's something pretty strange going on, though. This is deeper than a simple incompatibility with a bulb. The fact that you're seeing packets from a remote the bulbs respond to, coupled with sending exactly the packet the remote sent means:

  1. The same radio configs (channel, syncword, etc.) are being used.
  2. The packet structure is the same

Which makes me think there's either something really screwy on a level I'm not familiar with (deep inside the RF packets, for example), or maybe your remote is sending more than what you're seeing sniffed. This is why I suggested tapping the SPI pins.

I just ordered a FUT014 to test with.

Telling about me, I'll be with my father for 2 weeks starting on Sunday, he has good knowledge of electronics, RF and so on. I might find something with him. I'll let you know.

great, look forward to it!

quentin-legraverend commented 5 years ago

Have quite a few bulb types in a test box, but FUT104 isn't one of them. In my actual setup, I use a mix of FUT105 and FUT015.

Mi-Light bulb series are really strange :

This is why I suggested tapping the SPI pins.

I will try it with my father next week.

I just ordered a FUT014 to test with.

You mean a FUT104?

sidoh commented 5 years ago

Yeah, the models are an absolute mess. Honestly everything about these devices are a mess except that they work well after you get things set up.

There is absolutely no logic expect if I'm wrong with the models... Furthermore, FUT015 seems to have been discontinued (can't find it on Amazon, AliExpres...) FUT105 might be its replacement: and you said FUT105 is working for you?

This sounds right. FUT015 technically responds to the "RGB+CCT" (FUT092) remote type, but it's labeled as RGBWW.

Yeah, FUT105 works. I'm using the FUT089 remote type.

Yes, FUT104. Sorry.

quentin-legraverend commented 5 years ago

Honestly everything about these devices are a mess except that they work well after you get things set up.

That's why I chose them :)

Yes, FUT104. Sorry.

Let me know how you're going with FUT104.

It's possible that I buy a FUT013/14 or 105 to try another bulb, I will do it with my father cause I have no E14 / E27 here. Electrician decided to put only MR16 and G24Q-3 socket 🎉 (G24Q-3 are slow and not connected bulbs - 🎉 again).

sidoh commented 5 years ago

FUT104 arrived today. Seems to be working as expected.

I did notice some funky behavior when I first started using it, but I think it was just because the nRF got loose from the crappy jumper ribbon I use.

Video here.

Shown is all being controlled via espMH's web UI:

I tried physical FUT092 ("RGB+CCT") and FUT089 remotes. I tried pairing with the physical remotes then controlling with espMH, and pairing with espMH then controlling with the physical remotes. It all worked as expected.

sidoh commented 5 years ago

How bizarre!

It seems like you've tried everything I can think of. You were super thorough.

In case it's helpful, this is the FUT104 I bought. The nRF24L01s I have are from a variety of sources.

Let me know if you think of anything else I can try on my end.

quentin-legraverend commented 5 years ago

Thank you @sidoh for your time and tries. Still not working for me, can't figure out why... I am with my father till today, I will redo all the tests with him. If it still not working, I will buy an other bulb or / and another NRF24L01 or / and another FUT104, there must be something wrong there...

A point about the UI, for pairing the bulbs those steps are the correct one:

  1. Pick a random Device ID in espMH UI + pick a group
  2. Power off the bulb
  3. Power on the bulb
  4. Within 5 seconds click on the pair button on the UI
quentin-legraverend commented 5 years ago

Few more (simple) questions for you that may help us:

Can you please sniff & copy / paste:

Thank you !

quentin-legraverend commented 5 years ago

Hello again @sidoh,

Sorry for the triple post 😅!

I looked again with my father, but currently nothing more to say. Just te be sure, we recorded a video showing how this works (or not 😢). Can you please watch it and tell me if we are doing something wrong?

To fully understand what we are doing in the video, I added workflow in description + pastern of sniffed packets + all hardware & co details...

Our plans for next step:

EDIT (2019/08/11 - 16:40): I have just order a E27 9W RGBCCT bulb (supposed to be FUT012, but in France those devices are new and Amazon vendors are doing shitty ref work 👶). More news on August, 17...

sidoh commented 5 years ago

A point about the UI, for pairing the bulbs those steps are the correct one:

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

yep, exactly right. also ensuring you've selected the remote type you want to be using, of course.

Pairing from remote (FUT089) send 3 packets? Pairing from espMH send 5 packets? Unpairing from espMH send 10 packets?

espMH sends 5 packets each for pairing and unpairing. Only 3 are necessary, but at least for everything I've tried, more doesn't hurt. I've included the code below in case you want to try changing this.

// PacketFormatter.cpp
void PacketFormatter::pair() {
  for (size_t i = 0; i < 5; i++) {
    updateStatus(ON);
  }

// V2PacketFormatter.cpp
void V2PacketFormatter::unpair() {
  for (size_t i = 0; i < 5; i++) {
    updateStatus(ON, 0);
  }
}

Note that for unpairing, packets for Group 0 are sent. I think this is just based on some instruction manual I got with a remote. It does not seem to matter -- sending packets for the Group ID the bulb was paired with and for Group 0 work.

Can you please sniff & copy / paste:

Packets sent by remote (FUT089) on pairing step?
Packet sent by remote (FUT089) on global OFF?
Packets sent by espMH on pairing step?
Packet sent by espMH on global OFF?

Yep, here ya go:

Packets sent by remote (FUT089) on pairing step

I'm pressing the Group 1 "ON" 3 times here. Pairing seems to work just fine if I press it 5 times as well (it starts flashing green after the 3rd press).

fut089 packet received (9 bytes):
Raw packet: 19 99 D2 FC 61 40 73 62 4D 

Decoded:
Key      : 19
b1       : 25
ID       : 56C2
Command  : 01
Argument : 01
Sequence : C4
Group    : 01
Checksum : 65

fut089 packet received (9 bytes):
Raw packet: 12 95 D5 F0 C2 95 D8 82 45 

Decoded:
Key      : 12
b1       : 25
ID       : 56C2
Command  : 01
Argument : 01
Sequence : C3
Group    : 01
Checksum : A9

fut089 packet received (9 bytes):
Raw packet: 4D 65 FE 00 65 44 79 66 17 

Decoded:
Key      : 4D
b1       : 25
ID       : 56C2
Command  : 01
Argument : 01
Sequence : C2
Group    : 01
Checksum : 67

Packet sent by remote (FUT089) on global OFF

I pressed it a few times for good measure:

fut089 packet received (9 bytes):
Raw packet: 7E 29 49 7C 4E 29 68 0E A9 

Decoded:
Key      : 7E
b1       : 25
ID       : 56C2
Command  : 01
Argument : 09
Sequence : C7
Group    : 01
Checksum : 41

fut089 packet received (9 bytes):
Raw packet: 44 94 67 15 1A 7D B0 1A 71 

Decoded:
Key      : 44
b1       : 25
ID       : 56C2
Command  : 01
Argument : 09
Sequence : C6
Group    : 01
Checksum : 7A

fut089 packet received (9 bytes):
Raw packet: B6 F1 91 C4 16 E1 AE D6 37 

Decoded:
Key      : B6
b1       : 25
ID       : 56C2
Command  : 01
Argument : 09
Sequence : C5
Group    : 01
Checksum : 07

Packets sent by espMH on pairing step

fut089 packet received (9 bytes):
Raw packet: 00 D8 0B E1 66 D1 C9 66 3E 

Decoded:
Key      : 00
b1       : 25
ID       : 56C2
Command  : 01
Argument : 01
Sequence : 73
Group    : 01
Checksum : 6B

fut089 packet received (9 bytes):
Raw packet: 00 D8 0B E1 66 D1 C8 66 3D 

Decoded:
Key      : 00
b1       : 25
ID       : 56C2
Command  : 01
Argument : 01
Sequence : 72
Group    : 01
Checksum : 6A

fut089 packet received (9 bytes):
Raw packet: 00 D8 0B E1 66 D1 CB 66 40 

Decoded:
Key      : 00
b1       : 25
ID       : 56C2
Command  : 01
Argument : 01
Sequence : 71
Group    : 01
Checksum : 69

fut089 packet received (9 bytes):
Raw packet: 00 D8 0B E1 66 D1 CA 66 3F 

Decoded:
Key      : 00
b1       : 25
ID       : 56C2
Command  : 01
Argument : 01
Sequence : 70
Group    : 01
Checksum : 68

fut089 packet received (9 bytes):
Raw packet: 00 D8 0B E1 66 D1 DD 66 32 

Decoded:
Key      : 00
b1       : 25
ID       : 56C2
Command  : 01
Argument : 01
Sequence : 6F
Group    : 01
Checksum : 67

Packet sent by espMH on global OFF

fut089 packet received (9 bytes):
Raw packet: 00 D8 0B E1 66 D9 C6 65 26 

Decoded:
Key      : 00
b1       : 25
ID       : 56C2
Command  : 01
Argument : 09
Sequence : 74
Group    : 00
Checksum : 73
sidoh commented 5 years ago

I looked again with my father, but currently nothing more to say. Just te be sure, we recorded a video showing how this works (or not 😢). Can you please watch it and tell me if we are doing something wrong?

To fully understand what we are doing in the video, I added workflow in description + pastern of sniffed packets + all hardware & co details...

Everything in the video looks correct to me. The sniffed packets all look like I'd expect them to.

I'm sure you're already well aware, but in the absence of further ideas, I will say that breadboard/dupont connectors can be really unreliable. It's possible for even a slight bump to cause a jumper to lose its connection.

This can be really confusing with a chip like the nRF24 where listening can work fine while sending doesn't work at all.

A suggestion (which you may have already tried):

Keep your other other ESP8266 set up and verify that commands you think you're sending are being received. I know you already did this, but if it was in isolation from trying to control the bulb, a connection may have loosened later on.

Question that just occurred to me -- are you using the pin mapping suggested in the README?

Our plans for next step:

Buying another bulb (other model)
Find & try an alternative of espMH - not easy - to see if the problem is coming from espMH or hardware

EDIT (2019/08/11 - 16:40): I have just order a E27 9W RGBCCT bulb (supposed to be FUT012, but in France those devices are new and Amazon vendors are doing shitty ref work 👶). More news on August, 17...

If FUT012 bulb is working, then FUT104 bulb is in fault : may be new version with more obfuscation
If FUT012 bulb is not working, there might be something wrong in my setup, despite all the tries I did...

This all makes sense to me.

I'm not aware of any successful independent efforts to reverse the obfuscated milight protocol. I believe RFLink has support, but I'm pretty sure they just copied from me as support showed up a few months after I released RGB+CCT support. Source code isn't immediately available, so hard to tell for sure. Doesn't hurt to try, of course =)

quentin-legraverend commented 5 years ago

Thanks for your traces / logs. I have exactly the same thing here.

A suggestion (which you may have already tried):

Keep your other other ESP8266 set up and verify that commands you think you're sending are being received. I know you already did this, but if it was in isolation from trying to control the bulb, a connection may have loosened later on.

I have just re-tried everything another time: my 2nd ESP/NRF couple is receiving absolutely all the packets I am sending with my first espMH (trying to pair with FUT104, trying to send command as an already paired remote and so on)... To me, there is no doubt that RF packets are properly sent and received (at least between the ESP 😢). I also tried to play with all the settings I found, packet repeat, power level, send channel... nothing

As I said before, I will wait my FUT012 bulbs with 2 possible conclusions:

About the raw packet, does espMH display it entirely or you only "unpack" partial information responding to the structure of Mi-Light packets?

Another thing: I settep up the iBox 2 (sadly, 😞) it works as expected (except the fact that I had to use an Android Phone to set it up, iOS didn't work). I sniffed packets (using espMH), I didn't see anything abnormal, packets look like FUT089 or other remote packets.

sidoh commented 5 years ago

Super weird. I can try to tap the SPI pins on my FUT089 to see if it's doing anything unusual, but might be a while before I get around to doing that, and I would be really surprised to see anything interesting.

As I said before, I will wait my FUT012 bulbs with 2 possible conclusions:

If it still doesn't work: I must be doing something wrongly
If it works: my FUT104 is the problem and there might be something new with the protocol in the version of my bulb (and for me, that might be related with the strange key field because it's the only one we don't care about)...

It'll definitely be interesting. Honestly, though, not sure you'll be able to definitively conclude anything either way. If it doesn't work, could just be another bulb with the same em... difference.

There's pretty strong evidence that the key field is not behaving differently with your remote. I'm pretty familiar with it (the blog post I linked earlier was the result of lots of blood, sweat and tears). Namely, the fact that the decoded fields are stable while the key changes means the decoding is very likely working as expected.

About the raw packet, does espMH display it entirely or you only "unpack" partial information responding to the structure of Mi-Light packets?

The data displayed is the raw payload of the packet sent. There are, of course, a few layers that wrap the milight packet.

Milight devices actually use a LT8900 radio. The nRF24 is able to emulate it without much trouble. The LT8900 packet includes a few extra fields, e.g., a trailer and a 16-bit CRC. espMH emulates the LT8900 by adding these fields into the nRF24 packet.

Tapping the SPI pins on your remote will show what commands are being sent to the radio.

You might also try using an LT8900 with espMH, although the support for it is pretty limited. I think listening is broken, for example.

Another thing: I settep up the iBox 2 (sadly, 😞) it works as expected (except the fact that I had to use an Android Phone to set it up, iOS didn't work). I sniffed packets (using espMH), I didn't see anything abnormal, packets look like FUT089 or other remote packets.

Yeah, I have one of these too. And I actually have tapped the SPI pins on it, and it behaves like you'd expect.

quentin-legraverend commented 5 years ago

FUT104 arrived today. Seems to be working as expected.

@sidoh which version of espMH did you use for your tests?

sidoh commented 5 years ago

one of the 1.10 releases, not sure which. but shouldn't matter.

quentin-legraverend commented 5 years ago

FUT012 has just arrived and guess what?

It's not working 😭

We should receive another FUT012 soon and an other FUT089 but I'm not sure it's gonna help. I think we are missing something huge...

To sum up:

We recently try this to partially exclude a hypothesis were Key was involved:

  1. Power on the bulb
  2. Pair it in zone 1 with a FUT089 remote
  3. Physically disconnecting the bulb
  4. Playing and sniffing a zone 1 off with the FUT089 remote (bulb can't see the command)
  5. Power on the bulb again
  6. Replay with espMH the sniffed zone 1 off
  7. Packet is well sniffed by other espMH but bulb doesn't react...

Except a big coincidence, to me, that's pretty clear that Key is not the key :trollface: and as said before we are missing something huuuuge...

Is it possible that all my NRF24L01 can received each others, can receive iBox and FUT089 but are not able to properly send to bulbs?

quentin-legraverend commented 5 years ago

Me again, to pursue my previous message, I'll jump back on this:

  • Can you confirm that my NRF24L01 is supposed to be OK?

Reading the sum up & partial conclusions I made in my previous post, the only thing I suspect being the cause of all our troubles is the use of a NRF24L01 instead of a NRF24L01+...

This question is coming to me:

I found a French article clearly saying to prefer model +. Here is the few interesting lines (traduction below):

Préférer le modèle nRF24L01+ au modèle nRF24L01 (sans le +). Pour savoir quel est le type d’un module, utiliser le programme d’exemple pingpair_ack.ino, ou le programme printDetails.ino ci-dessous. Une des différences notables est la possibilité de descendre à 250 kb/s pour le modèle +. En plus de ça, Nordic indique dans la spec du nRF24L01+ : Intermodulation and wideband blocking values in nRF24L01+ are much improved in comparison to the nRF24L01 and the addition of internal filtering to nRF24L01+ has improved the margins for meeting RF regulatory standards.

First lines approximately says (last lines are already in English):

Prefer model nRF24L01 + on model nRF24L01. One of the main difference is the ability to go down to 250kb/s on model+.

Any thought on this?

sidoh commented 5 years ago

Not surprised at this point, but I'm definitely confused. :S

Just noticed this in your settings:

   "rf24_channels":[  
      "MID"
   ],

I'm assuming the answer is yes, especially since I believe this is the default, but you try setting this to:

   "rf24_channels":[  
      "MIN","MID","MAX"
   ],

? Shouldn't matter, but worth a shot if you haven't tried it.

Is it possible that all my NRF24L01 can received each others, can receive iBox and FUT089 but are not able to properly send to bulbs?

I don't know enough about the guts of these things to say whether or not that's the case, but it seems possible to me. Only thing that makes that not make complete sense is that it's able to pick up commands sent by remotes.

This question is coming to me:

Did you try with a NRF24L01 (no +)?

I found a French article clearly saying to prefer model +. Here is the few interesting lines (traduction below):

Préférer le modèle nRF24L01+ au modèle nRF24L01 (sans le +). Pour savoir quel est le type d’un module, utiliser le programme d’exemple pingpair_ack.ino, ou le programme printDetails.ino ci-dessous. Une des différences notables est la possibilité de descendre à 250 kb/s pour le modèle +. En plus de ça, Nordic indique dans la spec du nRF24L01+ : Intermodulation and wideband blocking values in nRF24L01+ are much improved in comparison to the nRF24L01 and the addition of internal filtering to nRF24L01+ has improved the margins for meeting RF regulatory standards.

First lines approximately says (last lines are already in English):

Prefer model nRF24L01 + on model nRF24L01. One of the main difference is the ability to go down to 250kb/s on model+.

Any thought on this?

I've had the nRF24s I use for a while, but looking at my ebay order history, I believe it's these, so they are the + model.

quentin-legraverend commented 5 years ago

I'm assuming the answer is yes, especially since I believe this is the default, but you try setting this to...

Yes, I tried.

I've had the nRF24s I use for a while, but looking at my ebay order history, I believe it's these, so they are the + model.

I was about to order new nRF but I looked closely a few moments ago, it's written NRF24L01+ on the square chip (photo below): IMG_1675

This doesn't totally discard the nRF but at least guaranty (or not?) they are model + and the problem is not here...

I want to keep believing that nRF are the problem but how this can be possible while they all are sending and receiving packets well...

quentin-legraverend commented 5 years ago

OMFG! Got it!

I want to keep believing that nRF are the problem but how this can be possible while they all are sending and receiving packets well...

I was right, I ordered new nRF yesterday, and have just received them few moment ago... It works!

So, all my nRF24L01+ modules were faulty. I have been in pain for days but I think it's a good catch for the espMH community, @sidoh you might find useful to link this issue in the Troubleshooting guide or at least mention that:

=> are not necessary sufficient proofs to confirm that your nRF are working properly

Moreover, by reading #322 yesterday, I tried soldering a 10uF capacitor + using an external power supply for the nRF module, no difference...

To conclude: in my case, the only way to solve the problem was ordering more nRF to make more tests.

sidoh commented 5 years ago

Glad you got it working. That's really, really strange. Happy to add this to the troubleshooting guide, but honestly I don't expect it to be very common.

It wasn't even that your nRF24s weren't working -- they were transmitting packets for sure. It's that they were doing something non-standard. Perhaps they were knockoffs?

sidoh commented 5 years ago

I've updated the troubleshooting guide:

https://github.com/sidoh/esp8266_milight_hub/wiki/Troubleshooting