[Zigbee] FOTA, light_switch sample

[Pawel(embeddedsolutions.pl)]

Hello,

I am playing around the Zigbee samples provided by nRF Connect SDK v2.2.0.

I would like to know how to test FOTA functionality implemented in light_switch sample.

This is what I have done since today :

1. Device 1: nrf52840dk with network_coordinator sample
2. Device 2: nrf52840dk with light_bulb sample
3. Device 3: nrf52840dk with light_switch sample
4. Device 4: nrf52840 dongle configured as nRF Sniffer for 802.15.4
5. Device 5: nrf52840dk configured as FOTA server.

All devices successfully created a Zigbee network and I am able to send commands by using On/Off or Level Control clusters.

What I am trying to do is to perform FOTA. After building light_switch sample I noticed that Zephyr generates the .zigbee package for FOTA in build directory, so the only thing I do to setup a FOTA server is running that command for nRF Util :

./nrfutil dfu zigbee -f 127F-0141-01020003-light_switch.zigbee -chan 16 -snr 683954443

I analyzed the frames in Wireshark and I spot that FOTA server sends a Beacon requests to join to network and after a while it successfully becomes a valid member of network. After that it sends the broadcast messages called "OTA Image Notify" to notify all OTA clusters that new image is available. The light_switch device calls the zigbee_fota_zcl_cb but unfortunately it jumps to the default case :

	default:
		LOG_INF("FOTA zcl cb RET_NOT_IMPLEMENTED");
		device_cb_param->status = RET_NOT_IMPLEMENTED;
		break;
	}

As a result Zigbee FOTA procedure is not even started.

What I would like to know is :

1. Is everything ok with my setup ?
2. Is that way of testing FOTA ok ? or maybe there is another way to do that ?
3. Is light_bulb node needed in network for testing FOTA ?

Thanks in advance,

Pawel

[Pawel(embeddedsolutions.pl)]

Hi,

I figured it out. I wrongly assumed that FOTA checks CRC rather than application version of new firmware before starting FOTA procedure.

Changing
CONFIG_MCUBOOT_IMAGE_VERSION="1.2.4"
to version different than that one stored currently on device solves the problem.


Additionally I would like to clarify things regarding wrong cluster id printing. It is simply because I made a mistake. I took the cluster ID from the struct which holds data for ZB_ZCL_WRITE action 
zb_uint16_t cluster_id = device_cb_param->cb_param.set_attr_value_param.cluster_id;
That is a wrong approach. If you would like to categorize actions in zcl_device_cb by clusters you have to use the frame header
data which contains cluster_id like this: 

zb_zcl_parsed_hdr_t cmd_info = {0};

ZB_ZCL_COPY_PARSED_HEADER(bufid, &cmd_info);

zb_uint16_t cluster_id = cmd_info.cluster_id;