iot-contact/fw/app/src, branch mdns

WIP: fw: app: Implement mDNS proof of concept

2025-08-13T15:43:25Z

TODO: Make this work. WireShark shows that some request / response is exchanged but it is unclear why the request is always canceled after timeout on the Zephyr side.

fw: app: http: Refactor settings handler

2025-05-07T16:14:13Z

fw: app: http: Set settings content type to text/json

2025-05-07T16:14:13Z

fw: app: Encode settings with JSON lib

2025-05-07T16:14:05Z

fw: app: http: Add working GET /settings.json

2025-04-16T16:03:40Z

fw: app: http: Add dummy GET /settings.json

2025-04-15T19:34:34Z

fw: app: syslog: Stop supporting CONFIG_LOG_BACKEND_NET_SERVER

2025-04-15T16:41:27Z

From now on the mixed format with IP and port is not supported. The settings system should keep them separate and first only the IP is configurable. Supporting this Kconfig option too is annoying and not necessary.

fw: app: syslog: Put only IP into syslog/target/ip

2025-04-15T16:33:31Z

The old format contained `[]:`. Nevertheless the format should be as strict as possible. Thus only the IP is used in the setting.

fw: app: syslog: Implement commit target

2025-04-15T16:06:32Z

fw: app: syslog: Make target IP configurable

2025-04-15T16:00:03Z

fw: app: Enable settings with NVS backend

2025-04-15T15:43:25Z

fw: app: Re-design web page

2025-04-12T10:11:33Z

This enables simple.css also for the device-hosted website and restructures the HTML a bit.

fw: app: Fix native_sim build

2025-04-02T18:43:29Z

To reduce the number of Kconfig options the network hack was added two both boards - the native_sim and nucleo_f767zi one. It reboots the device if the network connection cannot be established since this is a known bug of the nucleo board. Nevertheless it seems that for the native_sim board this command is not defined. Since it is a Linux application this makes somehow sense. This commit introduces the boolean Kconfig option `IOT_CONTACT_NETWORK_HACK` which is only enabled for the nucleo board fixing the native_sim build.

fw: app: update: Finish first HTTP PUT /update

2025-03-30T16:51:33Z

This adds marking the application firmware image in the secondary slot for a permanent update and rebooting the device. It is a known bug that the corresponding HTTP request is never properly closed since the device reboots while handling the request. Nevertheless the current state works and enables remote updates.

fw: app: update: Write uploaded image to flash

2025-03-30T16:51:33Z

This write the received firmware image data to the secondary MCUboot slot. This prepares an update. With the MCUboot shell it can be applied with: mcuboot request_upgrade permanent kernel reboot If the signature is valid the device will permanently update to the new application firmware. Otherwise it will refuse the new image and boot the old one.

fw: app: update: Add data rx on HTTP PUT /update

2025-03-30T16:51:33Z

This implements a HTTP handler capable of receiving the full data of the firmware image upload. The data is not handled at all and thus not written to flash. This is just an incremental step towards successful firmware image upload to the secondary MCUboot slot.

fw: app: update: Add source file and HTTP 204 handler

2025-03-30T16:51:33Z

This adds the HTTP PUT /update handler which just returns HTTP 204 No Content. This is the minimal first step towards a working /update handler.

fw: app: Reboot in case of no network

2025-03-30T11:38:05Z

Because of an issue likely related to hardware design on the nucleo_f767zi board (see issue [1] for details) the firmware should reboot in case network access cannot be established after 4 seconds. This makes the firmware more robust at the moment. As soon as iot-contact hardware without this issue exists the behavior can be changed again. [1]: https://github.com/zephyrproject-rtos/zephyr/issues/77794

fw: app: Move application firmware code here

2025-03-26T20:18:17Z

This makes the structure of the `fw` folder more clear and separates application-related code from bootloader- or rtos-related code.