Controlling a Trådfri bulb with nRF52840 - how to make it join?

[Ole Morten]

Hi,

I have an nRF52840 Development Kit, and am trying to control an IKEA Trådfri bulb. I'm following the commands from the SDK documentation, but it feels like they're missing a step, explaining how to make the bulb actually join the new network:

> bdb role zc
Coordinator set
Done
> bdb start
Started coordinator
Done
> bdb legacy enable
Done
> zdo match_desc 0xfffd 0xfffd 0xc05e 1 0 0
Sending broadcast request.
> 
Done

Between enabling legacy mode and doing the match_desc, I toggle power to the bulb 6 times, to factory reset it. However, it still doesn't show up anywhere.

I've also tried changing the channel mask, so that all channels are used, as it's not clear to me which channel the Trådfri system is using, but that apparently has no effect.

What am I missing? How can I instruct the bulb to join my newly formed network?

[Marjeris Romero]

Hi Ole,

When you factory reset the bulb, does the bulb start to "flash" after the 6th time? You need to be sure it actually has been reset. If you have problems resetting the plain white (non-colour) IKEA bulb, try making the "ons" very brief (less than a second) and the "offs" longer, this has fixed some of my problems earlier.

You can change the channel of the coordinator by using command 'bdb channel'. You can only open a network with a coordinator in one channel so changing the channel mask to all channels will not change that (but you can use this mask if using the CLI example as a router for example).

It's been a while since I have tried to connect with IKEA trådfri but they should send a beacon request on each channel after factory reset, so which channel you set the coordinator shouldn't matter. You can perhaps check that the bulb is sending beacon requests in the same channel as your coordinator by using the nRF Sniffer.

Best regards,

Marjeris

[Marjeris Romero]

Hi,

Small update, depending on which version of the Trådfri lightbulb you are using it may be using ZLL channels, so it would be best to test using channel 15 or channel 20 when testing.

Best regards,

Marjeris

[Ole Morten]

Hi again,

Writing a new reply, since the root cause turned out to not be what Marjeris Romero suggested, but a stupid mistake of my own. The short summary is that I needed to use gcc 7.2.1 instead of 9.2.1.

To give a bit more detail, I originally compiled the CLI example myself, but got two warnings:

../../../../../../../../components/zigbee/cli/zigbee_cli_cmd_zdo.c: In function 'cmd_zb_simple_desc_req_cb':
../../../../../../../../components/zigbee/cli/zigbee_cli_cmd_zdo.c:277:52: warning: taking address of packed member of 'struct zb_af_simple_desc_1_1_s' may result in an unaligned pointer value [-Waddress-of-packed-member]
  277 |     zb_uint16_t * p_cluster_list  = (zb_uint16_t *)p_resp->simple_desc.app_cluster_list;
      |                                                    ^~~~~~
../../../../../../../../components/zigbee/cli/zigbee_cli_cmd_zdo.c: In function 'cmd_zb_match_desc':
../../../../../../../../components/zigbee/cli/zigbee_cli_cmd_zdo.c:789:79: warning: taking address of packed member of 'struct zb_zdo_match_desc_param_s' may result in an unaligned pointer value [-Waddress-of-packed-member]
  789 |         if (!sscan_cluster_list(argv + 5, p_req->num_in_clusters, (uint16_t *)p_req->cluster_list))

I looked at the code, but concluded that there wasn't any clear, easy fixes, so I just removed  -Werror, assuming that this was a inconsequential warning that had somehow snuck past the release checks, without thinking more of it (MCU vendors supplying code with warnings is unfortunately not unheard of, although I was a bit surprised Nordic would do so).

However, after reading the answers, I realized I could test with an outlet instead of a bulb, since those are easier to factory reset (holding the button for 5 s). This unfortunately still didn't work, but it then struck me that I had never tried the precompiled hex files, so and when doing so it turned out the outlet was immediately joined.

Seeing that, I suddenly realized I was using a different compiler version than the SDK was supposed to be used with: arm-none-eabi-gcc 2019-q4 (9.2.1), from the Ubuntu repos. instead of 2018-q1 (7.2.1), originally referred to in Makefile.posix.

I therefore went back and downloaded 7.2.1 myself, and when recompiling with that, the warnings went away and the CLI worked as expected. Testing further, I also discovered that the example works when recompiling with 9.2.1 but without -Os.

The conclusion hence seems to be that there is some optimization that 9.2.1 does when compiled with -Os that causes the example to not work, and it's seems likely to be related to the warning given above. This hence may be worth fixing in a future SDK update.

Thanks for the help!