Proposal: Structured progress messages for SWUpdate / hawkBit UI integration

Ihor Fedorenco

unread,

Apr 6, 2026, 8:55:03 AMApr 6

to swupdate

Hi Stefano,

I’m continuing the discussion from the hawkBit thread:
https://github.com/eclipse-hawkbit/hawkbit/issues/2868#issuecomment-4191718757

Following the feedback there, it seems clear that extending hawkBit backend for progress reporting is not aligned with its architecture (DB impact, DDI load, etc.).

Given that, I’m exploring an alternative approach on the device + UI side, and I would like your opinion.

Since hawkBit already supports arbitrary details/messages, would it make sense to standardize a lightweight, structured message format for reporting device-side progress from SWUpdate?

For example:

progress phase=download percent=45 progress phase=install percent=12 progress phase=done percent=100

The idea is:

SWUpdate / suricatta emits structured progress messages via details
hawkBit stores them unchanged
hawkbitUI (or other clients) optionally parses and visualizes progress

This would:

avoid any backend or DB changes in hawkBit
stay fully backward compatible
provide a consistent way to expose progress for headless devices
improve over ad-hoc messages like “Downloaded 45%”

From the SWUpdate perspective, this seems like a small addition (formatting existing progress into a consistent structure), but it could significantly improve integration with hawkBit UI and similar tools.

Do you think such a convention would be acceptable for SWUpdate (even as an optional feature)?

Stefano Babic

unread,

Apr 8, 2026, 8:55:50 AMApr 8

to Ihor Fedorenco, swupdate

Hu Fedorenco,

On 4/6/26 14:38, Ihor Fedorenco wrote:
> Hi Stefano,
>
> I’m continuing the discussion from the hawkBit thread:
> https://github.com/eclipse-hawkbit/hawkbit/

> issues/2868#issuecomment-4191718757 <https://github.com/eclipse-hawkbit/
> hawkbit/issues/2868#issuecomment-4191718757>

>
> Following the feedback there, it seems clear that extending hawkBit
> backend for progress reporting is not aligned with its architecture (DB
> impact, DDI load, etc.).

Hawkbit does not allow to send a lot of logs - there is some specific
set up in SWUpdate to split logs in parts and to overcome Hawkbit
limitations.

>
> Given that, I’m exploring an alternative approach on the *device + UI
> side*, and I would like your opinion.

>
> Since hawkBit already supports arbitrary details/messages, would it make
> sense to standardize a lightweight, structured message format for
> reporting device-side progress from SWUpdate?
>
> For example:
>
> progress phase=download percent=45 progress phase=install percent=12
> progress phase=done percent=100
>

But well, this is *already* done and used, so I do not know what you want.

This is part of "Feedback channel for the DeploymentBase action "

The anser is already a structured message as specifie4d by the API:

{

"status": {
"execution": "closed",
"result": {
"finished": "success",
"progress": {
"cnt": 2,
"of": 5
}
},
"code": 200,
"details": []
},
"timestamp": 1627997501890

}

And SWUpdate sends *exactly* this message. SWUpdate uses the "details"
to push its logs, and this can be opened in the Hawkbit's GUI.

> The idea is:
>
> *

>
> SWUpdate / suricatta emits structured progress messages via details
>

It is already done, but Hawkbit doesn't parse it. Details[] contain the
logs.

> *
>
> hawkBit stores them unchanged
>
> *

>
> hawkbitUI (or other clients) optionally parses and visualizes progress
>

Logs are already shown in the GUI.

> This would:
>
> *

>
> avoid any backend or DB changes in hawkBit
>

> *
>
> stay fully backward compatible
>
> *

>
> provide a consistent way to expose progress for headless devices
>

> *

>
> improve over ad-hoc messages like “Downloaded 45%”
>
> From the SWUpdate perspective, this seems like a small addition
> (formatting existing progress into a consistent structure), but it could
> significantly improve integration with hawkBit UI and similar tools.
>
> Do you think such a convention would be acceptable for SWUpdate (even as
> an optional feature)?

The details[] array was already used, SWUpdate sends a structured
message, and logs are already shown by the GUI. However, the progress
data are ignored by Hawkbit.

Best regards,
Stefano Babic

--
_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail: sba...@nabladev.com

Ihor Fedorenco

unread,

Apr 8, 2026, 10:57:36 AMApr 8

to swupdate

thank you for the clarification — that helped a lot to understand the current behavior.

Yes, I see that SWUpdate already sends structured progress (cnt/of) and that logs (details[]) are available and shown in hawkBit.

What I’m trying to address is slightly different — more on the UI/UX side for headless devices.

In scenarios with:

large artifacts
slow or unstable connections
no local UI on the device

it becomes important to have a clear, visual representation of progress (download/install), similar to what SWUpdate provides locally (web UI / display).

At the moment:

structured progress (cnt/of) is not exposed by hawkBit
logs can contain progress, but require higher verbosity and parsing
the UI does not provide a consolidated “device progress view”

So the question is:

within the current architecture, what would be the recommended way to surface a concise, visual progress state in hawkBit UI?

For example:

download progress bar
install phase indication
possibly artifact-level progress

without relying on verbose logs or backend changes
for example to extend target with progress column

To give a concrete example from the UI perspective:

it could be useful to extend the target table with a simple “Progress” column, showing a concise device state derived from feedback.

This would provide a quick, at-a-glance view for headless devices (especially with large artifacts or slow connections), without requiring users to open logs and inspect detailed messages.

Very simplified image:

Best regards
Ihor,

середа, 8 квітня 2026 р. о 15:55:50 UTC+3 Stefano Babic пише:

shared image (1).jpeg

Stefano Babic

unread,

Apr 8, 2026, 1:00:32 PMApr 8

to Ihor Fedorenco, swupdate

Hi Ihor,

On 4/8/26 16:57, Ihor Fedorenco wrote:
> thank you for the clarification — that helped a lot to understand the
> current behavior.
>
> Yes, I see that SWUpdate already sends structured progress (cnt/of) and
> that logs (details[]) are available and shown in hawkBit.

This is generally enough.

>
> What I’m trying to address is slightly different — more on the *UI/UX
> side for headless devices*.
>
> In scenarios with:
>
> * large artifacts

=> always

> * slow or unstable connections

=> often

> * no local UI on the device

==> if we have Hawkbit, a device can have a HMI, but it is not accessible

So there is nothing new - this is a common scenario.

>
> it becomes important to have a clear, visual representation of progress
> (download/install), similar to what SWUpdate provides locally (web UI /
> display).

Well, I just provide the differences. Using SWUpdate's WebUI, the
software is pushed to the device in the same timeline when the display
is showed. Sure having a display or Webbrowser to show the progress is
very comfortable, but it is also a different use case.

With Hawkbit, we have generally rollouts. We want to provide updates for
thousands of devices. Devices maybe polls the server once a day, so
constantly looking at the progress makes less sense. The update itself
can run slowly, because bandwidth is maybe limited. What is important is
to get if an update fails (and this is reported by Hawkbit), and when it
happens, to get the logs to identify the reason (and this is done as well).

Consider also that SWUpdate is not allowed to send constantly logs to
the Hawkbit server. The default value in application.properties for
Hawkbit is very restrictive. There is a DOS (deny of service) property
in the Hawkbit server, and if SWUpdate sends too many messages, they are
silently dropped. So from design, Hawkbit's developers do not want to
have a lot of data coming from the device.

To have a functional progress, SWUpdate should send continuously new
data when something is changed. For example, percentage of downloaded
data (1..100), progress bar for each step, etc. All these information
are sent via the progress interface and the internal Webserver sends via
Websocket to any connected browser. Then yes, the visual representation
(WebUI / local) is responsive.

I guess that what is disturbing for the Hawkbit's developers is that
they cannot then control how much traffic the devices will generate.

>
> At the moment:
>
> * structured progress (cnt/of) is not exposed by hawkBit

But it is also not exposed to the REST API, so the GUI has no access.

> * logs can contain progress, but require higher verbosity and parsing
> * the UI does not provide a consolidated “device progress view”

Ok, let's see what I can discuss on my side.

- Hawkbit API: this cannot be changed if developers do not agree and
they do not agree.

- SWUpdate: this can be extended
- HawkbitGUI: this can be extended and we can make what we want, but we
have to use the REST API. At the moment, the GUI resembles the features
of the old GUI (until Hawkbit 0.4), but sure it can have another UX.

>
> So the question is:
>
> within the current architecture, what would be the recommended way to

> surface a *concise, visual progress state* in hawkBit UI?
>
> For example:
>
> * download progress bar
> * install phase indication
> * possibly artifact-level progress

>
> without relying on verbose logs or backend changes

I can change SWUpdate and the GUI. But in any case, this raises more
traffic (and it is an issue on lowband connection, mobile, GSM, etc.)

It will be nice to send logs just on demand, that is if Update fails,
but there is not REST API for this.

> for example to extend target with progress column
>
> To give a concrete example from the UI perspective:
>
> it could be useful to extend the target table with a simple “Progress”
> column, showing a concise device state derived from feedback.
> > This would provide a quick, at-a-glance view for headless devices

If we are using Hawkbit, all of them are headless, even the ones from
display. But how can we differentiate in base of bandwidth requirements ?

> (especially with large artifacts or slow connections), without requiring
> users to open logs and inspect detailed messages.
>

Targets are also loaded - that means, if the progress is always shown,
this causes a massive amount of data during the scroll of the target
window. And if I remember well, the targets must be individually asked,
that means each of them cause an additional GET to the server.

Best regards,
Stefano Babic

> Very simplified image:
>
> Best regards
> Ihor,
>
> середа, 8 квітня 2026 р. о 15:55:50 UTC+3 Stefano Babic пише:
>
> Hu Fedorenco,
>
> On 4/6/26 14:38, Ihor Fedorenco wrote:
> > Hi Stefano,
> >
> > I’m continuing the discussion from the hawkBit thread:

> > https://github.com/eclipse-hawkbit/hawkbit/ <https://github.com/
> eclipse-hawkbit/hawkbit/>
> > issues/2868#issuecomment-4191718757 <https://github.com/eclipse-
> hawkbit/ <https://github.com/eclipse-hawkbit/>

> Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596>

> Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> E-Mail: sba...@nabladev.com
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/bbd2955b-9e7b-45af-8d27-bd8f037a8c60n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/bbd2955b-9e7b-45af-8d27-
> bd8f037a8c60n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Ihor Fedorenco

unread,

Apr 9, 2026, 8:32:43 AMApr 9

to swupdate

Hi Stefano,
thanks, this clarifies the concern about scalability and data access.
I understand now that the main limitation is not the data itself, but how it is accessed:

/status is available per target
but fetching it for all targets (or during scrolling) would lead to too many requests
so any UI feature must avoid per-target polling in the table view

Given that, I see the following constraints:

no additional requests per target while rendering the table
logs should be fetched only on demand or in a controlled manner (as currently done)

So instead of fetching logs for every target, a possible approach would be:

keep the table view based on already available data
optionally enrich only a limited subset of targets (e.g. active updates or a selected target)
cache /status results and avoid repeated requests

In this model:

no additional load is introduced during scrolling
logs remain the source of truth and are still accessed on demand
the UI can provide a lightweight, best-effort summary only where relevant

Does this approach align better with the design constraints,
or would you recommend avoiding this entirely and keeping the UI strictly log-based?

середа, 8 квітня 2026 р. о 20:00:32 UTC+3 Stefano Babic пише:

Stefano Babic

unread,

Apr 9, 2026, 10:44:15 AMApr 9

to Ihor Fedorenco, swupdate, Xavier Patricio Garcia Bano, Daniel García

Hi Ihor,

On 4/9/26 14:32, Ihor Fedorenco wrote:
> Hi Stefano,

> thanks, this clarifies the concern about scalability and data access.
> I understand now that the main limitation is not the data itself, but
> how it is accessed:
>

> * /status is available per target
> * but fetching it for all targets (or during scrolling) would

> lead to too many requests

> * so any UI feature must avoid per-target polling in the table view
>

There is not a group API. So there is a GET to retrieve the list of
target, one to get the list of actions for each target and then it is
possible to run the GET for a target and a specific action.

> Given that, I see the following constraints:
>

> * no additional requests per target while rendering the table
> * logs should be fetched only on demand or in a controlled manner
> (as currently done)
>

This is already supported, and it is how it is currently implemented.
You have to select a target to get the logs.

> So instead of fetching logs for every target, a possible approach would be:
>

> * keep the table view based on already available data
> * optionally enrich only a limited subset of targets (e.g. active

> updates or a selected target)

> * cache /status results and avoid repeated requests
>

To do what ?

The /status API does not report what SWUpdate has sent. We get:

PagedListMgmtActionStatus{
content* [MgmtActionStatus{
id [...]
type [...]
messages [...]
reportedAt [...]
timestamp [...]
code [...]
}]

> In this model:
>
> * no additional load is introduced during scrolling
> * logs remain the source of truth and are still accessed on demand
> * the UI can provide a lightweight, best-effort summary only

It is not clear to me what you are proposing.

> where relevant
>
> Does this approach align better with the design constraints,
> or would you recommend avoiding this entirely and keeping the UI
> strictly log-based?

Best regards,
Stefano Babic

> github.com/eclipse-hawkbit/hawkbit/> <https://github.com/ <https://
> github.com/>
> > eclipse-hawkbit/hawkbit/>
> > > issues/2868#issuecomment-4191718757 <https://github.com/
> eclipse- <https://github.com/eclipse->
> > hawkbit/ <https://github.com/eclipse-hawkbit/ <https://

> +49%20821%2045592596> <tel:

> > +49%20821%2045592596>
> > Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> > E-Mail: sba...@nabladev.com
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > swupdate/bbd2955b-9e7b-45af-8d27-bd8f037a8c60n%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/swupdate/
> bbd2955b-9e7b-45af-8d27- <https://groups.google.com/d/msgid/
> swupdate/bbd2955b-9e7b-45af-8d27->
> > bd8f037a8c60n%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?

> utm_medium=email&utm_source=footer>>.
>
> --
> _______________________________________________________________________
> Nabla Software Engineering GmbH

> Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596>
> Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> E-Mail: sba...@nabladev.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> swupdate/853dcf5a-c665-4ec4-a621-8656b6b7771fn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4-
> a621-8656b6b7771fn%40googlegroups.com?utm_medium=email&utm_source=footer>.

Ihor Fedorenco

unread,

Apr 10, 2026, 3:12:02 AMApr 10

to swupdate

Hi Stefano,
thank you for your time and for the detailed explanations so far.

and
let me restate the requirement clearly:
the goal is to show percentage-based progress (e.g. download / install % / count of artifacts) in the UI.
From what I understand:

hawkBit does not expose structured progress via REST
continuous updates via logs are limited and not reliable
additional polling or frequent updates are not acceptable due to scalability constraints

So it seems that accurate percentage-based progress is not supported by design.
At the same time, this is a requirement to improve.
So I would like to ask directly:
within these constraints, do you see any acceptable way to approximate progress in the UI, even as a best-effort solution?
For example, using:

sparse signals from logs
coarse milestones
or any other approach that would not increase load or interfere with existing behavior

Or should this be considered out of scope for hawkBit entirely?
This will help me decide whether to:

implement a local workaround, or
design a separate solution for progress monitoring.

четвер, 9 квітня 2026 р. о 17:44:15 UTC+3 Stefano Babic пише:

Stefano Babic

unread,

Apr 11, 2026, 5:30:40 AMApr 11

to Ihor Fedorenco, swupdate

Hi Ihor,

On 4/10/26 09:12, Ihor Fedorenco wrote:
> Hi Stefano,

> thank you for your time and for the detailed explanations so far.
>
> and
> let me restate the requirement clearly:
> the goal is to show percentage-based progress (e.g. download / install
> % / count of artifacts) in the UI.
> From what I understand:
>

> * hawkBit does not expose structured progress via REST
> * continuous updates via logs are limited and not reliable
> * additional polling or frequent updates are not acceptable due to

> scalability constraints
>
> So it seems that accurate percentage-based progress is not supported by
> design.
> At the same time, this is a requirement to improve.
> So I would like to ask directly:
> within these constraints, do you see any acceptable way to
> approximate progress in the UI, even as a best-effort solution?

The most efficient way is to have a REST that collects status for
multiple targets. Something like:

http://localhost:53002/rest/v1/targets/targets/action/status

where as query parameter the list of targets is sent, that corresponds
to the targets that are currently showed on the table in the GUI.

> For example, using:
>
> * sparse signals from logs
> * coarse milestones
> * or any other approach that would not increase load or interfere
> with existing behavior
>

If there is no way to improve the REST API, a "work-around" SWUpdate
sends first as mfirst message in "details" a JSON formatted string with
the progress status. This allows to have a nice view, but the point is
that each showed target (or selected target, better) generates a GET to
the server. Not really efficient. I cannot say if the UX will be enough
responsive, or what should be done. The GUI must then polls the server
continouosly, it is also something to be tested.

> Or should this be considered out of scope for hawkBit entirely?

For Hawkbit developers this is not a priority. I do not know if someone
(are you planning to do this ?) post a patch to the Hawkbit server to
extend the REST, if this will be merged. It is something that must be
verified before starting.

> This will help me decide whether to:
>

> * implement a local workaround, or

What is a local workaround if device is headless and nothing can be
displayed ?

> * design a separate solution for progress monitoring.
>

Does it mean a different server, new protocol, etc. ? This is
overkilling IMHO.

Best regards,
Stefano Babic

> > github.com/eclipse-hawkbit/hawkbit/ <http://github.com/eclipse-
> hawkbit/hawkbit/>> <https://github.com/ <https://github.com/> <https://
> > github.com/ <http://github.com/>>
> > > eclipse-hawkbit/hawkbit/>
> > > > issues/2868#issuecomment-4191718757 <https://github.com/
> <https://github.com/>
> > eclipse- <https://github.com/eclipse- <https://github.com/eclipse->>

> > > hawkbit/ <https://github.com/eclipse-hawkbit/ <https://

> github.com/eclipse-hawkbit/> <https://
> > github.com/eclipse-hawkbit/ <http://github.com/eclipse-hawkbit/>>>

> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>>
> > > swupdate/bbd2955b-9e7b-45af-8d27-
> bd8f037a8c60n%40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <https://groups.google.com/d/msgid/swupdate/ <https://
> groups.google.com/d/msgid/swupdate/>
> > bbd2955b-9e7b-45af-8d27- <https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/>
> > swupdate/bbd2955b-9e7b-45af-8d27->
> > > bd8f037a8c60n%40googlegroups.com <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?

> > utm_medium=email&utm_source=footer>>.
> >
> > --
> >
> _______________________________________________________________________
> > Nabla Software Engineering GmbH
> > Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:

> +49%20821%2045592596> <tel:
> > +49%20821%2045592596>
> > Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> > E-Mail: sba...@nabladev.com
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/>

> > swupdate/853dcf5a-c665-4ec4-a621-8656b6b7771fn%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4-
> <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4->
> > a621-8656b6b7771fn%40googlegroups.com?

> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
> --
> _______________________________________________________________________
> Nabla Software Engineering GmbH
> Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596>
> Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> E-Mail: sba...@nabladev.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> swupdate/e7a5030b-ed45-4d06-a6d5-cc91dbea633dn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/e7a5030b-ed45-4d06-a6d5-
> cc91dbea633dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

Ihor Fedorenco

unread,

Apr 12, 2026, 5:19:14 AMApr 12

to swupdate

Hi Stefano,
thanks — I think there was a misunderstanding in my previous message.
By “local workaround” I did NOT mean something on the device (like a local UI or display).
What I meant was:
a workaround within the existing hawkBit communication flow,
by reusing the `details[]` field to transport structured progress information (e.g. JSON), and then parsing it in the UI.
So effectively:
* SWUpdate sends structured progress inside `details[]`
* hawkBit stores it unchanged
* the UI interprets it
No additional APIs or protocols involved.

Separately, when I mentioned “a separate solution”, I meant introducing an additional telemetry channel outside hawkBit (which I understand you consider overkill).

>For Hawkbit developers this is not a priority. I do not know if someone
>(are you planning to do this ?)

Given the effort required to extend the REST API and my current limitations on the backend side(hawkbit, DB, N+1 request problem),
I will proceed with the `details[]`-based approach as a best-effort solution.
I understand this is not a perfect or fully scalable solution, but it should be sufficient for our use case.

Thanks again for the guidance — it helped to choose a realistic path forward.

субота, 11 квітня 2026 р. о 12:30:40 UTC+3 Stefano Babic пише:

Stefano Babic

unread,

Apr 12, 2026, 7:13:06 AMApr 12

to Ihor Fedorenco, swupdate

Hi Ihor,

On 4/12/26 11:19, Ihor Fedorenco wrote:
> Hi Stefano,

> thanks — I think there was a misunderstanding in my previous message.
> By “local workaround” I did NOT mean something on the device (like a
> local UI or display).
> What I meant was:
> a workaround within the existing hawkBit communication flow,
> by reusing the `details[]` field to transport structured progress
> information (e.g. JSON), and then parsing it in the UI.

Ok

> So effectively:
> * SWUpdate sends structured progress inside `details[]`
> * hawkBit stores it unchanged
> * the UI interprets it
> No additional APIs or protocols involved.
>
> Separately, when I mentioned “a separate solution”, I meant introducing
> an additional telemetry channel outside hawkBit (which I understand you
> consider overkill).

This opens a lot of security issues, that are already solved using Hawkbit.

>
> >For Hawkbit developers this is not a priority. I do not know if someone
> >(are you planning to do this ?)
> Given the effort required to extend the REST API and my current
> limitations on the backend side(hawkbit, DB, N+1 request problem),
> I will proceed with the `details[]`-based approach as a best-effort
> solution.
> I understand this is not a perfect or fully scalable solution, but it
> should be sufficient for our use case.
>

Ok

Please do not forget that SWUpdate and the hawkbitGUI are both GPL
licensed projects, and if you extend them please consider to post and/or
public these changes.

> Thanks again for the guidance — it helped to choose a realistic path
> forward.

You're welcome.

Best regards,
Stefano Babic

> hawkbit/hawkbit/> <http://github.com/eclipse- <http://github.com/
> eclipse->

> > hawkbit/hawkbit/>> <https://github.com/ <https://github.com/>
> <https://github.com/ <https://github.com/>> <https://

> > > github.com/ <http://github.com/> <http://github.com/ <http://

> github.com/>>>
> > > > eclipse-hawkbit/hawkbit/>
> > > > > issues/2868#issuecomment-4191718757 <https://github.com/
> <https://github.com/>
> > <https://github.com/ <https://github.com/>>

> > > eclipse- <https://github.com/eclipse- <https://github.com/

> eclipse-> <https://github.com/eclipse- <https://github.com/eclipse->>>
> > > > hawkbit/ <https://github.com/eclipse-hawkbit/ <https://
> github.com/eclipse-hawkbit/> <https://
> > github.com/eclipse-hawkbit/ <http://github.com/eclipse-hawkbit/>>
> <https://
> > > github.com/eclipse-hawkbit/ <http://github.com/eclipse-hawkbit/

> > <http://github.com/eclipse-hawkbit/ <http://github.com/eclipse-

> > msgid/ <https://groups.google.com/d/msgid/ <https://

> groups.google.com/d/msgid/>>
> > > <https://groups.google.com/d/msgid/ <https://groups.google.com/

> d/msgid/> <https://groups.google.com/d/ <https://groups.google.com/d/>

> > msgid/>>
> > > > swupdate/bbd2955b-9e7b-45af-8d27-
> > bd8f037a8c60n%40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>
> > > > <https://groups.google.com/d/msgid/swupdate/ <https://

> groups.google.com/d/msgid/swupdate/> <https://
> > groups.google.com/d/msgid/swupdate/ <http://groups.google.com/d/
> msgid/swupdate/>>
> > > bbd2955b-9e7b-45af-8d27- <https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>>
> > > swupdate/bbd2955b-9e7b-45af-8d27->
> > > > bd8f037a8c60n%40googlegroups.com <http://40googlegroups.com>

> <http://40googlegroups.com <http://40googlegroups.com>>?

> > > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>>.
> > >
> > > --
> > >
> >
> _______________________________________________________________________
> > > Nabla Software Engineering GmbH
> > > Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596> <tel:

> > +49%20821%2045592596> <tel:
> > > +49%20821%2045592596>
> > > Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> > > E-Mail: sba...@nabladev.com
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "swupdate" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send
> > > an email to swupdate+u...@googlegroups.com
> > > <mailto:swupdate+u...@googlegroups.com>.
> > > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>>

> > > swupdate/853dcf5a-c665-4ec4-
> a621-8656b6b7771fn%40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4-
> <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4->
> > <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4-
> <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4->>
> > > a621-8656b6b7771fn%40googlegroups.com <http://40googlegroups.com>?

> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> >
> > --
> >
> _______________________________________________________________________
> > Nabla Software Engineering GmbH
> > Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596> <tel:
> > +49%20821%2045592596>
> > Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> > E-Mail: sba...@nabladev.com
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/>

> > swupdate/e7a5030b-ed45-4d06-a6d5-cc91dbea633dn%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/swupdate/e7a5030b-ed45-4d06-
> a6d5- <https://groups.google.com/d/msgid/swupdate/e7a5030b-
> ed45-4d06-a6d5->
> > cc91dbea633dn%40googlegroups.com?

> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
> --

> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> swupdate/a0ffccb7-4869-41e8-bc88-fe20847d758cn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/a0ffccb7-4869-41e8-bc88-
> fe20847d758cn%40googlegroups.com?utm_medium=email&utm_source=footer>.

Ihor Fedorenco

unread,

May 14, 2026, 10:52:57 AMMay 14

to swupdate

hawkBit deployment feedback currently only reports coarse proceeding/finished
state and log details. This makes long-running downloads or installations hard
to observe from hawkBit.

This patch subscribes to SWUpdate progress IPC from the hawkBit notification
thread and emits a compact, machine-readable progress detail string into the
existing hawkBit feedback details path.

Progress details are coalesced and share the existing feedback path. A global
feedback throttle limits all feedback POSTs, including both normal log batches
and progress snapshots, so progress reporting cannot increase feedback
frequency beyond the configured interval, except for important state changes.

Normal PROGRESS status messages are filtered from details[] to avoid pushing
unstructured progress noise into hawkBit action logs.

The emitted detail format is intended to be consumed by a corresponding
hawkBit UI change, which parses the progress detail entries and renders target
download/install progress. Without the UI change, the patch still reports
progress as ordinary hawkBit action-log details, but hawkBit will not display it
as a dedicated progress indicator.

diff --git a/suricatta/server_hawkbit.c b/suricatta/server_hawkbit.c
index a9d09ac5..57c4816c 100644
--- a/suricatta/server_hawkbit.c
+++ b/suricatta/server_hawkbit.c
@@ -20,6 +20,7 @@
#include <sys/time.h>
#include <swupdate_status.h>
#include <pthread.h>
+#include <progress_ipc.h>
#include "suricatta/suricatta.h"
#include "suricatta/server.h"
#include "server_utils.h"
@@ -987,6 +988,54 @@ static int server_update_status_callback(ipc_message *msg)
return 0;
}

+/*
+ * These functions are for V2 of the protocol
+ */
+#define enum_string(x) [x] = #x
+static const char *get_status_string(unsigned int status)
+{
+ const char * const str[] = {
+ enum_string(IDLE),
+ enum_string(START),
+ enum_string(RUN),
+ enum_string(SUCCESS),
+ enum_string(FAILURE),
+ enum_string(DOWNLOAD),
+ enum_string(DONE),
+ enum_string(SUBPROCESS)
+ };
+
+ if (status >= ARRAY_SIZE(str))
+ return "UNKNOWN";
+
+ return str[status];
+}
+
+#define enum_source_string(x) [SOURCE_##x] = #x
+static const char *get_source_string(unsigned int source)
+{
+ const char * const str[] = {
+ enum_source_string(UNKNOWN),
+ enum_source_string(WEBSERVER),
+ enum_source_string(SURICATTA),
+ enum_source_string(DOWNLOADER),
+ enum_source_string(LOCAL)
+ };
+
+ if (source >= ARRAY_SIZE(str))
+ return "UNKNOWN";
+
+ return str[source];
+}
+
+static time_t get_monotonic_ms(void)
+{
+ struct timespec time_now;
+ clock_gettime(CLOCK_MONOTONIC, &time_now);
+
+ return time_now.tv_sec * 1000 + time_now.tv_nsec / 1000000;
+}
+
static void *process_notification_thread(void *data)
{
const int action_id = *(int *)data;
@@ -998,6 +1047,36 @@ static void *process_notification_thread(void *data)
unsigned int percent = 0;
unsigned int step = 0;

+ struct progress_msg progress_msg;
+ RECOVERY_STATUS progress_status = -1;
+ unsigned int progress_dwl_percent = 0;
+ size_t progress_dwl_total = 0;
+ unsigned int progress_step = 0;
+ unsigned int progress_total = 0;
+ unsigned int progress_percent = 0;
+ char progress_image_name[256];
+ sourcetype progress_source = -1;
+
+ char progress_str[512];
+ char progress_escaped[512];
+ int progress_fd = -1;
+ int progress_ret;
+ unsigned int field_size = 0;
+ const int NUMBER_OF_FIELDS = 3;
+ char *p_fields[NUMBER_OF_FIELDS];
+ const char *progress_detail = NULL;
+ bool progress_avail = false;
+ bool progress_pending = false;
+ bool flush_allowed = false;
+ bool flush_force = false;
+
+ time_t now_ms, last_flush_ms;
+ const unsigned int interval_ms = 3000;
+
+ p_fields[0] = &progress_str[0];
+
+ now_ms = get_monotonic_ms();
+ last_flush_ms = now_ms;

/*
* Create a new channel to the server. The opened channel is
@@ -1018,13 +1097,76 @@ static void *process_notification_thread(void *data)
bool data_avail = false;
int ret = ipc_get_status(&msg);

+ if (get_monotonic_ms() - last_flush_ms >= interval_ms)
+ flush_allowed = true;
+
+ if (progress_fd < 0)
+ progress_fd = progress_ipc_connect(true);
+
+ if (progress_fd >= 0) {
+ progress_ret = progress_ipc_receive(&progress_fd, &progress_msg);
+ if (progress_ret == sizeof(progress_msg)) {
+ if (progress_msg.status != PROGRESS &&
+ (progress_msg.status != progress_status || progress_msg.status == FAILURE)) {
+ progress_status = progress_msg.status;
+ progress_avail = true;
+ flush_force = true;
+ }
+
+ if (progress_msg.source != progress_source) {
+ progress_source = progress_msg.source;
+ progress_avail = true;
+ }
+
+ if ((progress_msg.dwl_percent != progress_dwl_percent) &&
+ progress_msg.dwl_bytes != 0 &&
+ progress_msg.status == DOWNLOAD) {
+ progress_dwl_percent = progress_msg.dwl_percent;
+ progress_dwl_total = progress_msg.dwl_bytes;
+ progress_avail = true;
+ }
+
+ if ((progress_msg.cur_step != progress_step ||
+ progress_msg.cur_percent != progress_percent) &&
+ progress_msg.cur_step) {
+ progress_step = progress_msg.cur_step;
+ progress_percent = progress_msg.cur_percent;
+ progress_total = progress_msg.nsteps;
+ snescape(progress_image_name, sizeof(progress_image_name), progress_msg.cur_step ? progress_msg.cur_image: "");
+ progress_avail = true;
+ }
+ }
+ if (progress_avail) {
+ p_fields[0] = progress_escaped;
+ field_size = snescape(p_fields[0], sizeof(progress_escaped), get_status_string(progress_status));
+
+ p_fields[1] = p_fields[0] + field_size + 1;
+ field_size = snescape(p_fields[1], sizeof(progress_escaped) - (p_fields[1] - p_fields[0]), get_source_string(progress_source));
+
+ p_fields[2] = p_fields[1] + field_size + 1;
+ field_size = snescape(p_fields[2], sizeof(progress_escaped) - (p_fields[2] - p_fields[0]), progress_image_name);
+
+ snprintf(progress_str, sizeof(progress_str),
+ "[suricatta_progress] { status : %s, source : %s, "
+ "download : { bytes : %zu, percent : %d }, "
+ "artifact : { current : %d, name : %s, percent : %d, total : %d } }",
+ p_fields[0], p_fields[1],
+ progress_dwl_total, progress_dwl_percent,
+ progress_step, p_fields[2], progress_percent, progress_total
+ );
+ progress_avail = false;
+ progress_pending = true;
+ }
+ }
+
if (ret < 0) {
ERROR("Error getting status, stopping notification thread");
stop = true;
} else {
data_avail = (strlen(msg.data.status.desc) != 0);
+ if (msg.data.status.current == PROGRESS)
+ data_avail = false;
}
-
/*
* Mutex used to synchronize end of the thread
* The suricatta thread locks the mutex at the beginning
@@ -1035,8 +1177,6 @@ static void *process_notification_thread(void *data)
stop = true;
}

- if (data_avail && msg.data.status.current == PROGRESS)
- continue;
if (data_avail && numdetails < MAX_DETAILS) {
for (int c = 0; c < strlen(msg.data.status.desc); c++) {
switch (msg.data.status.desc[c]) {
@@ -1051,11 +1191,11 @@ static void *process_notification_thread(void *data)
}
details[numdetails++] = strdup(msg.data.status.desc);
}
-
/*
* Flush to the server
*/
- if (numdetails == MAX_DETAILS || (stop && !data_avail)) {
+ if ((flush_allowed && !flush_force) &&
+ ((numdetails == MAX_DETAILS) || (stop && !data_avail && numdetails > 0))) {
TRACE("Update log to server from thread");
if (server_send_deployment_reply(
channel,
@@ -1074,9 +1214,32 @@ static void *process_notification_thread(void *data)
percent = 0;
step++;
}
+ flush_allowed = false;
+ last_flush_ms = get_monotonic_ms();
}

- if (stop && !data_avail)
+ if ((flush_allowed || flush_force) && progress_pending) {
+ progress_detail = strdup(progress_str);
+ if (server_send_deployment_reply(
+ channel,
+ action_id, step, percent,
+ reply_status_result_finished.none,
+ reply_status_execution.proceeding, 1,
+ &progress_detail) != SERVER_OK) {
+ ERROR("Error while sending log to server.");
+ }
+ free((void *)progress_detail);
+ progress_pending = false;
+ percent++;
+ if (percent > 100) {
+ percent = 0;
+ step++;
+ }
+ flush_allowed = false;
+ flush_force = false;
+ last_flush_ms = get_monotonic_ms();
+ }
+ if (stop && !data_avail && !progress_pending && numdetails == 0)
break;

// wait a bit for next message...
@@ -1265,7 +1428,7 @@ server_op_res_t server_process_update_artifact(int action_id,
artifact->url);

channel_data_t channel_data = channel_data_defaults;
- channel_data.url =
+ channel_data.url =
strdup(artifact->url);

static const char* const update_info = STRINGIFY(

[PATCH]---hawkbitUI---

ui: add target progress card for SWUpdate feedback

Add a progress card to the target details modal that displays coarse
SWUpdate/Suricatta deployment progress reported through hawkBit action-log
details.

The implementation introduces a target-progress parser for
[suricatta_progress] detail entries and derives a UI model containing phase,
source, download percentage, artifact step, artifact name, and byte counters.
Only strict progress detail entries are parsed, preventing unrelated log lines
or embedded feedback request dumps from being interpreted as progress.

The target progress container polls the latest target action logs and renders
the derived progress through a target-specific progress card and reusable
progress bar.

diff --git a/src/app/components/progress-bar/index.tsx b/src/app/components/progress-bar/index.tsx
new file mode 100644
index 0000000..ae02e1f
--- /dev/null
+++ b/src/app/components/progress-bar/index.tsx
@@ -0,0 +1,52 @@
+'use client';
+
+import styles from './styles.module.scss';
+
+export interface ProgressBarProps {
+ value: number;
+ label?: string;
+ showValue?: boolean;
+ valueInside?: boolean;
+}
+
+function clampPercent(value: number): number {
+ if (!Number.isFinite(value)) {
+ return 0;
+ }
+
+ return Math.max(0, Math.min(100, Math.round(value)));
+}
+
+export default function ProgressBar({
+ value,
+ label,
+ showValue = true,
+ valueInside = true,
+}: ProgressBarProps) {
+ const percent = clampPercent(value);
+
+ return (
+ <div className={styles.container}>
+ {(label || (showValue && !valueInside)) && (
+ <div className={styles.header}>
+ {label && <span>{label}</span>}
+ {showValue && !valueInside && <strong>{percent}%</strong>}
+ </div>
+ )}
+
+ <div
+ className={styles.track}
+ aria-valuenow={percent}
+ aria-valuemin={0}
+ aria-valuemax={100}
+ role='progressbar'
+ >
+ <div className={styles.fill} style={{ width: `${percent}%` }} />
+
+ {showValue && valueInside && (
+ <span className={styles.value}>{percent}%</span>
+ )}
+ </div>
+ </div>
+ );
+}
diff --git a/src/app/components/progress-bar/styles.module.scss b/src/app/components/progress-bar/styles.module.scss
new file mode 100644
index 0000000..9229c67
--- /dev/null
+++ b/src/app/components/progress-bar/styles.module.scss
@@ -0,0 +1,40 @@
+.container {
+ width: 100%;
+}
+
+.header {
+ display: flex;
+ justify-content: space-between;
+ margin-bottom: 8px;
+ font-size: 14px;
+}
+
+.track {
+ position: relative;
+ width: 100%;
+ height: 24px;
+ overflow: hidden;
+ border-radius: 999px;
+ background: #e5e7eb;
+}
+
+.fill {
+ height: 100%;
+ border-radius: 999px;
+ background: #5b236b;
+ transition: width 250ms ease;
+}
+
+.value {
+ position: absolute;
+ inset: 0;
+ display: flex;
+ align-items: center;
+ justify-content: center;
+ font-size: 16px;
+ font-weight: 600;
+ line-height: 1;
+ color: white;
+ mix-blend-mode: difference;
+ pointer-events: none;
+}
diff --git a/src/app/components/target-info-modal/components/target-progress-card/index.tsx b/src/app/components/target-info-modal/components/target-progress-card/index.tsx
new file mode 100644
index 0000000..d29d4f6
--- /dev/null
+++ b/src/app/components/target-info-modal/components/target-progress-card/index.tsx
@@ -0,0 +1,101 @@
+'use client';
+
+import styles from './styles.module.scss';
+import Text from '@/app/components/text';
+import ProgressBar from '@/app/components/progress-bar';
+import { TargetProgress } from '@/entities/target-progress';
+
+export interface ProgressCardProps {
+ progress: TargetProgress | null;
+ title?: string;
+}
+
+function getStepLabel(progress: TargetProgress): string | null {
+ if (progress.totalSteps > 0 && progress.currentStep > 0) {
+ return `Step ${progress.currentStep} of ${progress.totalSteps}`;
+ }
+
+ return null;
+}
+
+function ProgressEmptyState({ title }: { title: string }) {
+ return (
+ <div className={styles.container}>
+ <Text variant='heading-2'>{title}</Text>
+ <div className={styles.empty}>No progress data available.</div>
+ </div>
+ );
+}
+
+function MetaItem({ children }: { children: React.ReactNode }) {
+ return <div className={styles.meta}>{children}</div>;
+}
+
+function SourceItem({ source }: { source?: string }) {
+ if (!source) {
+ return null;
+ }
+
+ return <MetaItem>Source: {source}</MetaItem>;
+}
+
+function BytesItem({
+ currentBytes,
+ totalBytes,
+}: {
+ currentBytes?: number;
+ totalBytes?: number;
+}) {
+ if (
+ currentBytes === undefined ||
+ totalBytes === undefined ||
+ !Number.isFinite(currentBytes) ||
+ !Number.isFinite(totalBytes) ||
+ totalBytes <= 0
+ ) {
+ return null;
+ }
+
+ return (
+ <div className={styles.common}>
+ ({currentBytes} of {totalBytes}) kB
+ </div>
+ );
+}
+
+export default function ProgressCard({
+ progress,
+ title = 'Progress',
+}: ProgressCardProps) {
+ if (!progress) {
+ return <ProgressEmptyState title={title} />;
+ }
+
+ const artifactName = progress.name.trim() || null;
+ const stepLabel = getStepLabel(progress);
+
+ return (
+ <div className={styles.container}>
+ <Text variant='heading-2'>{title}</Text>
+ <div className={styles.card}>
+ <div className={styles.header}>
+ <div className={styles.phase}>{progress.phase}</div>
+ <SourceItem source={progress.source} />
+ </div>
+ <ProgressBar value={progress.totalPercent} />
+ <div className={styles.metaBlock}>
+ <div className={styles.oneline}>
+ {artifactName && (
+ <div className={styles.common}>{artifactName}</div>
+ )}
+ <BytesItem
+ currentBytes={progress.currentBytes}
+ totalBytes={progress.totalBytes}
+ />
+ </div>
+ {stepLabel && <MetaItem>{stepLabel}</MetaItem>}
+ </div>
+ </div>
+ </div>
+ );
+}
diff --git a/src/app/components/target-info-modal/components/target-progress-card/styles.module.scss b/src/app/components/target-info-modal/components/target-progress-card/styles.module.scss
new file mode 100644
index 0000000..8407ced
--- /dev/null
+++ b/src/app/components/target-info-modal/components/target-progress-card/styles.module.scss
@@ -0,0 +1,62 @@
+@use 'src/app/styles/variables' as *;
+
+.container {
+ width: 100%;
+}
+
+.card {
+ margin-top: 20px;
+ padding: 20px;
+ border-radius: 12px;
+ background-color: $secondary-color;
+}
+
+.header {
+ display: flex;
+ align-items: flex-start;
+ justify-content: space-between;
+ gap: 16px;
+ margin-bottom: 16px;
+}
+
+.oneline {
+ display: flex;
+ align-items: flex-start;
+ justify-content: space-between;
+ gap: 16px;
+}
+
+.current {
+ font-size: 16px;
+ font-weight: 600;
+}
+
+.meta {
+ margin-top: 4px;
+ font-size: 13px;
+ opacity: 0.7;
+}
+
+.phase {
+ padding: 6px 10px;
+ border-radius: 999px;
+ font-size: 18px;
+ font-weight: 600;
+ text-transform: capitalize;
+ background: #e5e7eb;
+}
+
+.unknown {
+ background: #e5e7eb;
+}
+
+.common {
+ margin-top: 12px;
+ font-size: 13px;
+ opacity: 0.75;
+}
+
+.empty {
+ margin-top: 20px;
+ color: #777;
+}
diff --git a/src/app/components/target-info-modal/containers/target-progress-container/index.tsx b/src/app/components/target-info-modal/containers/target-progress-container/index.tsx
new file mode 100644
index 0000000..432e7da
--- /dev/null
+++ b/src/app/components/target-info-modal/containers/target-progress-container/index.tsx
@@ -0,0 +1,115 @@
+'use client';
+
+import { useEffect, useMemo, useState } from 'react';
+import ProgressCard from '../../components/target-progress-card';
+import {
+ deriveProgressFromDetails,
+ TargetProgress,
+} from '@/entities/target-progress';
+import { ActionLog } from '@/entities/action-log';
+import { TargetsService } from '@/services/targets-service';
+import { useTargetActionsTableStore } from '@/stores/target-action-table-store';
+
+function getLogTime(log: ActionLog): number {
+ const reportedAt = log.reportedAt;
+
+ if (!reportedAt) {
+ return 0;
+ }
+
+ if (typeof reportedAt === 'number') {
+ return reportedAt;
+ }
+
+ const parsed = Date.parse(reportedAt);
+
+ return Number.isFinite(parsed) ? parsed : 0;
+}
+
+function collectDetails(logs: ActionLog[]): string[] {
+ return logs
+ .slice()
+ .sort((a, b) => getLogTime(a) - getLogTime(b))
+ .flatMap((log) => log.messages ?? []);
+}
+
+function isTerminalProgress(progress: TargetProgress | null): boolean {
+ return progress?.phase === 'success' || progress?.phase === 'failure';
+}
+
+export default function TargetProgressContainer() {
+ const selectedTargetId = useTargetActionsTableStore(
+ (state) => state.selectedTargetId
+ );
+
+ const latestActionId = useTargetActionsTableStore(
+ (state) => state.actions[0]?.id
+ );
+
+ const [logs, setLogs] = useState<ActionLog[]>([]);
+ const [isLoading, setIsLoading] = useState(false);
+
+ useEffect(() => {
+ if (!selectedTargetId || !latestActionId) {
+ setLogs([]);
+ return;
+ }
+
+ let cancelled = false;
+ let timeoutId: ReturnType<typeof setTimeout> | undefined;
+
+ const fetchLogs = async () => {
+ setIsLoading(true);
+
+ try {
+ const actionLogs = await TargetsService.getActionLog(
+ selectedTargetId,
+ latestActionId
+ );
+
+ if (cancelled) {
+ return;
+ }
+
+ setLogs(actionLogs);
+
+ const progress = deriveProgressFromDetails(
+ collectDetails(actionLogs)
+ );
+
+ if (!isTerminalProgress(progress)) {
+ timeoutId = setTimeout(fetchLogs, 3000);
+ }
+ } catch (error) {
+ console.error('Failed to fetch progress logs', error);
+
+ if (!cancelled) {
+ timeoutId = setTimeout(fetchLogs, 5000);
+ }
+ } finally {
+ if (!cancelled) {
+ setIsLoading(false);
+ }
+ }
+ };
+
+ fetchLogs();
+
+ return () => {
+ cancelled = true;
+
+ if (timeoutId) {
+ clearTimeout(timeoutId);
+ }
+ };
+ }, [selectedTargetId, latestActionId]);
+
+ const progress: TargetProgress | null = useMemo(() => {
+ return deriveProgressFromDetails(collectDetails(logs));
+ }, [logs]);
+
+ if (isLoading && !progress) {
+ return <ProgressCard progress={null} title='Progress' />;
+ }
+ return <ProgressCard progress={progress} title='Progress' />;
+}
diff --git a/src/app/components/target-info-modal/containers/target-progress-container/styles.module.scss b/src/app/components/target-info-modal/containers/target-progress-container/styles.module.scss
new file mode 100644
index 0000000..228de19
--- /dev/null
+++ b/src/app/components/target-info-modal/containers/target-progress-container/styles.module.scss
@@ -0,0 +1,59 @@
+.container {
+ width: 100%;
+}
+
+.title {
+ margin-bottom: 24px;
+ color: #5b236b;
+}
+
+.card {
+ padding: 20px;
+ border-radius: 12px;
+ background: #f7f7fb;
+}
+
+.header {
+ display: flex;
+ justify-content: space-between;
+ align-items: center;
+ margin-bottom: 16px;
+}
+
+.status {
+ font-weight: 600;
+}
+
+.source {
+ font-size: 14px;
+ color: #666;
+}
+
+.stepLabel {
+ margin-bottom: 8px;
+ font-size: 15px;
+}
+
+.progressOuter {
+ width: 100%;
+ height: 14px;
+ background: #e5e7eb;
+ border-radius: 999px;
+ overflow: hidden;
+}
+
+.progressInner {
+ height: 100%;
+ background: #52d410;
+ transition: width 0.25s ease;
+}
+
+.progressText {
+ margin-top: 8px;
+ font-size: 14px;
+ color: #333;
+}
+
+.empty {
+ color: #777;
+}
diff --git a/src/app/components/target-info-modal/index.tsx b/src/app/components/target-info-modal/index.tsx
index 0eaa17b..c0468c9 100644
--- a/src/app/components/target-info-modal/index.tsx
+++ b/src/app/components/target-info-modal/index.tsx
@@ -6,6 +6,7 @@ import TargetAssignedDistributionContainer from '@/app/components/target-info-mo
import TargetInstalledDistributionContainer from '@/app/components/target-info-modal/containers/target-installed-distribution-container';
import TargetMetadataContainer from '@/app/components/target-info-modal/containers/target-metadata-container';
import TargetTags from '@/app/components/target-info-modal/components/target-tags';
+import TargetProgressContainer from '@/app/components/target-info-modal/containers/target-progress-container';

export default function TargetInfo() {
return (
@@ -26,6 +27,7 @@ export default function TargetInfo() {
},
{ title: 'Tags', component: <TargetTags /> },
{ title: 'Metadata', component: <TargetMetadataContainer /> },
+ { title: 'Progress', component: <TargetProgressContainer />},
]}
/>
);
diff --git a/src/entities/target-progress.ts b/src/entities/target-progress.ts
new file mode 100644
index 0000000..115225a
--- /dev/null
+++ b/src/entities/target-progress.ts
@@ -0,0 +1,241 @@
+type TargetProgressPhase =
+ | 'starting'
+ | 'download'
+ | 'install'
+ | 'success'
+ | 'failure'
+ | 'unknown';
+
+export interface TargetProgress {
+ phase: TargetProgressPhase;
+ source?: string;
+ name: string;
+ currentStep: number;
+ totalSteps: number;
+ stepPercent: number;
+ downloadPercent: number;
+ totalBytes: number;
+ currentBytes: number;
+ totalPercent: number;
+}
+
+interface SuricattaProgressDetail {
+ status: string;
+ source: string;
+ download: {
+ bytes: number;
+ percent: number;
+ };
+ artifact: {
+ current: number;
+ name: string;
+ percent: number;
+ total: number;
+ };
+}
+
+const SURICATTA_PROGRESS_DETAIL_RE =
+ /^\s*\[suricatta_progress\]\s*\{\s*status\s*:\s*[^,}]*,\s*source\s*:\s*[^,}]*,\s*download\s*:\s*\{[^}]*\}\s*,\s*artifact\s*:\s*\{[^}]*\}\s*\}\s*$/i;
+
+export function parseProgressDetail(
+ detail: string
+): SuricattaProgressDetail | null {
+
+ if (!SURICATTA_PROGRESS_DETAIL_RE.test(detail)) {
+ return null;
+ }
+
+ const status = extractValue(detail, 'status');
+ const source = extractValue(detail, 'source');
+ if (source != 'SURICATTA')
+ return null;
+
+ const downloadBlock = extractBlock(detail, 'download');
+ const artifactBlock = extractBlock(detail, 'artifact');
+
+ if (!status || !source || !downloadBlock || !artifactBlock) {
+ return null;
+ }
+
+ const downloadBytes = parseNumber(extractValue(downloadBlock, 'bytes'));
+ const downloadPercent = parseNumber(extractValue(downloadBlock, 'percent'));
+
+ const artifactCurrent = parseNumber(extractValue(artifactBlock, 'current'));
+ const artifactName = extractValue(artifactBlock, 'name') ?? '';
+ const artifactPercent = parseNumber(extractValue(artifactBlock, 'percent'));
+ const artifactTotal = parseNumber(extractValue(artifactBlock, 'total'));
+
+ if (
+ downloadBytes === null ||
+ downloadPercent === null ||
+ artifactCurrent === null ||
+ artifactPercent === null ||
+ artifactTotal === null
+ ) {
+ return null;
+ }
+
+ if (
+ downloadPercent < 0 ||
+ downloadPercent > 100 ||
+ artifactPercent < 0 ||
+ artifactPercent > 100 ||
+ artifactCurrent < 0 ||
+ artifactTotal < 0
+ ) {
+ return null;
+ }
+
+ if (artifactCurrent > 0 && artifactTotal <= 0) {
+ return null;
+ }
+
+ if (artifactTotal > 0 && artifactCurrent > artifactTotal) {
+ return null;
+ }
+
+ return {
+ status,
+ source,
+ download: {
+ bytes: downloadBytes,
+ percent: downloadPercent,
+ },
+ artifact: {
+ current: artifactCurrent,
+ name: artifactName,
+ percent: artifactPercent,
+ total: artifactTotal,
+ },
+ };
+}
+
+function findLatestTextProgress(
+ details: string[]
+): SuricattaProgressDetail | null {
+ for (let i = details.length - 1; i >= 0; i--) {
+ const detail = details[i];
+
+ if (!detail) {
+ continue;
+ }
+
+ const progress = parseProgressDetail(detail);
+
+ if (progress) {
+ return progress;
+ }
+ }
+
+ return null;
+}
+
+function deriveProgressFromText(
+ progress: SuricattaProgressDetail
+): TargetProgress {
+ const currentStep = progress.artifact.current;
+ const totalSteps = progress.artifact.total;
+ const stepPercent = clampPercent(progress.artifact.percent);
+ const downloadPercent = clampPercent(progress.download.percent);
+ const phase = derivePhase(progress.status, currentStep);
+
+ const installIsActive = currentStep > 0 && totalSteps > 0;
+
+ const totalPercent =
+ phase === 'success'
+ ? 100
+ : installIsActive
+ ? Math.round(((currentStep - 1) * 100 + stepPercent) / totalSteps)
+ : downloadPercent;
+
+ const totalBytes = Math.round(progress.download.bytes / 1024);
+ const currentBytes = Math.round((totalBytes * downloadPercent) / 100);
+
+ return {
+ phase,
+ source: progress.source,
+ name: progress.artifact.name,
+ currentStep,
+ totalSteps,
+ stepPercent,
+ downloadPercent,
+ totalBytes,
+ currentBytes,
+ totalPercent: clampPercent(totalPercent),
+ };
+}
+
+export function deriveProgressFromDetails(
+ details: string[]
+): TargetProgress | null {
+ const latestTextProgress = findLatestTextProgress(details);
+
+ if (latestTextProgress) {
+ return deriveProgressFromText(latestTextProgress);
+ }
+
+ return null;
+}
+
+function clampPercent(value: number): number {
+ if (!Number.isFinite(value)) {
+ return 0;
+ }
+
+ return Math.max(0, Math.min(100, Math.round(value)));
+}
+
+function parseNumber(value: string | null): number | null {
+ if (value === null || value.trim() === '') {
+ return null;
+ }
+
+ const num = Number(value.trim());
+
+ return Number.isFinite(num) ? num : null;
+}
+
+function escapeRegExp(value: string): string {
+ return value.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+}
+
+function extractBlock(input: string, blockName: string): string | null {
+ const re = new RegExp(
+ `${escapeRegExp(blockName)}\\s*:\\s*\\{([^}]*)\\}`,
+ 'i'
+ );
+
+ const match = input.match(re);
+
+ return match ? match[1] : null;
+}
+
+function extractValue(block: string, key: string): string | null {
+ const re = new RegExp(`${escapeRegExp(key)}\\s*:\\s*([^,}]*)`, 'i');
+ const match = block.match(re);
+
+ if (!match) {
+ return null;
+ }
+
+ return match[1].trim();
+}
+
+function derivePhase(status?: string, currentStep = 0): TargetProgressPhase {
+ switch (status?.toUpperCase()) {
+ case 'START':
+ return 'starting';
+ case 'DOWNLOAD':
+ return 'download';
+ case 'RUN':
+ return currentStep > 0 ? 'install' : 'starting';
+ case 'SUCCESS':
+ case 'DONE':
+ return 'success';
+ case 'FAILURE':
+ case 'ERROR':
+ return 'failure';
+ default:
+ return 'unknown';
+ }
+}

неділя, 12 квітня 2026 р. о 14:13:06 UTC+3 Stefano Babic пише:

Message has been deleted

Stefano Babic

unread,

May 28, 2026, 10:36:05 AM (8 days ago) May 28

to Ihor Fedorenco, swupdate

Hi Ihor,

first step to reach is to have a well formed patch that could be
applied, also for testing before merging. It seems you have copy&paste
the code, and your mailer has damaged the patch. So I do not start the
review if I know that patch couldn't be applied.

pacthes are collected on patchwork, see :
https://patchwork.ozlabs.org/project/swupdate/list/

But if I try to apply your patch:

patching file suricatta/server_hawkbit.c
patch: **** malformed patch at line 2154: *msg)

you should use "git format-patch" to generate patches, and "git
send-email" to send them to ML, els ethe mailer breaksthem.

Best regards,
Stefano Babic

On 5/28/26 15:01, Ihor Fedorenco wrote:
> [PATCH] suricatta: report SWUpdate progress in hawkBit details[]
>
> hawkBit deployment feedback currently reports only coarse deployment state
> changes and log details. This makes long-running downloads or installations

> hard to observe from hawkBit.
>

> Subscribe to the SWUpdate progress IPC from the hawkBit notification
> thread and
> emit coalesced progress snapshots through the existing hawkBit feedback
> details[] path.
>
> The progress detail has the following form:
>
> [suricatta_progress] { status : DOWNLOAD, source : SURICATTA,
> download : { bytes : 28128, percent : 42 },
> artifact : { current : 1, name : image.rootfs.ext4.gz,
> percent : 0, total : 1 } }
>
> Progress snapshots share the same feedback path as normal log details. A
> global
> feedback throttle limits feedback POST frequency for both normal log batches
> and progress snapshots, so progress reporting does not create an additional
> high-frequency telemetry channel.
>
> A corresponding hawkbitUI change can parse these detail entries and render
> download/install progress. Without that UI change, the entries remain
> ordinary
> hawkBit action-log details.

>
> diff --git a/suricatta/server_hawkbit.c b/suricatta/server_hawkbit.c
> index a9d09ac5..57c4816c 100644
> --- a/suricatta/server_hawkbit.c
> +++ b/suricatta/server_hawkbit.c
> @@ -20,6 +20,7 @@
> #include <sys/time.h>
> #include <swupdate_status.h>
> #include <pthread.h>
> +#include <progress_ipc.h>
> #include "suricatta/suricatta.h"
> #include "suricatta/server.h"
> #include "server_utils.h"
> @@ -987,6 +988,54 @@ static int
> server_update_status_callback(ipc_message *msg)
> return 0;
> }
>
> +/*
> + * These functions are for V2 of the protocol
> + */
> +#define enum_string(x)[x] = #x
> +static const char *get_status_string(unsigned int status)
> +{

> +const char * const str[] = {

> +enum_string(IDLE),
> +enum_string(START),
> +enum_string(RUN),
> +enum_string(SUCCESS),
> +enum_string(FAILURE),
> +enum_string(DOWNLOAD),
> +enum_string(DONE),
> +enum_string(SUBPROCESS)
> +};
> +
> +if (status >= ARRAY_SIZE(str))
> +return "UNKNOWN";
> +

> +return str[status];

> +}
> +
> +#define enum_source_string(x)[SOURCE_##x] = #x
> +static const char *get_source_string(unsigned int source)
> +{
> +const char *const str[] = {
> +enum_source_string(UNKNOWN),
> +enum_source_string(WEBSERVER),
> +enum_source_string(SURICATTA),
> +enum_source_string(DOWNLOADER),
> +enum_source_string(LOCAL)
> +};
> +
> +if (source >= ARRAY_SIZE(str))
> +return "UNKNOWN";
> +

> +return str[source];

> +}
> +
> +static time_t get_monotonic_ms(void)
> +{
> +struct timespec time_now;
> +clock_gettime(CLOCK_MONOTONIC, &time_now);
> +

> +return time_now.tv_sec * 1000 + time_now.tv_nsec / 1000000;

> +const unsigned int interval_ms = 3000;
> +
> +p_fields[0] = &progress_str[0];
> +
> +now_ms = get_monotonic_ms();
> +last_flush_ms = now_ms;

>
> /*
> * Create a new channel to the server. The opened channel is
> @@ -1018,13 +1097,76 @@ static void *process_notification_thread(void *data)
> bool data_avail = false;
> int ret = ipc_get_status(&msg);
>

> +if (get_monotonic_ms() - last_flush_ms >= interval_ms)

> +flush_allowed = true;
> +
> +if (progress_fd < 0)
> +progress_fd = progress_ipc_connect(true);
> +
> +if (progress_fd >= 0) {
> +progress_ret = progress_ipc_receive(&progress_fd, &progress_msg);
> +if (progress_ret == sizeof(progress_msg)) {
> +if (progress_msg.status != PROGRESS &&

> +(progress_msg.status != progress_status || progress_msg.status ==

> +snescape(progress_image_name, sizeof(progress_image_name),

> progress_msg.cur_step ? progress_msg.cur_image: "");
> +progress_avail = true;
> +}
> +}
> +if (progress_avail) {
> +p_fields[0] = progress_escaped;

> +field_size = snescape(p_fields[0], sizeof(progress_escaped),
> get_status_string(progress_status));
> +
> +p_fields[1] = p_fields[0] + field_size + 1;
> +field_size = snescape(p_fields[1], sizeof(progress_escaped) -

> (p_fields[1] - p_fields[0]), get_source_string(progress_source));
> +

> +p_fields[2] = p_fields[1] + field_size + 1;
> +field_size = snescape(p_fields[2], sizeof(progress_escaped) -

> (p_fields[2] - p_fields[0]), progress_image_name);
> +

> +snprintf(progress_str, sizeof(progress_str),

> +"[suricatta_progress] { status : %s, source : %s, "
> +"download : { bytes : %zu, percent : %d }, "
> +"artifact : { current : %d, name : %s, percent : %d, total : %d } }",

> +p_fields[0], p_fields[1],
> +progress_dwl_total, progress_dwl_percent,
> +progress_step, p_fields[2], progress_percent, progress_total
> +);
> +progress_avail = false;
> +progress_pending = true;

> +}
> +}
> +
> if (ret < 0) {
> ERROR("Error getting status, stopping notification thread");
> stop = true;
> } else {
> data_avail = (strlen(msg.data.status.desc) != 0);
> +if (msg.data.status.current == PROGRESS)

> +data_avail = false;

> }
> -
> /*
> * Mutex used to synchronize end of the thread
> * The suricatta thread locks the mutex at the beginning
> @@ -1035,8 +1177,6 @@ static void *process_notification_thread(void *data)
> stop = true;
> }
>

> -if (data_avail && msg.data.status.current == PROGRESS)

> -continue;
> if (data_avail && numdetails < MAX_DETAILS) {
> for (int c = 0; c < strlen(msg.data.status.desc); c++) {
> switch (msg.data.status.desc[c]) {
> @@ -1051,11 +1191,11 @@ static void *process_notification_thread(void *data)
> }
> details[numdetails++] = strdup(msg.data.status.desc);
> }
> -
> /*
> * Flush to the server
> */

> -if (numdetails == MAX_DETAILS || (stop && !data_avail)) {

> +if ((flush_allowed && !flush_force) &&

> +((numdetails == MAX_DETAILS) || (stop && !data_avail && numdetails > 0))) {

> TRACE("Update log to server from thread");
> if (server_send_deployment_reply(
> channel,
> @@ -1074,9 +1214,32 @@ static void *process_notification_thread(void *data)
> percent = 0;
> step++;
> }
> +flush_allowed = false;
> +last_flush_ms = get_monotonic_ms();
> }
>
> -if (stop && !data_avail)
> +if ((flush_allowed || flush_force) && progress_pending) {
> +progress_detail = strdup(progress_str);
> +if (server_send_deployment_reply(
> +channel,
> +action_id, step, percent,
> +reply_status_result_finished.none,
> +reply_status_execution.proceeding, 1,
> +&progress_detail) != SERVER_OK) {

> +ERROR("Error while sending log to server.");

> +}
> +free((void *)progress_detail);
> +progress_pending = false;
> +percent++;
> +if (percent > 100) {
> +percent = 0;
> +step++;
> +}
> +flush_allowed = false;
> +flush_force = false;
> +last_flush_ms = get_monotonic_ms();
> +}

> +if (stop && !data_avail && !progress_pending && numdetails == 0)

> break;
>
> // wait a bit for next message...
> @@ -1265,7 +1428,7 @@ server_op_res_t server_process_update_artifact(int
> action_id,
> artifact->url);
>
> channel_data_t channel_data = channel_data_defaults;
> -channel_data.url =

> +channel_data.url =

> strdup(artifact->url);
>
> static const char* const update_info = STRINGIFY(
>

> четвер, 14 травня 2026 р. о 17:52:57 UTC+3 Ihor Fedorenco пише:

> + name: progress.artifact.name <http://progress.artifact.name>,

> > github.com/eclipse-hawkbit/hawkbit/ <http://github.com/
> eclipse-hawkbit/hawkbit/>> <https://

> > > github.com/eclipse-hawkbit/hawkbit/ <http://github.com/
> eclipse-hawkbit/hawkbit/> <http://github.com/eclipse- <http://
> github.com/eclipse->
> > hawkbit/hawkbit/>> <https://
> > > > github.com/eclipse-hawkbit/hawkbit/ <http://github.com/
> eclipse-hawkbit/hawkbit/> <http://github.com/eclipse- <http://
> github.com/eclipse->
> > hawkbit/hawkbit/> <http://github.com/eclipse- <http://

> github.com/eclipse-> <http://github.com/ <http://github.com/>
> > eclipse->
> > > hawkbit/hawkbit/>> <https://github.com/ <https://
> github.com/> <https://github.com/ <https://github.com/>>

> > <https://github.com/ <https://github.com/> <https://
> github.com/ <https://github.com/>>> <https://
> > > > github.com/ <http://github.com/> <http://github.com/

> <http://github.com/>> <http://github.com/ <http://github.com/>
> <http://
> > github.com/ <http://github.com/>>>>
> > > > > eclipse-hawkbit/hawkbit/>
> > > > > > issues/2868#issuecomment-4191718757 <https://
> github.com/ <https://github.com/>

> > <https://github.com/ <https://github.com/>>
> > > <https://github.com/ <https://github.com/> <https://

> github.com/ <https://github.com/>>>
> > > > eclipse- <https://github.com/eclipse- <https://

> github.com/eclipse-> <https://github.com/ <https://github.com/>

> > eclipse-> <https://github.com/eclipse- <https://github.com/

> eclipse-> <https://github.com/eclipse- <https://github.com/

> eclipse->>>>
> > > > > hawkbit/ <https://github.com/eclipse-hawkbit/ <https://
> github.com/eclipse-hawkbit/> <https://

> > github.com/eclipse-hawkbit/ <http://github.com/eclipse-
> hawkbit/>> <https://
> > > github.com/eclipse-hawkbit/ <http://github.com/eclipse-
> hawkbit/> <http://github.com/eclipse-hawkbit/ <http://
> github.com/eclipse-hawkbit/>>>
> > <https://
> > > > github.com/eclipse-hawkbit/ <http://github.com/eclipse-
> hawkbit/> <http://github.com/eclipse-hawkbit/ <http://

> github.com/eclipse-hawkbit/>
> > > <http://github.com/eclipse-hawkbit/ <http://github.com/

> eclipse-hawkbit/> <http://github.com/eclipse- <http://
> github.com/eclipse->

> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>>

> > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://groups.google.com/

> <https://groups.google.com/>
> > d/msgid/> <https://groups.google.com/d/ <https://

> groups.google.com/d/> <https://groups.google.com/d/ <https://

> > groups.google.com/d/msgid/swupdate/ <http://

> groups.google.com/d/msgid/swupdate/>> <https://
> > > groups.google.com/d/msgid/swupdate/ <http://

> groups.google.com/d/msgid/swupdate/> <http://groups.google.com/
> d/ <http://groups.google.com/d/>
> > msgid/swupdate/>>
> > > > bbd2955b-9e7b-45af-8d27- <https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>>

> > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://groups.google.com/d/
> <https://groups.google.com/d/>
> > msgid/>>
> > > > swupdate/bbd2955b-9e7b-45af-8d27->
> > > > > bd8f037a8c60n%40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>

> <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer
> <http://40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer>>.
> > > >
> > > > --
> > > >
> > >
> >
> _______________________________________________________________________
> > > > Nabla Software Engineering GmbH
> > > > Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
> <tel:+49%20821%2045592596> <tel:
> > +49%20821%2045592596> <tel:

> > > +49%20821%2045592596> <tel:
> > > > +49%20821%2045592596>
> > > > Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> > > > E-Mail: sba...@nabladev.com
> > > >
> > > > --
> > > > You received this message because you are subscribed to
> the Google
> > > > Groups "swupdate" group.
> > > > To unsubscribe from this group and stop receiving emails
> from it,
> > > send
> > > > an email to swupdate+u...@googlegroups.com
> > > > <mailto:swupdate+u...@googlegroups.com>.
> > > > To view this discussion visit https://groups.google.com/
> d/ <https://groups.google.com/d/>
> > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>>
> > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://groups.google.com/d/

> <https://groups.google.com/d/>
> > msgid/>>
> > > > swupdate/853dcf5a-c665-4ec4-
> > a621-8656b6b7771fn%40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>

> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>

> > > > <https://groups.google.com/d/msgid/swupdate/853dcf5a-
> c665-4ec4- <https://groups.google.com/d/msgid/swupdate/853dcf5a-
> c665-4ec4->
> > <https://groups.google.com/d/msgid/swupdate/853dcf5a-
> c665-4ec4- <https://groups.google.com/d/msgid/swupdate/853dcf5a-
> c665-4ec4->>
> > > <https://groups.google.com/d/msgid/swupdate/853dcf5a-
> c665-4ec4- <https://groups.google.com/d/msgid/swupdate/853dcf5a-
> c665-4ec4->
> > <https://groups.google.com/d/msgid/swupdate/853dcf5a-
> c665-4ec4- <https://groups.google.com/d/msgid/swupdate/853dcf5a-
> c665-4ec4->>>

> > > > a621-8656b6b7771fn%40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com

> > > swupdate/e7a5030b-ed45-4d06-a6d5-
> cc91dbea633dn%40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <https://groups.google.com/d/msgid/swupdate/e7a5030b-
> ed45-4d06- <https://groups.google.com/d/msgid/swupdate/e7a5030b-
> ed45-4d06->
> > a6d5- <https://groups.google.com/d/msgid/swupdate/e7a5030b-
> <https://groups.google.com/d/msgid/swupdate/e7a5030b->
> > ed45-4d06-a6d5->
> > > cc91dbea633dn%40googlegroups.com <http://40googlegroups.com>?

> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> >
> > --

> > You received this message because you are subscribed to the
> Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>

> > swupdate/a0ffccb7-4869-41e8-bc88-
> fe20847d758cn%40googlegroups.com <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/swupdate/
> a0ffccb7-4869-41e8-bc88- <https://groups.google.com/d/msgid/
> swupdate/a0ffccb7-4869-41e8-bc88->
> > fe20847d758cn%40googlegroups.com?

> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> swupdate/d70e44b2-3fd4-42f2-a252-6b7e01334cd4n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/d70e44b2-3fd4-42f2-
> a252-6b7e01334cd4n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Ihor Fedorenco

unread,

May 28, 2026, 11:02:18 AM (8 days ago) May 28

to swup...@googlegroups.com

hawkBit deployment feedback currently reports only coarse deployment state
changes and log details. This makes long-running downloads or installations
hard to observe from hawkBit.

Subscribe to the SWUpdate progress IPC from the hawkBit notification thread and
emit coalesced progress snapshots through the existing hawkBit feedback
details[] path.

The progress detail has the following form:

[suricatta_progress] { status : DOWNLOAD, source : SURICATTA,
download : { bytes : 28128, percent : 42 },
artifact : { current : 1, name : image.rootfs.ext4.gz,
percent : 0, total : 1 } }

Progress snapshots share the same feedback path as normal log details. A global
feedback throttle limits feedback POST frequency for both normal log batches
and progress snapshots, so progress reporting does not create an additional
high-frequency telemetry channel.

Raw PROGRESS status messages are filtered from normal details[] handling to

avoid pushing unstructured progress noise into hawkBit action logs.

A corresponding hawkbitUI change can parse these detail entries and render
download/install progress. Without that UI change, the entries remain ordinary
hawkBit action-log details.

---
suricatta/server_hawkbit.c | 177 +++++++++++++++++++++++++++++++++++--
1 file changed, 170 insertions(+), 7 deletions(-)

+ ((numdetails == MAX_DETAILS) || (stop && !data_avail && numdetails > 0))) {

TRACE("Update log to server from thread");
if (server_send_deployment_reply(
channel,
@@ -1074,9 +1214,32 @@ static void *process_notification_thread(void *data)
percent = 0;
step++;
}

--
2.43.0

Ihor Fedorenco

unread,

May 28, 2026, 3:53:49 PM (8 days ago) May 28

to swup...@googlegroups.com

Add a progress card to the target details modal that displays coarse
SWUpdate/Suricatta deployment progress reported through hawkBit action-log
details.

The implementation introduces a target-progress parser for
[suricatta_progress] detail entries and derives a UI model containing phase,
source, download percentage, artifact step, artifact name, and byte counters.
Only strict progress detail entries are parsed, preventing unrelated log lines
or embedded feedback request dumps from being interpreted as progress.

The target progress container polls the latest target action logs and renders
the derived progress through a target-specific progress card and reusable
progress bar.

---
src/app/components/progress-bar/index.tsx | 52 ++++
.../progress-bar/styles.module.scss | 40 +++
.../components/target-progress-card/index.tsx | 101 ++++++++
.../target-progress-card/styles.module.scss | 62 +++++
.../target-progress-container/index.tsx | 115 +++++++++
.../styles.module.scss | 59 +++++
.../components/target-info-modal/index.tsx | 2 +
src/entities/target-progress.ts | 241 ++++++++++++++++++
8 files changed, 672 insertions(+)
create mode 100644 src/app/components/progress-bar/index.tsx
create mode 100644 src/app/components/progress-bar/styles.module.scss
create mode 100644 src/app/components/target-info-modal/components/target-progress-card/index.tsx
create mode 100644 src/app/components/target-info-modal/components/target-progress-card/styles.module.scss
create mode 100644 src/app/components/target-info-modal/containers/target-progress-container/index.tsx
create mode 100644 src/app/components/target-info-modal/containers/target-progress-container/styles.module.scss
create mode 100644 src/entities/target-progress.ts

diff --git a/src/app/components/progress-bar/index.tsx b/src/app/components/progress-bar/index.tsx

+ cancelled = true;
+

@@ -6,6 +6,7 @@ import TargetAssignedDistributionContainer from '@/app/components/target-info-mo
import TargetInstalledDistributionContainer from '@/app/components/target-info-modal/containers/target-installed-distribution-container';
import TargetMetadataContainer from '@/app/components/target-info-modal/containers/target-metadata-container';
import TargetTags from '@/app/components/target-info-modal/components/target-tags';
+import TargetProgressContainer from '@/app/components/target-info-modal/containers/target-progress-container';

+ name: progress.artifact.name,

--
2.43.0

Fabio Estevam

unread,

May 28, 2026, 4:01:28 PM (8 days ago) May 28

to Ihor Fedorenco, swup...@googlegroups.com

Hi Ihor,

On Thu, May 28, 2026 at 4:53 PM Ihor Fedorenco <iho...@gmail.com> wrote:
>
> Add a progress card to the target details modal that displays coarse
> SWUpdate/Suricatta deployment progress reported through hawkBit action-log
> details.
>
> The implementation introduces a target-progress parser for
> [suricatta_progress] detail entries and derives a UI model containing phase,
> source, download percentage, artifact step, artifact name, and byte counters.
> Only strict progress detail entries are parsed, preventing unrelated log lines
> or embedded feedback request dumps from being interpreted as progress.
>
> The target progress container polls the latest target action logs and renders
> the derived progress through a target-specific progress card and reusable
> progress bar.

Your Signed-off-by tag is missing.

Ihor Fedorenco

unread,

May 28, 2026, 5:19:08 PM (8 days ago) May 28

to swup...@googlegroups.com

Add a progress card to the target details modal that displays coarse
SWUpdate/Suricatta deployment progress reported through hawkBit action-log
details.

The implementation introduces a target-progress parser for
[suricatta_progress] detail entries and derives a UI model containing phase,
source, download percentage, artifact step, artifact name, and byte counters.
Only strict progress detail entries are parsed, preventing unrelated log lines
or embedded feedback request dumps from being interpreted as progress.

The target progress container polls the latest target action logs and renders
the derived progress through a target-specific progress card and reusable
progress bar.

Signed-off-by: Ihor Fedorenco <iho...@gmail.com>

---
src/app/components/progress-bar/index.tsx | 52 ++++
.../progress-bar/styles.module.scss | 40 +++

.../components/target-progress-card/index.tsx | 99 +++++++
.../target-progress-card/styles.module.scss | 53 ++++
.../target-progress-container/index.tsx | 115 +++++++++

.../components/target-info-modal/index.tsx | 2 +
src/entities/target-progress.ts | 241 ++++++++++++++++++

7 files changed, 602 insertions(+)

create mode 100644 src/app/components/progress-bar/index.tsx
create mode 100644 src/app/components/progress-bar/styles.module.scss
create mode 100644 src/app/components/target-info-modal/components/target-progress-card/index.tsx
create mode 100644 src/app/components/target-info-modal/components/target-progress-card/styles.module.scss
create mode 100644 src/app/components/target-info-modal/containers/target-progress-container/index.tsx

index 0000000..77320a7
--- /dev/null
+++ b/src/app/components/target-info-modal/components/target-progress-card/index.tsx
@@ -0,0 +1,99 @@

+'use client';
+
+import styles from './styles.module.scss';
+import Text from '@/app/components/text';
+import ProgressBar from '@/app/components/progress-bar';
+import { TargetProgress } from '@/entities/target-progress';
+

+export interface TargetProgressCardProps {

+export default function TargetProgressCard({

+ progress,
+ title = 'Progress',

+}: TargetProgressCardProps) {

+ if (!progress) {
+ return <ProgressEmptyState title={title} />;
+ }
+
+ const artifactName = progress.name.trim() || null;
+ const stepLabel = getStepLabel(progress);
+
+ return (
+ <div className={styles.container}>
+ <Text variant='heading-2'>{title}</Text>
+ <div className={styles.card}>
+ <div className={styles.header}>
+ <div className={styles.phase}>{progress.phase}</div>
+ <SourceItem source={progress.source} />
+ </div>
+ <ProgressBar value={progress.totalPercent} />

+ <div className={styles.oneline}>
+ {artifactName && (
+ <div className={styles.common}>{artifactName}</div>
+ )}
+ <BytesItem
+ currentBytes={progress.currentBytes}
+ totalBytes={progress.totalBytes}
+ />
+ </div>
+ {stepLabel && <MetaItem>{stepLabel}</MetaItem>}
+ </div>
+ </div>

+ );
+}
diff --git a/src/app/components/target-info-modal/components/target-progress-card/styles.module.scss b/src/app/components/target-info-modal/components/target-progress-card/styles.module.scss
new file mode 100644

index 0000000..b5077a4
--- /dev/null
+++ b/src/app/components/target-info-modal/components/target-progress-card/styles.module.scss
@@ -0,0 +1,53 @@

+.meta {
+ margin-top: 4px;
+ font-size: 13px;
+ opacity: 0.7;
+}
+
+.phase {
+ padding: 6px 10px;
+ border-radius: 999px;
+ font-size: 18px;
+ font-weight: 600;
+ text-transform: capitalize;
+ background: #e5e7eb;
+}
+

+.common {
+ margin-top: 12px;
+ font-size: 13px;
+ opacity: 0.75;
+}
+
+.empty {
+ margin-top: 20px;
+ color: #777;
+}
diff --git a/src/app/components/target-info-modal/containers/target-progress-container/index.tsx b/src/app/components/target-info-modal/containers/target-progress-container/index.tsx
new file mode 100644

index 0000000..1a79601

--- /dev/null
+++ b/src/app/components/target-info-modal/containers/target-progress-container/index.tsx
@@ -0,0 +1,115 @@
+'use client';
+
+import { useEffect, useMemo, useState } from 'react';

+import TargetProgressCard from '../../components/target-progress-card';

+ return <TargetProgressCard progress={null} title='Progress' />;
+ }
+ return <TargetProgressCard progress={progress} title='Progress' />;
+}
diff --git a/src/app/components/target-info-modal/index.tsx b/src/app/components/target-info-modal/index.tsx
index 0eaa17b..29065d5 100644

--- a/src/app/components/target-info-modal/index.tsx
+++ b/src/app/components/target-info-modal/index.tsx
@@ -6,6 +6,7 @@ import TargetAssignedDistributionContainer from '@/app/components/target-info-mo
import TargetInstalledDistributionContainer from '@/app/components/target-info-modal/containers/target-installed-distribution-container';
import TargetMetadataContainer from '@/app/components/target-info-modal/containers/target-metadata-container';
import TargetTags from '@/app/components/target-info-modal/components/target-tags';
+import TargetProgressContainer from '@/app/components/target-info-modal/containers/target-progress-container';

export default function TargetInfo() {
return (
@@ -26,6 +27,7 @@ export default function TargetInfo() {
},
{ title: 'Tags', component: <TargetTags /> },
{ title: 'Metadata', component: <TargetMetadataContainer /> },
+ { title: 'Progress', component: <TargetProgressContainer /> },
]}
/>
);
diff --git a/src/entities/target-progress.ts b/src/entities/target-progress.ts
new file mode 100644

index 0000000..61759f3

+ if (source !== 'SURICATTA') {

Ihor Fedorenco

unread,

May 28, 2026, 5:21:07 PM (8 days ago) May 28

to swupdate

thank you, Fabio

But beware: this is an RFC companion patch for hawkbitUI and is not intended to be applied
to the SWUpdate tree.

четвер, 28 травня 2026 р. о 23:01:28 UTC+3 Fabio Estevam пише:

Ihor Fedorenco

unread,

May 29, 2026, 5:07:08 AM (7 days ago) May 29

to swup...@googlegroups.com

hawkBit deployment feedback currently reports only coarse deployment state
changes and log details. This makes long-running downloads or installations
hard to observe from hawkBit.

Subscribe to the SWUpdate progress IPC from the hawkBit notification thread and
emit coalesced progress snapshots through the existing hawkBit feedback
details[] path.

The progress detail has the following form:

[suricatta_progress] { status : DOWNLOAD, source : SURICATTA,
download : { bytes : 28128, percent : 42 },
artifact : { current : 1, name : image.rootfs.ext4.gz,
percent : 0, total : 1 } }

Progress snapshots share the same feedback path as normal log details. A global
feedback throttle limits feedback POST frequency for both normal log batches
and progress snapshots, so progress reporting does not create an additional
high-frequency telemetry channel.

Raw PROGRESS status messages are filtered from normal details[] handling to
avoid pushing unstructured progress noise into hawkBit action logs.

A corresponding hawkbitUI change can parse these detail entries and render
download/install progress. Without that UI change, the entries remain ordinary
hawkBit action-log details.

Signed-off-by: Ihor Fedorenco <iho...@gmail.com>
---

suricatta/server_hawkbit.c | 175 +++++++++++++++++++++++++++++++++++--
1 file changed, 169 insertions(+), 6 deletions(-)

diff --git a/suricatta/server_hawkbit.c b/suricatta/server_hawkbit.c
index a9d09ac5..d72d9eb1 100644