DFU compatibility for a mesh example

[DeveloperZ]

Hi,

I am interested to know how to make a mesh node (for example, a light server) compatible to perform a DFU.

I have gone through the DFU page and I noticed that the DFU is done over the Serial port. I understand that the dfu firmware is being replaced with blinky firmware. Correct me if I am wrong.

Now, what changes should I make to the commands inorder to make the light_server example node to be DFU compatible/capable over the air?

Would replacing the application hex file on step 8 to light_server instead of dfu solve it? or should I add any other commands to have light_server firmware first?

Thank you.

[DeveloperZ]

Hi,

Now that I have the DFU running,

Edvin said:

The short answer is that you need the mesh_evt_handler() to handle DFU packets,

I will try to add this functionality into other examples which don't have DFU capability and will be back with the update on that.

Thank you.

[DeveloperZ]

Hi,

I was able to successfully add the DFU capabilities into the Enocean_switch node, I was able to push the Blinky dfu to it and it was done successfully. Then, I tried to push a DFU packet with a customized mesh example hex file which understandably takes around 90mins.

Next, I am thinking about differentiating the DFU packets as my network might have multiple firmwares. 
My best idea is differentiating the application id in the bootloader.json file. Is there any other way(can be easy or not) to differentiate the firmware updates.

Feel free to criticize my ideas and point out the best way.

Thank you. 

[Edvin]

Hello,

You are correct. The application ID is intended for exactly this. If you have several types of nodes in your network, you can differentiate them using the application ID. Note that all the nodes in your network will still retransmit the DFU packets (like it would with any other Mesh packet), in case there are some other nodes that are not in range of the original publisher that needs this update. 

Just be aware that when you are testing the DFU from the getting started guide, and you have more nodes, you may notice that these nodes are not actually in a network. They are not provisioned at any point. The DFU runs outside the encryption of the network, but your nodes will only accept packets that are using the same keyset and manufacturer ID as your nodes use in your device page.

Best regards,

Edvin

[DeveloperZ]

Edvin said:

If you have several types of nodes in your network, you can differentiate them using the application ID

So, If I were to have only one node as the gateway to push all the DFU updates into the mesh, I need to have a different device page on the gateway node every time I push a different firmware?

in other words, does the gateway node check the application id after the update is successfully loaded onto mesh or initially when we try to push the update?

Because the device page that is flashed on the gateway node might have a different application id and that varies with every new firmware that is being updated.

[DeveloperZ]

Edvin said:

Just be aware that when you are testing the DFU from the getting started guide, and you have more nodes, you may notice that these nodes are not actually in a network. They are not provisioned at any point. The DFU runs outside the encryption of the network

Just to make sure, the nodes need not be connected in a mesh network? 

Yesterday when I tried to push the DFU on the Enocean switch example to which I added the DFU functionality, it was pushing to only one device but not both. I thought that provisioning was required. If they need not be provisioned then, I need to try the process again and see the result!!