Hello, in this post, we'll discover more about the MCUBoot bootloader and its integration into Zephyr/NCS. What is MCUBoot? MCUBoot is a lightweight bootloader capable of multiple tasks: • Boot an image stored in flash • Verify an image in flash • Swap images in slots • Launch the TFM environement • Wait for Serial recovery • ... It is board/OS agnostic and can be ported to any board with simple adaptations. In this post, we'll focus on its integration in the nRF Connect SDK (NCS). Why using MCUBoot? Having a bootloader is often a requirement for most project. It allows upgrade management as well as image integrity checks and a lot more features as we saw previously. The basics images management is needed to offer an upgrade system to the user. As MCUBoot can be as trimmed down to ~24kB, it is suited for low memory system. MCUBoot can also be upgraded if a first stage bootloader is present before it. In that case, it requires two MCUBoot slots to be able to perform verification and images swapping if needed. Upgrade modes MCUBoot allows multiple upgrade types: • Single slot: Only one application slot is available and is always overwritten in case of an upgrade. Upgrade only possible from MCUBoot • Dual slot: Two slots are reserved for the application. When upgrading, the slot 2 is written, then MCUBoot checks if the image is valid and swap it into slot 1, as only slot 1 can be executed. • Serial recovery: Allow MCUBoot to upgrade/overwrite an image by launching a SMP client, waiting on UART commands, containing the new image to write. The most commonly used is the dual slot one, as it allows to keep a backup of the old application, as well as defining some rules to validate the new image. It's main disadvantage is that the application can only take up to 1/2 of the remaining memory (after MCUBoot and the other storage partitions are set). How to use MCUBoot in NCS In NCS, MCUBoot can be enabled using the sysbuild configuration by enabling: SB_CONFIG_BOOTLOADER_MCUBOOT=y This will compile MCUBoot for your project and automatically create the corresponding partitions if dynamic partitioning is used. More information about how to configure MCUBoot can be found on the official nRF documentation. Image upgrade from an application The classical and most common way of upgrading an application is through the DFU Target API available in an nRF application. It is only possible in a dual slots setup, as the application cannot erase itself if we are using a single slot. Here is a pseudo-code using the DFU Target API: /* Set the update buffer used by the DFU API */ dfu_target_mcuboot_set_buf(mcuboot_buf, MCUBOOT_BUF_SZ); /* Initialize the DFU Target API with the image info (type, size)*/ dfu_target_init(DFU_TARGET_IMAGE_TYPE_MCUBOOT, 0, img_size, dfu_target_callback_handler); /* Send images chunks */ while (images bytes left) { bytes_to_write = read_image_from_sd(dec_buf); dfu_target_write(dec_buf, bytes_to_write); } /* Notify that the flash is done and all chunks were sent */ dfu_target_done(true); /* Ask MCUBoot to check for an update on all slots */ dfu_target_schedule_update(-1); /* Reboot to let MCUBoot upgrade the system) */ sys_reboot(SYS_REBOOT_COLD); Once MCUBoot boots again, it will check for the image validity (version higher, correct slot, ...) and integrity (correct encryption key, correct signature, ...) and swap it if it is valid. Then the application can do some more checks (comparing values stored in NVS for example) to validate and confirm the upgrade using the following function: boot_write_img_confirmed(); Conclusion We now can setup and use MCUBoot to upgrade our system! This is the first step to consider when designing a system requiring upgrades, as it will determine: • What to enable • How to configure the upgrade • What sizes are available for my different system components (bootloader, application, TFM, NVS, ...) • How and if the upgrade can be recovered in case it fails I hope you are now ready to dig deeper in MCUBoot and see what else it has to offer! Its code is always fully open-source and is a great way of learning the boot process and its capabilities. I also strongly encourage you to read the available MCUBoot samples from NRF! Links: • https://docs.nordicsemi.com/bundle/ncs-latest/page/mcuboot/readme-ncs.html • https://docs.mcuboot.com/ • https://docs.zephyrproject.org/latest/services/device_mgmt/dfu.html

Hello everyone! Today we'll cover the topic on how to enter Serial Recovery boot mode in MCUBoot, using Zephyr. This can be handful if no user input is available, as traditionally, it is how you let the user initiate Serial Recovery. In this article, we'll see: • How configure MCUBoot to enable Serial Recovery • How to add a retention memory to communicate between our application and MCUBoot • How to request Serial Recovery mode from the application • What is needed once entering the Serial Recovery mode Configuring MCUBoot for Serial Recovery The first step is enabling serial recovery support in MCUBoot. This is done through the MCUBoot Kconfig options. You’ll need to make sure your build of MCUBoot is compiled with: CONFIG_MCUBOOT_SERIAL=y Depending on your board, you may also need to configure the UART device used by MCUBoot for recovery. For example: CONFIG_MCUBOOT_SERIAL_UART=1 This ensures that MCUBoot includes the serial recovery subsystem and listens on the correct UART port for incoming SMP commands. Adding Retention Memory To request Serial Recovery from your application, Zephyr offers the retention memory API. It allows one to define an area in the DTS, which will be shared across you application and MCUBoot. Here is how to add it in the DTS overlay: / { /* Define a non-init RAM region as retained memory */ sram@2003FC00 { compatible = "zephyr,memory-region", "mmio-sram"; reg = <0x2003FC00 DT_SIZE_K(1)>; zephyr,memory-region = "RetainedMem"; status = "okay"; /* Define a small partition dedicated to boot mode (1 byte) */ retainedmem { compatible = "zephyr,retained-ram"; status = "okay"; #address-cells = <1>; #size-cells = <1>; retention0: retention@0 { compatible = "zephyr,retention"; status = "okay"; reg = <0x0 0x1>; }; }; }; /* Tell Zephyr this retention region is used for boot-mode */ chosen { zephyr,boot-mode = &retention0; }; }; /* Reduce SRAM0 usage by 1 byte to account for non-init area */ &sram0 { reg = <0x20000000 0x3FFFF>; }; And in the config (prj.conf or an overlay): CONFIG_RETAINED_MEM=y CONFIG_RETENTION=y CONFIG_RETENTION_BOOT_MODE=y # Enable MCUboot serial recovery feature CONFIG_MCUBOOT_SERIAL=y CONFIG_BOOT_SERIAL_BOOT_MODE=y Requesting Serial Recovery from the Application Once the retention mechanism is in place, the application can request Serial Recovery mode by: 1. Writing the predefined flag value into the retention memory. 2. Triggering a system reset (sys_reboot(SYS_REBOOT_COLD) in Zephyr). #include <zephyr/retention/bootmode.h> #include <zephyr/sys/reboot.h> #include <zephyr/logging/log.h> LOG_MODULE_REGISTER(app, LOG_LEVEL_INF); void request_serial_recovery(void){ int ret; ret = bootmode_set(BOOT_MODE_TYPE_BOOTLOADER); if (ret) { LOG_ERR("Failed to set boot mode (err %d)", ret); return; } sys_reboot(SYS_REBOOT_COLD); /* Should not reach here */ } On the next startup, MCUBoot detects the flag and drops directly into Serial Recovery, waiting for a flashing system to send new firmware. What Happens in Serial Recovery Mode When MCUBoot is running in Serial Recovery, it uses the Simple Management Protocol (SMP) over UART. This means it expects SMP packets containing image management commands (upload, erase, test, confirm, etc.). The commands implementation can be found at bootloader/mcuboot/boot/boot_serial/src/boot_serial.c To make use of this, you need an SMP-capable machine another Zephyr device configured as an SMP client. Some common options: • From a host machine: use mcumgr, the reference SMP tool. For example: mcumgr -t 30 -c serial1 image upload app_update.bin • From another Zephyr board: you can build Zephyr with the mcumgr subsystem enabled, turning the board into an SMP client. In this case, you’ll need to configure the board with: CONFIG_MCUMGR=y CONFIG_MCUMGR_CMD_IMG_MGMT=y CONFIG_MCUMGR_CMD_OS_MGMT=y CONFIG_MCUMGR_SMP_UART=y Then, your second board can act as the update host and push firmware into the target board running MCUBoot in Serial Recovery, from an SDCard, WiFi, ... Conclusion With this setup, your application can programmatically request Serial Recovery, and MCUBoot will listen for new firmware uploads via SMP, whether from a PC host tool like mcumgr or from another SMP capable device.

Since 9.x it becomes possible to patch LVGL to natively support new pixel formats. It can be a simple color swap mode not originally planned or a super specific display pixel format. In this posts serie, we will cover the necessary steps for you to add such a custom pixel format and end up with a patch to apply to LVGL sources. In the following examples, we'll use a custom pixel format on ABRG 32bpp (8A, 8B, 8R, 8G). This is a made up format and is only used as an example purpose. We'll name this pixel format ABGR8888. Adding the color format to lv_color.h The first step is to let LVGL know about our new pixel format. To do this, we'll add our pixel format in src/misc/lv_color.h in the lv_color_format_t enum. Here we need to add the color fomat and specify to use it natively if LVGL is configured in 32bpp: ... LV_COLOR_FORMAT_ABGR8888 = 0x36, ... #elif LV_COLOR_DEPTH == 32 LV_COLOR_FORMAT_NATIVE = LV_COLOR_FORMAT_ABGR8888, #else Then, complete both lv_color_format_get_bpp and lv_color_format_has_alpha: uint8_t lv_color_format_get_bpp(lv_color_format_t format) { ... case LV_COLOR_FORMAT_ARGB8888: case LV_COLOR_FORMAT_XRGB8888: case LV_COLOR_FORMAT_ABGR8888: /* Added this line on the return 32 case */ return 32; ... } bool lv_color_format_has_alpha(lv_color_format_t format) { ... case LV_COLOR_FORMAT_ARGB4444: case LV_COLOR_FORMAT_ABGR8888: /* Added here as our pixel format has an alpha chanel */ return true; ... } We now are ready to implement the blending functions! Adding the blending functions LVGL needs a way to know how to blend a pixel format into a draw buffer, which can be the same or another color format. In our case, we are only interrested to blend our custom pixel format with itself, but the procedure is the same to blend any other format. The blending in LVGL can be of two different type: • Color blending: Simple blending of a single color in a given area. Consist of filling an area with the color, with or without masking. • Image blending: Blending of an image descriptor comming with its source buffer to blend. Can be with or without mask. In the examples, we only cover the color/image blend with no mask or with a mask, but not the AA, to keep it simple. So first, create your custom blending files (which you can copy paste from existant) in src/draw/sw/blend/: • lv_draw_sw_blend_to_abgr8888.c: Functions definitions • lv_draw_sw_blend_to_abgr8888.h: Functions declarations Color blending function The color blending function has this prototype (can also be customized): blend_color_to_format(lv_draw_sw_blend_fill_dsc_t * dsc) Where the dsc parameter contains all the information about the color, the destination buffer, the coordinates, ... You should en up with something like this: static inline void *drawbuf_next_row(const void *buf, uint32_t stride) { return (void *)((uint8_t *)buf + stride); } void lv_draw_sw_blend_color_to_abgr8888(lv_draw_sw_blend_fill_dsc_t * dsc) { int32_t w = dsc->dest_w; int32_t h = dsc->dest_h; lv_color_t color_abgr8888; lv_opa_t opa = dsc->opa; const lv_opa_t * mask = dsc->mask_buf; int32_t mask_stride = dsc->mask_stride; uint32_t *dest_buf_abgr8888 = dsc->dest_buf; int32_t dest_stride = dsc->dest_stride; int32_t x; int32_t y; /* Invert here, as we did not patched lv_color_make() */ color_abgr8888.blue = = dsc->color.red; color_abgr8888.green = = dsc->color.green; color_abgr8888.red = = dsc->color.blue; LV_UNUSED(w); LV_UNUSED(h); LV_UNUSED(x); LV_UNUSED(y); LV_UNUSED(opa); LV_UNUSED(mask); LV_UNUSED(mask_stride); LV_UNUSED(dest_stride); /* Simple fill, no mask, full opacity */ if(mask == NULL && opa >= LV_OPA_MAX) { for(y = 0; y < h; y++) { for (x = 0; x < w; x++) { dest_buf_u8[x] = color_abgr8888; } /* Get next row */ dest_buf_abgr8888 = drawbuf_next_row(dest_buf_abgr8888, dest_stride); } /* Fill with mask */ } else if(mask && opa >= LV_OPA_MAX) { for(y = 0; y < h; y++) { for(x = 0; x < w; x++) { /* Mask is on 8bits */ uint8_t mask8 = *((uint8_t *)&mask[x]); /* Apply color to all the mask pixel which are not 0 */ if(mask8 != 0x00) { dest_buf_u8[x] = LV_OPA_MIX2(color_abgr8888.alpha, mask); } } /* Get next row */ dest_buf_abgr8888 = drawbuf_next_row(dest_buf_abgr8888, dest_stride); mask += mask_stride; } } } We can see the two different branches, once without masking, once with a mask. The mask is a uint8_t array containing a mask per bit (0-255), defining how to blend each pixel. The masking branch is taken for example when drawing letters, which are just a rectangle area with a mask to only draw on the letters outlines, with AA. Now add the function prototype in the previously created header. Image blending function Then is the image blending function, which acts exactly like the color blending, but with a source buffer instead of a single color: void lv_draw_sw_blend_image_to_abgr8888(lv_draw_sw_blend_image_dsc_t * dsc) { switch(dsc->src_color_format) { case LV_COLOR_FORMAT_ABGR8888: abgr8888_image_blend(dsc); break; default: LV_LOG_WARN("Not supported source color format"); break; } } static uint8_t blend_channel(uint8_t c1, uint8_t c2, uint8_t mask) { return (uint8_t)(((c1 * (255 - mask)) + (c2 * mask)) / 255); } static uint32_t blend_abgr(uint32_t color1, uint32_t color2, uint8_t mask) { uint8_t a1 = (color1 >> 24) & 0xFF; uint8_t b1 = (color1 >> 16) & 0xFF; uint8_t g1 = (color1 >> 8) & 0xFF; uint8_t r1 = color1 & 0xFF; uint8_t a2 = (color2 >> 24) & 0xFF; uint8_t b2 = (color2 >> 16) & 0xFF; uint8_t g2 = (color2 >> 8) & 0xFF; uint8_t r2 = color2 & 0xFF; uint8_t a = blend_channel(a1, a2, mask); uint8_t b = blend_channel(b1, b2, mask); uint8_t g = blend_channel(g1, g2, mask); uint8_t r = blend_channel(r1, r2, mask); return (a << 24) | (b << 16) | (g << 8) | r; } static void abgr8888_image_blend(lv_draw_sw_blend_image_dsc_t * dsc) { int32_t w = dsc->dest_w; int32_t h = dsc->dest_h; lv_opa_t opa = dsc->opa; uint32_t * dest_buf = dsc->dest_buf; int32_t dest_stride = dsc->dest_stride; const uint32_t * src_buf = dsc->src_buf; int32_t src_stride = dsc->src_stride; const lv_opa_t * mask_buf = dsc->mask_buf; int32_t mask_stride = dsc->mask_stride; int32_t dest_x; int32_t src_x; int32_t y; if(dsc->blend_mode == LV_BLEND_MODE_NORMAL) { if(mask_buf == NULL && opa >= LV_OPA_MAX) { for(y = 0; y < h; y++) { for(dest_x = 0, src_x = 0; dest_x < w; dest_x++, src_x++) { dest_buf[dest_x] = src_buf[src_x]; } dest_buf = drawbuf_next_row(dest_buf, dest_stride); src_buf = drawbuf_next_row(src_buf, src_stride); } } else (mask_buf != NULL && opa >= LV_OPA_MAX) { for(y = 0; y < h; y++) { for(x = 0; x < w; x++) { uint8_t mask = mask_buf[x] if (mask != 0x00) { dest_buf[x] = blend_abgr(dest_buf[x], src_buf[x], mask); } } dest_buf = drawbuf_next_row(dest_buf, dest_stride); src_buf = drawbuf_next_row(src_buf, src_stride); mask += mask_stride; } } } } We see that like before we treat both with or without masking. In the masking case, the destintaion buffer is also used in the mix. Now add the function prototype in the previously created header. Adding our functions to LVGL SW draw We also see that we need another function called lv_draw_sw_blend_image_to_abgr8888, as it will now need to be added to the common lv_sw_blend function found in lv_draw_sw_blend.c file. Here we need to add both calls to our new functions. So first include the header: #include "lv_draw_sw_blend_to_abgr8888.h In lv_sw_blend, we can now add our functions calls. This function have two main branches: /*Color fill, as now image source is specified*/ if(blend_dsc->src_buf == NULL) { ... switch(layer->color_format) { ... case LV_COLOR_FORMAT_ABGR8888: lv_draw_sw_blend_color_to_abgr8888(&fill_dsc); break; } } else { switch(layer->color_format) { ... case LV_COLOR_FORMAT_ABGR8888: lv_draw_sw_blend_image_to_abgr8888(&image_dsc); break; } } We now are ready to let LVGL use our custom pixel format for basic color and image blending, which allow use to draw simple LVGL objects, letters and already decoded images (more on that in a future post!). Conclusion This first part covers the very basics of adding a custom pixel format to LVGL 9.x. It is kept pretty simple for example purpose, but I strongly encourage you to check the already existing work in LVGL to base your addition on it. In the next part we'll see how to add transformation to our pixel format, to be able to rotate and scale our objects!

So you want to include images into your LVGL project, running on a nRF5340. You prepare your images, convert them using LVGL online tool, integrate them into your application, and.... end up with 167% of your flash used! Optimizing your images is crucial in low resources system such as MCUs. As a quick example, if you want to use a full size background for your application, using a 480x320 display, using ARGB8888 you end up with: 480 * 320 * 4 = 614400 B = 614.4 kB Which, in some system corresponds to more than half the flash size. So what can we do to optimize it? The following sections will show solutions to reduce flash usage. Using RLE compression RLE is a simple compression format which group contiguous symbols together. Here is a simple example: AAABBCCCCD (10B) -> RLE compression -> 3A2B4C1D (8B) It is very useful when your image have a lot of contiguous same color pixels. It becomes a bit less interesting with images using a lot of colors and blurring as there won't be that much contiguous pixels. To convert an image to RLE, LVGL offers an utility script in scripts/LVGLImage.py: python3 lvgl/scripts/LVGLImage.py --ofmt C --cf RGB565 --compress RLE -o my_image.c my_image.png This will convert my_image.png to a .c file in RGB565 format, compressed using RLE. To be able to use this compressed image in LVGL, you must activate these configs: • LV_USE_RLE 1: Enable RLE processing. • LV_BIN_DECODER_RAM_LOAD 1: Enable decoding the binary images in RAM. Note that RLE decompression can use quite a lot of RAM, as it will need decompression buffers while loading the image. Using indexed color format The indexed color format allow to represent each pixel as an index, pointing to a color in a palette,which is encoded next to the pixels data. It means that if your image has <= 256 colors, the palette index can be represented as 1B (index 0 to 255). The palettes are written as ARGB8888, meaning that a 256 colors palette = 256 * 4 = 1024B = 1kB. To convert an image to indexed color, you can also use LVGL scripts/LVGLImage.py: python3 lvgl/LVGLImage.py --ofmt C --cf I8 -o my_image.c my_image.png The script internally convert your base PNG to an indexed PNG if needed, and then convert it to a .c. One can use these color format (parameter --cf): • I1: 1 color palette • I2: 4 color palette • I4: 16 colors palette • I8: 256 colors palette Using A* format (for grayscale images) The last format(s) we will talk about are the A* formats, where * can be 1, 2, 4, 8. This format allows to only encode the transparency. Like this, you end up with a grayscale image, which can the be recolored using the style.recolor property. To convert an image to A8, you can also use LVGL scripts/LVGLImage.py: python3 lvgl/LVGLImage.py --ofmt C --cf A8 -o my_image.c my_image.png Conclusion We saw that multiple options are available when you need optimizing your images size. Depending on your base image, it may be better to use one or the other method, so my advice would be to try playing a bit with these color formats and see what works best for your images. If you need any assistance in optimizing your images for your project, don't hesitate to contact us! Links: • RLE compression: https://en.wikipedia.org/wiki/Run-length_encoding • Indexed color format: https://en.wikipedia.org/wiki/Indexed_color#:~:text=In%20computing%2C%20indexed%20color%20is,2%2Dbit%20indexed%20color%20image • LVGL Image doc: https://docs.lvgl.io/9.2/overview/image.html#overview-image

So you just received a Nordic board for your next project. First thing you do is to open the documentation to see how to setup a project for your board (at least it should be the first thing to do!). Then you quickly realize that in the Nordic world, you have two main ways of managing the environment and your development: • The nRF Connect for Desktop • The VSCode nRF Connect Extension Pack So why would you choose one over the other? First it may be a matter of habits. Maybe you absolutely despise VSCode and never want to ever touch it, maybe downloading yet another GUI app to manage you development is the last straw for you. The good news is that you can use one or the other for almost all your tasks: • Manage your SDKs & toolchains • Flash/erase/recover the board • Monitor the board serial output on a console • Configure the DTS But not everything can be done by the nRF Connect for Desktop. The nRF Connect for Desktop has no way to let you write and build your applications. The build can be done using the CLI tools offered by Nordic (nrfutils, west, ...). On the other hand, the VSCode extension allows you to build your project as well as managing your build configurations for your applications. It also hide the build commands under some Tasks linked to your build configuration to help you concentrate on the coding part. My take on this is that the VSCode extension is becoming more and more robust and features complete. It shows by Nordic pushing to use the VSCode extension in their user guides/doc. For having used theses two in my projects, I think the VSCode extension is overall the best choice, as it really is an all-in-one solution, actively maintained and developed by Nordic. Here is my pro and cons for each one. VSCode Extension Pack: ✅ All-in-one development kit ✅ Integrates in the VSCode ecosystem ✅ Heavily maintained ❌ Hide the build details and how the underlying build system works ❌ Can sometimes be buggy nRF Connect for Desktop: ✅ Very easy to use ✅ Clear roles of the different applications ✅ Integrated updater ❌ Must compile your code aside ❌ Standalone GUI application In the end, it is mainly a matter of preference and usage. For example I really like the build configurations management of the VSCode extension Pack as well as its powerful build tasks, but I always use the Serial Monitor of the nRF Connect for Desktop to monitor my board output to have a nice view in another window. As for everything, the correct usage of a tool is the usage you are comfortable with the most!

In the world of IoT devices being deployed everywhere, it sometimes become difficult to keep track of your fleet logs and status. Fluent-Bit is a lightweight and high performance telemetry agent for logs, device metric or traces. It allows: • Definition of Input, which correspond to the data you want to collect • Usage of Parsers to transform any unstructured log entry and give them a structure that makes easier it processing and further filtering • Filters pass to only select a specific subset of your logged data to be forwarded • Flexible Output definition which allows to easily route the processed data to any location Here is a simple example to show how to collect RAM usage of a specific application called my-amazing-app: [INPUT] Name proc Proc_Name my-amazing-app Interval_Sec 1 Interval_NSec 0 Fd true Mem true [OUTPUT] Name stdout Match * [OUTPUT] Name http Match * Host 192.168.2.3 Port 80 URI /something This will monitor the memory usage of the application my-amazing-app every second. The two OUTPUT are defined to prints the logs on stdout and send them on a specific URI at the IP 192.168.2.3. Fluent-Bit defines a lot of input type to gather system metrics. It is also possible to use custom commands to logs more specific data. For example, let's say we want to get the disk usage of my main disk. The df command gives this output: $ df -k Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 3246320 3500 3242820 1% /run efivarfs 438 309 125 72% /sys/firmware/efi/efivars /dev/nvme0n1p3 975262680 806211136 119437160 88% / tmpfs 16231600 414416 15817184 3% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 16231600 0 16231600 0% /run/qemu /dev/nvme0n1p1 243852 6272 237580 3% /boot/efi tmpfs 3246320 5936 3240384 1% /run/user/1001 Knowing that the disk is the /dev/nvme0n1p3, we can then use a combination of grep and jq to gather the information and output them in a JSON format: $ df -k | grep nvme0n1p3 | jq -R -c -s 'gsub(" +"; " ") | split(" ") | { "disk_total": .[1], "disk_used": .[2], "disk_avail": .[3]}' {"disk_total":"975262680","disk_used":"806195688","disk_avail":"119452608"} Next we must fill the Fluent-Bit configuration file with the new Input, using the Exec plugin: [INPUT] Name exec Tag disksize Command df -k | grep nvme0n1p3 | jq -R -c -s 'gsub(" +"; " ") | split(" ") | { "disk_total": .[1], "disk_used": .[2], "disk_avail": .[3]}' Parser json Interval_Sec 3600 [FILTER] Name nest Match disksize Operation nest Wildcard * Nest_under custom [OUTPUT] Name http Match * Host 192.168.2.3 Port 80 URI /something This will gather the disk size using our custom command every hour. The Nest FILTER allow to nest all the data gathered from the JSON under a custom key: [0] disksize: [[1737017868.008708965, {}], {"custom"=>{"disk_total"=>"975262680", "disk_used"=>"806364640", "disk_avail"=>"119283656"}}] Useful links: • Fluent-Bit documentation: https://docs.fluentbit.io/manual • Torizon OS example: https://developer.toradex.com/torizon/torizon-platform/device-monitoring-in-torizoncore/