Are there any plans to add the UI to enable device’s firmware update job management (like it was the case in chirpstack v3 application-server?)
Thanks!
No… In my experience, different devices implement FUOTA in a slightly different way. Then the FUOTA specification is subject to change, thus over time, different devices might implement different FUOTA specification versions.
Therefore it is better to keep this out of ChirpStack and this was the reason to put it into an external application: GitHub - chirpstack/chirpstack-fuota-server: FUOTA server which can be used together with ChirpStack Application Server..
This way you can modify the server code if needed and mix and match versions over time. As well it allows you to use the FUOTA “building blocks” separately (e.g. to just initiate a multicast-session), without ChirpStack intercepting this data.
1 Like
What you say all makes sense.
If we consider the simplest FUOTA scenario with a single multicast group and a single fragmentation session, LoRaWAN FUOTA process is pretty much straightforward (thanks to the specification) until the whole process reaches parity fragment broadcasts and fragmentation session status request to end-devices where different strategies can be used.
Throw into the mix multiple multicast groups and split fragmentation session and it’s getting a little more tricky and very difficult to “streamline”.
In the meanwhile, i’ve written a simple python code that uses the gRPC API so I can get my hands on how chirpstack-fuota-server behaves. I discovered that i’ll have to modify the way frag session status takes place so that small consecutive batches of parity broadcast, followed by a multicast frag session setup is performed until all end-devices correctly reconstructed the payload, or failed because of not enough memory.
At most, it’d be nice to be able to start a deployment and configure whether FragSessionStatusReq will be sent unicast or multicast.
Since each device needs to confirm, would that become messy? E.g. if only 90 out of 100 do confirm with an Ans, you would need to re-transmit to the remaining 10, but that would be received by the others as well since we are using multicast and thus these devices will respond again with an Ans.
As well it means that all devices will be in multicast for a longer amount of time, thus using more power than if they would be when staying in unicast until the fragmentation-session starts.
Not if the server does not set the participants bit in the FragSessionReq payload.
As far as I know, LoRaWAN does not specify what devices shall or shall not do when they successfully reconstruct a datablock. Odds are if a device successfully reconstruct a datablock, they move on straight with the firmware upgrade process or they simply fall back to Class-A and leave the multicast group.
Isn’t this a flag available in FragSessionStatusReq and thus related to the fragmented data-transport?
If I understand you correctly, you are looking at:
- Starting the multicast session (setup using unicast)
- Then sending the
FragSessionSetupReqover this multicast session
I believe each device that receives a FragSessionSetupReq must respond with a FragSessionSetupAns. The participants flag that you refer to is not related to this command I think…
This is right.
No, FragSessionStatusReq over multicast.
Ah sorry, then I misread the original question. Yes, I guess that should be possible 
1 Like
Nice! Should I create a “Feature Request” issue on the project github?
EDIT: opened feature request issue on project github: Feature request: add the possibility to send FragSessionStatusReq via multicast rather than unicast · Issue #15 · chirpstack/chirpstack-fuota-server · GitHub
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.