Packets from some remotes (e.g., RGB) are never sniffed

[xbmcnut]

Great work so thank you for this. I intend using it to replace a dead v4 Milight bridge and with Hass.io

I have flashed 1.6.5 onto a NodeMCU V2 and have a NRF24L01 module (that was working with My Sensors previously) and I have managed to pair one MiLight bulb (CCT) and can control on/off, brightness and color temp. Based on this, I'm assuming the NRF module is fully working?

My question is I have two different 2.4Ghz RF remotes; one for a flash pendant wave light and another for some RGB LED strips. Both lights work with their consecutive remotes.

When I activate sniffing though and use either remote, I see nothing. I do see data when I use the UI to control the one paired bulb but nothing when using the remotes. Am I supposed to see something when the remote turns on my lights that are not paired with any bridge?

P.S I have not configured anything in the MQTT section yet other than my broker address.

[sidoh]

Any traffic espMH intercepts while in listening mode should show up. Shouldn't matter if the remotes are paired with anything.

If it's not showing up, it might be a remote model that's not supported. Could you:

• Let me know what model the remote is? futlight.com seems to have the best product catalog.
• See if there's anything interesting in Serial logs with the DEBUG_PRINTF flag enabled?

[xbmcnut]

Thanks for the prompt reply. The LED RGB strip remote appears to be a FUT098. The other one is not shown at futlight.com but here is a picture.

I'm assuming I'll have to compile to enable the debug flag?

[sidoh]

That's right, build flags are here:

https://github.com/sidoh/esp8266_milight_hub/blob/master/platformio.ini#L28

My guess is that both of those should work. The pictured one looks like a FUT007. Never used one myself, so not positive that it would show up.

[xbmcnut]

I there. Bit rusty on Platformio but tried it with settings below.

Serial monitor inside Platformio have me nothing but 'null null null null' so I connected to COM4 with Putty. Got valid data when I used an actual FUT007 (found the one that came with my bridge), but the remote pictured above and the FUT098 show nothing. Maybe there are just outside the band of the NRF2401 I have?? I have a LT8900 (with NRF2401+ chip) so maybe I'll try that next.

[xbmcnut]

The other module I have is not a LT8900 (as sold to me) but the ultra mini version of the NRF2401+. I hooked it up anyway and get the same results from PuTTy.

*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 10.0.1.182
Setup complete
Radio is available

Packet received: E05A58D540B09778EE030303Packet transformed: 075A1AAB020DE91E77C0  C0C0Failed CRC: expected 0, got 49344

Only see these results when pushing buttons on the 'real' FUT007. Nothing from the other remotes. Does that tell us anything?

[sidoh]

Sniffing on the real LT8900 might even be broken. So maybe a good thing it wasn't a real one? :)

Definitely looks like an unsupported protocol. Might even suggest it's knockoff hardware that wasn't implemented to spec.

Could you get a few more packet captures and label them with what button they correspond to?

[xbmcnut]

Thanks but that's the thing. The knock off remotes do not generate any code in PuTTy even though they work on their respective lights.

[sidoh]

Sorry, I should've been more clear. I meant the logs from serial output. Like the stuff you pasted above:

Packet received: E05A58D540B09778EE030303Packet transformed: 075A1AAB020DE91E77C0  C0C0Failed CRC: expected 0, got 49344

This contains the packet data.

[xbmcnut]

Thanks Chris but that is the problem. I have three remotes and only one gives me a data output through PuTTY. Not sure I did the Platformio build right but it did upload and the NoceMCU board works so I'll take that as a win. I'm assuming that if if didn't build with the DEBUG_PRINTF enabled then I'd getting nothing on serial? I can't post anything for the two 'rogue' remotes as nothing is being 'seen' by the NRF2401.

[sidoh]

If you're seeing that "Packet received" line, you successfully compiled with DEBUG_PRINTF.

If you're not seeing serial output for your remotes, then they're probably sending on different channels and with different syncwords. We'd likely need to sniff the SPI bus to get those parameters.

I ordered a FUT007 from ebay, but won't be here for a few weeks.

[xbmcnut]

Thanks for all your help, much appreciated. Is there a way I can set up a sniff from the SPI bus?

[sidoh]

Doing this is quite a bit more heavyweight than most things required for this project. You'd need a logic analyzer or oscilloscope, and you'd probably need to take apart the remote so you could attach probes to the appropriate pins.

[xbmcnut]

I have an oscilloscope and an electronics background and don' like being beaten by a machine! :) If I can help get these remotes working, I'm happy to help if you can point me in the right direction.

[sidoh]

It's not something I actually have any experience with. I think people basically find the microcontroller or the radio, figure out where the SPI pins are, and watch for messages as actions are taken. Fancier scopes can decode SPI messages. Some of the folks who have helped out with this before have digital logic analyzers that do this.

[sidoh]

Got my FUT007. Works with CCT:

cct packet received (7 bytes):
Request type  : 5A
Device ID     : 333A
b1            : 02
b2            : 04
b3            : 2A
Sequence Num. : FE
cct packet received (7 bytes):
Request type  : 5A
Device ID     : 333A
b1            : 02
b2            : 04
b3            : 29
Sequence Num. : FD
cct packet received (7 bytes):
Request type  : 5A
Device ID     : 333A
b1            : 02
b2            : 04
b3            : 28
Sequence Num. : FC

[xbmcnut]

Thanks, I appreciate you going to that effort. One of my three remotes is indeed that one that is branded 'Mi-Light' and I can confirm mine works too. The other two do not however. The colour LED strip one is this one https://www.ebay.com/itm/2-4G-LED-RGB-RGBW-Controller-Touch-Screen-RF-Remote-Control-for-RGBW-LED-Strip-/262983073383?roken=cUgayN&soutkn=huGRwh. Can I send you one of those to try? PM me if that is OK.

[sidoh]

No need, I think. I have the milight wifi bridge which is capable of emulating that remote.

I can confirm I'm not seeing any sniffed traffic on my end.

We'll need to get the radio configs (channels, syncwords) to add support for the remote. This writeup shows a teardown of a milight device. My wifi gateway has both of these chips, but I don't have the equipment to do this myself.

Also possible that someone else has done this already.

[sidoh]

Found a really cheap digital logic analyzer that works great.

Don't have great probes, but managed a hacky solder job of magnet wire to the SPI pins on the radio:

I think there's a bug in the listening logic for the nRF24L01 radio code. The syncwords and channels are already configured, but packets aren't showing up. Seems like some packet types just aren't working.

Thinking it's probably a regression introduced in 1.6 when the nRF code was optimized. Will try to find some time to dig in over the next couple of weeks.

[xbmcnut]

Wow Chris, that is above and beyond! You made my day though :). If I can get my new WiFi dining room light and the pool LED's voice controlled by HA, I can put my feet up with a cold one for at least a week! Cheers for all your hard work, much appreciated. P.S Can you link to the analyzer you got? Might pick one up myself.

[sidoh]

https://www.amazon.com/gp/product/B077LSG5P2

And to think I was halfheartedly considering getting a $400 Saleae.

[xbmcnut]

Wow, that is awesome! If it did the trick, that is all I need too. Thanks.

[sidoh]

Just an update here --

This is definitely an issue with the nRF radio code. I poked around a little bit, but haven't made much progress yet. (I did, however, manage to get the radio configs for all remotes supported by the ibox)

@khmann I recall that some of the radio optimizations you contributed a few months back may have broken sniffing from official devices (this was something we agreed was fine at the time). Does this sound familiar to you?

If so, any pointers on adding this support back without breaking the radio? Definitely happy to investigate myself, but thought I'd ask in case you have any ideas offhand.

[xbmcnut]

Thanks for the update.

[xbmcnut]

Any NRF changes in the esp8266_milight_hub_nodemcuv2-1.8.0-dev1 build?

[sidoh]

@xbmcnut hey, sorry I'm so slow getting back to you. Busy summer!

No, no nRF changes in v1.8. At the rate I'm going it probably won't make it in.

[xbmcnut]

Thanks for the update, appreciated. Let us know once you have something I can test.

[khmann]

Sorry, I dropped off the internet for awhile. The "bug" relates to the not-clearly-defined PL1167 trailer bits; It is possible that these bits are encoded differently by different transmitters and my original patch (RF mod was to replace the rather silly PL1167 software decoding by using nRF hardware filters) had a problem with some of the syncword calculation. I believe this was actually fixed in the second patch, but that there was some other problem that broke everything. I've been meaning to pick this back up (and actually use it this time - previously I was just using the reusing your radio code for my own project)

EDIT: part of the problem is in the below area, I was always confused how to set the "trailer" bits... never found that "defined" to my liking... I haven't looked at it in awhile, maybe I was wrong and it should always be 0x05 or 0x0a . nRF stores syncword backwords and flipped, so that's part of why the whole setup is so goofy. If I get back on this project again, nRF actually supports 2 simultaneous RX syncwords, I'll just add the alternate trailer as well.

[code]
if (_syncword0 & 0x01) {
_nrf_pipe[ --nrf_address_pos ] = reverse_bits( ( (_syncword0 << 4) & 0xf0 ) + 0x05 );
} else {
_nrf_pipe[ --nrf_address_pos ] = reverse_bits( ( (_syncword0 << 4) & 0xf0 ) + 0x0a );
}
[/code]

[sidoh]

Beginning to feel like you might have some not-Milight gear.

Some questions/asks:

1. Could you post pictures of all of the not-working remotes you have (including the PCB if possible)?
2. Does the really old v1.5 release works for you?
3. Does espMH work to control the LED strip at all? (guessing you're not able to do this because you don't have the remote ID)

Beyond this, think we might be stuck until I get the FUT098 I ordered or you get the logic analyzer and post SPI dumps.

[xbmcnut]

Below is the board photo from the FUT098 (clone) that came with a LED strip controller.
https://photos.app.goo.gl/afe4jLW2mn3Q1HDT8
And here is the board of the controller pictured above that came with my dining room lights
https://photos.app.goo.gl/HRrzxccCK6hBHn1Y7

I tried 1.5 built binary as I could not build with PIO and got nothing in the sniffing console when using the two rogue remotes.

When the USB debugger turns up I can provide more info but I'd need guidance on how to do that based on the image links as there are no markings on the chips.

[xbmcnut]

Is there a datasheet on the 16-pin radio chip on the remote PCB so I can identify the SPI pins?

[sidoh]

I believe this is the PL1167 --

here's a datasheet:

2014.2.8_9.21.48_1259.pdf

this is the pinout:

relevant pins are:

DVSS - pin 6 - Gnd
SCK - pin 7 - SPI clock
SDO - pin 10 - SPI out
SDI - pin 9 - SPI in

[xbmcnut]

That's helpful thanks. And by poking around, I believe I need this program? https://www.saleae.com/downloads/

[sidoh]

thats right!

[cometfish]

Just wanted to chime in and say I've been following this one, because one of my remotes (RGB) never came up when sniffing. With the 1.10.0-dev5 build, it's now working! Thankyou! :)

[xbmcnut]

Thanks @cometfish I raced home to try dev5 with my two rogues but alas, still no go. Never fear, USB debugger turned up yesterday so Houston, standby...

[cometfish]

Sorry @xbmcnut, I should've specified I had skipped straight from the 1.9 release to 1.10.0-dev5 - it was probably the fix in dev4 that helped for my remote.
Good luck with the USB debugger!

[xbmcnut]

Started looking at the debugging today but both the working MiLight remote and one of the rogue remotes don't follow the pinout for the PL1167. If you take the dot as indicating pin one, then my antenna is connected to 09 and VCC is on 12 with GND at 15. This does not marry with a PL1167?

Any other possibilities for the 2.4G transceiver in a GOP16 configuration?

[sidoh]

That looks right to me. The datasheet I linked is the only PL1167 documentation I'm familiar with. Could try to find where the trace going to the copper antenna is going as a reference.

The orientation you've described is the one I used as well, I think. But on vacation now, so can't check :)

[xbmcnut]

Schematic for PL1167 shows antenna on 16, VCC on 11 and GND (DVSS) on 6.

[sidoh]

The dot on my devices seems to not indicate pin 1. I had to try some of the other pins towards the end until I found the right ones. :X

[xbmcnut]

If you follow my pix above disregarding the pin 1 locater, the antenna, power and GND do not map to the PL1167 no matter which way you try and look at it.

[sidoh]

Huh, wacky. I've tapped the PL1167 pins on I believe 5 different devices, and they're always in the same place. :-\

[localhost61]

Hi @sidoh and @xbmcnut.
I discover this project and it's exactly what I was looking for in order to control two ceiling lights with OpenHab, one is a 48W CCT+Leds, the other a 36W RGB-CCT. And I'm already familiar with all the parts of it. But unfortunately it doesn't work as I would expect...

• I cloned at first the master branch but having issues in PlatformIO for windows, telling that several forks of the required version of library were available for nRF24, mqtt and some others I don't recall, back to the blog I ended up to compile latest 10.0-wip and uploaded it on a Wemos D1 mini and a nodeMCU too.
• I connected those ESP to several nRF24L01 I own where one of them is a PA+LNA model.
• No problem to reach the webpage with a browser, I could sniff the packets of the RGB-CCT remote but couldn't manage to control the lamp. And about the CCT one, as it seems I've got a new version of the @xbmcnut 's one with fluorescent buttons, I got nothing at all too.
• I tried to uncommented -D DEBUG_PRINT in platformio.ini and monitor on USB to get more troubleshooting data... and the packets appear in the PIO monitor and no more at the end of the webpage.
• On D1 mini, using esptool, I uploaded several older pre-compiled Release files too (RC1, dev8, 1.9.2, 1.6.0-dev3 with complementary data but no result.

None of my two remotes were referenced as milight products, I believe they are clones of FUT096 and FUT007, all the boards have a 'GM' reference on the silk screen. The interesting, and somewhat scarring, news is that both remote's chips are monolithic. The 2.4GHz RF and the CPU are integrated in a single 16 pin SOIC, and it's not a nRF24 as it doesn't seem to exist in such package. At first sight my RGB-CCT remote shows 2 chips, but U17 appears to be only used to encode the touch buttons, both Oscillator and Antenna or connected to IC2.
Thus no SPI pins may be available here for diagnose. But... on the 36W controller side, we have two separate chips one 16 pin and one 20 pin, a 80C51 CPU, the Nuvoton N76E003AT20 with SPI on pins 7,15,16,17.
So I'll have to check if this 16pin chip pinout matches the one on my FUT007 clone and the older one.

Here are the pictures ov my remotes:

---

[xbmcnut]

@localhost61 Thanks so much for your feedback and input. Can you confirm you have the 3.3V, GND and antenna connection on your 16-pin chip like mine (even though I may have the numbering wrong) that in no way match the PL1167? The PL1167 pinout shows the Xtal and Antenna pins on the same side but mine are opposite.

My problem is I have a USB debugger now and don't know what pins to connect it to.

[localhost61]

Today, I checked both drivers pinout and results are deceiving.

RGBCW

• Chips are SSOP with 3.3V power supply. The transceiver marking is erased. Do you know any RF24 transceiver in SSOP16 package?
• Pin 6 & 7: 12MHz crystal
• Pin 10: Antenna
• pin 9 & 15: Gnd ("G" test point)
• pin 12: VDD ("V" test point)
• pin 1 = IC1.3
• pin 2 = IC1.2
• pin 4 = IC1.1
• pin 13 = IC1.20
• pin 14 = IC1.19
• pin 16 = IC1.15
• pin 3, 5, 8 & 11 are tight together

About IC1, the N76E003AT20, its DataSheet says that SPI bus is located on pins 10,15,16,17 but I could see it's not used here as pin 10 is the Red output, and 17 the Green one.

• additionally pin 14 is Blue output, "R" Test point (for Receive?) is pin 4, "S" Test point (for Send?) is pin 18, with multimeter frequency is about 1kHz. Due to dangerous voltage present (LED strip output voltage is measured at 180V) I'm reluctant to plugin my Logical Analyzer here .
  
• On the main driver board, signals for CW and WW travel through a supplementary stage, a JL2233A (?) and it's the same on the RGBCW driver.

CCT


On the CCT driver, things are worse, chips are SOP like on the Remote but that's all, the second SOP8 chip is an I²C E²prom 24C02.

• SDA on pin 7, SCL on pin 8 of the RF24 transceiver
• Crystal is between pins 15 & 16
• Antenna on pin 2
• Gnd on pins 1 & 3
• VDD on pins 7 & 14

On my Remote (FUT007 clone see in previous post), it appears that :

• Crystal is between pins 14 & 15
• Antenna on pin 1
• Gnd on pin 16
• VDD on pins 2, 6 & 13
• /LED on pin 9
• I guess that the 8 remaining pins are used for the row and column of the 4x4 matrix of buttons.
  => Nothing to monitor with a Logic Analyzer and different chips are used for Transmit and Receive.

Maybe a RTL-SDR could be the monitoring option. I've received this one some weeks ago, it's bandwidth is large enough and I have the pigtails required to adapt on WiFi antennas. I may learn how to sniff data sent on the air.

[localhost61]

It seems I need a MMDS down converter to be able to sniff the air with my RTL-SDR. Order made.
See you in two weeks ;-)

[xbmcnut]

I thought you wanted to keep this open Chris?

[sidoh]

The official milight RGB remote now works.

It seems like you may have a different, probably non-milight device, which I don't think I can commit to supporting. Happy to revisit if you think that assessment is wrong, though.

[rryk]

@localhost61 I wonder if you have managed to sniff the data sent by the CCT remote you've described in the Aug 6-8 comments? I have the same remote (PINs and layout all match your description), so would love to either add support for it into this library or fork it.

[localhost61]

@rryk Sorry, I didn't put enough resources in it. Anyway, the driver is dead now. I just ordered it's successor. It will be WiFi.

[localhost61]

The problem with milight products it that they drive only constant voltage 12V/24V lights. My ceiling light uses 230mA constant current and at 48W the resulting voltage is above 100VDC. My other ceiling light is 36W RGB+CCT and if the driver die too, I'm not sure I'll be able to replace it.

[rryk]

Thank you for the quick answer. I have bought a lamp with this remote and would be happy to play with the NodeMCU / remote, which only work with low-voltage. However, I do not feel comfortable tinkering with high-voltage on the lamp itself, so I'll probably either ask an electrician to do it or just get myself some servos to push physical buttons on the actual remote :-).

[magicmicros]

I'm late to the party, but want to chime in with some info on the PL1167.
The datasheet posted here earlier (version 0.4, 2012), is NOT correct.
I have attached the correct datasheet (version 0.9, 2012).
I have also attached the User Manual for the PL1167.
As both are from the same supplier, just different versions, it's quite remarkable that the pinout is different.
Anyway, I have, over the last 5-6 years or so, made several designs based on the "real" pinout as well as replaced PL1167's on bulb boards and remotes. And checked the pinning towards that datasheet.
It works.

To make matters worse, there is (at least) one more pinout version, I saw on AliExpress once. I wanted to link to it, but was not able to find it again.
I've bought PL1167's from multiple suppliers there (Hong Kong CCD Limited, Keteling, e.t.c.)
All have been correct and working.

Hope this clears some things up and helps some.

PL1167_DS_EN_V0.9.pdf
PL1167_UM_EN_V0.2.pdf

[synio-wesley]

@localhost61 I also have a SOP16 SOC 2.4 GHz transceiver in my remote for a ceiling light I purchased a few weeks ago. The remote is pictured here:

The SOC looks very similar to the one in your blue circuit board remote.

While looking online, I found this datasheet: http://www.ledentech.com/uploadfile/HS6206_DataSheet_V0.6_20150302.pdf The HS6206 SOP16 version looks exactly like the one we have (see page 14 for a drawing). It has an embedded microcontroller, so that's probably why it's just one chip.

The datasheet I linked to is very detailed... it might help...?