Implement DFU feature about ios-nrf-mesh-library HOT 33 OPEN

I'll transition after I'll release the version 2. I'll be also fixing bugs after that.
The version 2 is almost ready, there are some more features I want to add, e.g. database migration from version 1.

from ios-nrf-mesh-library.

We understand, but I'm really busy with other things :(
And the official spec for mesh dfu isn't even released yet!

from ios-nrf-mesh-library.

I see... we checked the current DFU from others like Cypress and Silvair, they don't seem to be a "Mesh" DFU, instead they seem to update 1 device at the time using several (4) proxies as a "queue", my idea was to make something like that as a temporary solution.
However this brings few questions, for example all the nodes needs to have proxy enabled, we actually disable most of the proxies, then someone needs to go walking very slowly trough the whole site updating 1 device at the time... all in all this "mesh" BLE DFU doesn't seem a very good idea, but still maybe worth it as a temporary solution until the real Mesh DFU model comes from the SIG?

from ios-nrf-mesh-library.

Yes. With 4.0 released the DFU will come in 4.1. I need to switch to Android for a bit to fix some issues here and there and I'll start updating all my mesh nodes like a crazy person. Hopefully by end of this year you'll be able to join me and we will update the world!

from ios-nrf-mesh-library.

Great news! I will join you, the world will be updated by two crazy ones :)

from ios-nrf-mesh-library.

On Android DFU will come later. We're rewriting the lib in Kotlin (should make it public as soon as it's "usable enough") and we need to focus on implementing the basics first.

from ios-nrf-mesh-library.

I mean, in nRF Mesh app. Library will just have API to do whatever.

from ios-nrf-mesh-library.

I didn't memorize the whole DFU spec yet, like I did the other parts of mesh.

We will use mesh models for sending metadata, but will not use BLOB transfer to send the image to Distributor. Instead we'll use OOB method - McuManager. However, I'll try to implement the upload in transport agnostic way so users can choose other protocols. And, depending on complexity, perhaps we can add BLOB as well, just for completeness. As I said, this amazing novel is waiting for me.

from ios-nrf-mesh-library.

+1，Urgently need this feature to upgrade the entire network.

from ios-nrf-mesh-library.

We haven't spec'd this yet, but we are planning to do so this coming week, will keep you updated about the roadmap:)

from ios-nrf-mesh-library.

Nice! 👍👍👍

from ios-nrf-mesh-library.

Any future plans to add DFU to the sample app?

from ios-nrf-mesh-library.

Not in the coming months. I have to switch to another project for some time.

from ios-nrf-mesh-library.

Okay, when are you moving on? What will be the state of the application?

from ios-nrf-mesh-library.

+1 very important, a must have :)

from ios-nrf-mesh-library.

Hey @philips77 about the "And the official spec for mesh dfu isn't even released yet!" we also notice that it has being pushed back, originally expected on spring 2020 now its summer 2020... so got me thinking if maybe there is a case about implementing BLE DFU as a temporary solution? I wonder how difficult from the app and firmware would this be? is it temporary solution worth exploring? or the complexity for just few months is not really worth it?

from ios-nrf-mesh-library.

I didn't read the draft, so I don't know how much work would it require. We also don't have it out backlog now.

from ios-nrf-mesh-library.

I would like to ask a few questions about DFU:

1. Is there a DFU plan that supports the same device firmware in the Mesh network?

2. Understand that all current new functions only support NCS SDK, nRF5 SDK no longer updates new functions, only fix bugs, currently we are using firmware written by NCS SDK, chip memory must be 512K or more to support separate DFU, Is there a better way to support DFU for chip devices with 512K or less memory?

Thanks.

from ios-nrf-mesh-library.

Is there a DFU plan that supports the same device firmware in the Mesh network?

I'm afraid I don't understand.

Understand that all current new functions only support NCS SDK, nRF5 SDK no longer updates new functions, only fix bugs, currently we are using firmware written by NCS SDK, chip memory must be 512K or more to support separate DFU, Is there a better way to support DFU for chip devices with 512K or less memory?

Use an external flash memory to download the new firmware, MCUboot which is used for firmware update in NCS SDK can be used with external flash. For more information, please check infocenter or DevZone.

from ios-nrf-mesh-library.

Is there a DFU plan that supports the same device firmware in the Mesh network?

It means that only one device needs to be upgraded, and the Mesh network will automatically upgrade other devices of the same device type. For example, if there are five lights in the same network, one of the devices will be upgraded, and the other four will be upgraded automatically.

Thank you very much, it seems that the only way to increase external storage or use other chip models.

from ios-nrf-mesh-library.

So there will be many ways you may do DFU. The best one from mobile phone's point of view is indeed initiating DFU using mesh protocol, then sending a new firmware using a OOB (Out Of Band, not through mesh proxy service, but something much faster) and confirming with mesh protocol. Then the proxy node (with dfu capabilities) would be responsible for transferring it to all nodes registered during the initialization phase. You send once in 1 minute, and the image distribution takes very long time.

from ios-nrf-mesh-library.

Is this ever coming ?

from ios-nrf-mesh-library.

As far as I know, the official specification is still under development. Realistically speaking, I don't see it coming to mobile implementations in 2022.

from ios-nrf-mesh-library.

from ios-nrf-mesh-library.

it has been released: https://www.bluetooth.com/mesh-device-firmware-update/

;-) any hints @philips77 ?

from ios-nrf-mesh-library.

Fine too, let's get rock in iOS first 😎

from ios-nrf-mesh-library.

When basics first, then the initiator role is good starting point, right?

from ios-nrf-mesh-library.

For DFU - yes. For transport of the image we will use SMP protocol and nRF Connect Device Manager library, sending meta-data over mesh. Then the DFU proxy should take over and slowly forward the image to desired nodes. That way we'll get 30 kB/s from the phone instead of 0.01.

from ios-nrf-mesh-library.

For DFU - yes. For transport of the image we will use SMP protocol and nRF Connect Device Manager library, sending meta-data over mesh. Then the DFU proxy should take over and slowly forward the image to desired nodes. That way we'll get 30 kB/s from the phone instead of 0.01.

just to understand your reply better: do we get the mesh dfu (Models like BLOBTransfer, FirmwareDistribution and FirmwareUpdate cli/srv)?

or you refer the off-mesh DFU...

from ios-nrf-mesh-library.

thinking of speed, sure: faster is better :)

I think if the fw is moved to distributor, then the speed is not that relevand (distributor will push updates and network will be updated). It would be nice to see in the Lib the minimum required for the Initiator Role:

• Firmware Distribution Client
• Firmware Update Client
• BLOB Transfer Client
  then UI/Views can catchup later...

would that fit into our roadmap?

from ios-nrf-mesh-library.

Oh, that's a great plan! A sound-crazy-plan thing 🎢

from ios-nrf-mesh-library.

Hi, just a quick follow-up: any updates on this?

from ios-nrf-mesh-library.

Hi, it will come in few months. I'm busy with some other tasks at the moment, but DFU comes next.
Also, as we're working on a new Kotlin mesh library for Android, we want the new one to catch up with the is one in feature set, so we can start adding new features in parallel.

from ios-nrf-mesh-library.