Hmm.
When you put like that, then that does seem feasible.
Now that ARM has implemented this feature in their Mbed stack, I’m looking forward to finally integrate FUOTA into LoRa App Server. I’m looking forward to feedback on how you think you would use this feature.
So far, I’m thinking of adding support for the following options:
-
Upgrade an individual device. E.g. you would click on the device within the web-interface and upload the new firmware which would trigger a FUOTA process for this device only.
-
Upgrade all devices within an application. E.g. you would click on an application and upload the new firmware. This would then trigger a FUOTA profess for all devices within the given application.
Feedback is welcome 
4 Likes
Awesome, I’m trying to use multicast to update groups of end devices, but I need delta update due to my large firmware. Could delta updates be considered in the LoraServer FUOTA? Like, one way to send all the firmware in case of critical failure, and another way to send only the patch.
I believe LoRa App Server should not be aware of what it is sending, e.g. a full update, delta update, … This is application specific and also depends on what the application and / or bootloader of the device supports. So in short, yes, you would be able to use the FUOTA to do delta updates, given that your device supports this
1 Like
Any news? How are you proceeding with FUOTA implementation?
Keep up the good work!
I really appriciate that FUOTA comes to this greate project!
Still, open questions for me are:
Think of a big deployment of heterogenous nodes, where heterogenous means different nodes from different vendors, as well as same nodes on different firmware versions.
The first scenario can easily be manage via applications: just put separate device types into different applications.
But, how would you manage the second scenario?
Would you move devices on different firmware versions between applications?
Would you manage versions in loraserver.io directly?
What if you do not know the firmware version a priori?
What if updating fails for some of the devices, e.g., due to a bad connection?
…
I know that some (if not all) of these questions have to be answered/handled within the application. But what will happen then? Will everyone implement its own update process? How will the management of those different processes be done? How will the LNS handle this ressouce consuming so that the network can still work?
To do this intelligently (things like prioritizing downlink capacity, gateway aware multicasting, …) the either the application of the LNS needed information of the other party which they currently do not have.
If it was up to me, I think I’d propose a new component (something like a update server) which would handle the firmware related things like versioning, prioritizing, etc. Maybe it would be tightly coupled to the LNS to do things intelligently, maybe it only uses the specified functionalities for multicast, fragmentation, …
I think for now, however, there is no specification on how the actual update process will take place, which makes such a component a thing of the future.
(I’m not even sure, if specification of an update process is even possible, if we consider the different requirements which arise from different deployments.)
As far as I know, the LoRaAlliance only specified how multicast groups are setup (LoRaWAN Remote Multicast Setup Specification v1.0.0.), how big data packets can be fragemented and sent via these groups (LoRaWAN Fragmented Data Block Transport Specification v1.0.0.), and how colock synch can be done, so that all devices can agree on the start of the multicast session.
There are proposals of how firmware files and update processes should look like (I’ve seen documents from mbed guys, as well as semtech; the latter one even tries to describe what specific tasks have to be done by which participant of the LoRaWAN infrastructur (interestingly, they propose a US (update server) as well, as they also seem to have undertood, that updating is not that trivial).
To make things short:
I think your porposal to upload files directly to (either device or application based) will only work for very simple deployments but it might be sufficient for the first shot.
To make this thing usable in real world environments, it takes a lot more -> a new update server component should be implemented, which handles this stuff.
To enable other parties to implement such server, the LSN should provide some APIs for the currently specified functionalities (Multicast, Fragmented Downlinks, …), so that these features can be used comfortably by a separate component and concerns can be separated cleanly.
Btw., are you aware of any resources or a specification which may cover (parts of) my questions?
I agree that per device or application is a simple implementation. It is a first shot and I think we all need to see how the FUOTA is going to move forward. Please note, the whole FUOTA implementation is implemented in the application-layer, thus you could already create your own separate update server I believe the only APIs you would need are the multicast-group and device-queue APIs which are already available.
I’ve already open-sourced the modules that you can use to create the multicast-setup / clocksync and fragmentation-session payloads: https://godoc.org/github.com/brocaar/lorawan/applayer.
Actility has a working multicast network server in place make FUOTA available today in production
@brocaar I see FUOTA is still marked as experimental and also the documentation states “Application Server only supports firmware update jobs to single devices”. Is this correct? If so, are there plans for getting multicast FUOTA fully supported?
2 Likes
Any tips if we can implement multicast FUOTA support ourselves without patching and recompiling whole app-server @brocaar? It seems that FUOTA is a bit forgotten
I’m planning to release an update on FUOTA pretty soon! In short, I’m planning to completely decouple it from the ChirpStack Application Server and offer it as a stand-alone component. That makes it easier for me to maintain and for users to implement their own FUOTA / customize the stand-alone component to their own needs. Stay tuned
11 Likes
Hi there,
Can https://github.com/brocaar/chirpstack-fuota-server already be used for simple testing of FUOTA? I don’t really understand how this chirpstack-fuota-server mixes into the rest of ChripStack. I did add an API key to the configuration, but what are the following steps to operate the chirpstack-fuota-server? I hope you have some time to answer my questions, kind regards.
The FUOTA server integrates with the ChirpStack Application Server (it receives the uplinks using the HTTP integration and sends the downlinks using the ChirpStack Application Server gRPC API).
For creating a FUOTA deployment, you need to integrate with the ChirpStack FUOTA Server gRPC API, which is specified in this document: https://github.com/brocaar/chirpstack-api/blob/master/protobuf/fuota/fuota.proto#L14.
Thanks for your reply @brocaar. If I understand it correctly, ChirpStack already had FUOTA but with unicast and I thought that the fuota.proto calls were meant for that. But if I set up the separate FUOTA server correctly, will it replace this API for a real multicast update session? Or am I understanding it wrong?
Anyway, thanks for your time.
EDIT: Ow wait you said ChirpStack FUOTA API, not the API of the Application server. I understand now better
Is there a ubuntu repo available for the chirpstack-fuota-server? It would be easyer for me.
Thanks
It is in the testing channel
Is there a video or tutorial about real-deployment fuota using chirpstack?
I am now trying to implement this repo (https://github.com/ARMmbed/mbed-os-example-lorawan-fuota), but it seems that I am not clear about how to connect chirpstack server after I successfully built the program, plus some changes of chirpstack during this period?
Great thanks!
@Sun1998 chirpstack-fuota-server replaces the node js fuota server in the ARMmbed example you posted. Or, are you using that repo only for the device/node side of fuota? If so, can you elaborate on where your challenges are? Have you gone through the readme at https://github.com/brocaar/chirpstack-fuota-server and/or tried the example deployment script in the repo?