Embedded web updating method and system

Abstract

The application relates to the technical field of embedded device software development, and aims to solve the problems of low webpage module updating efficiency, long iteration period and poor adaptability caused by the coupling of an embedded device webpage module and a webpage module; the application provides an embedded WEB updating method and system, the core of which is to construct a method and system for completely decoupling the embedded device webpage module from the device firmware; an automatic compiling server is introduced to independently compile and package the webpage module, thereby completely avoiding the long and time-consuming firmware compilation; meanwhile, an MQTT protocol is used to establish a long connection channel actively maintained by the device, so that the server can push an updating notification in real time in a scene where the device has no fixed IP; then, the device actively pulls a webpage package through an HTTP protocol according to the address in the notification, without manual intervention, the webpage firmware updating efficiency is effectively improved, and the network characteristics of the scattered deployment of embedded devices such as gateways and routers and the lack of fixed IP are adapted.

Description

Technical Field

[0001] This invention mainly relates to the field of embedded device software development technology, and in particular to an embedded WEB update method and system. Background Technology

[0002] In the development and iteration of embedded network devices such as gateways and routers, the web module is the core interactive carrier for realizing visual configuration, status monitoring, and functional debugging of the device. Its development and iteration efficiency directly affects the overall product development cycle and user experience. Currently, the industry generally adopts the whole firmware update approach for updating web modules of embedded devices. That is, the web code and device firmware are integrated and packaged into a unified image file, and the update is completed by local import or online image push. This mode has many inherent defects, which seriously restricts the development and iteration efficiency of the web module.

[0003] On the one hand, firmware compilation is time-consuming and resource-intensive. Due to the strong coupling between the web module and the firmware, even minor adjustments to the web front-end style and interaction logic require recompiling, linking, and packaging the entire device firmware. Furthermore, compiling embedded device firmware often involves complex cross-compilation environment configuration, hardware adaptation layer linkage, and integrity verification, with a single compilation typically taking tens of minutes or even hours, significantly increasing the iteration cycle of the web module. Simultaneously, traditional firmware updates require manual intervention in downloading images, logging into the device management interface, and triggering the upgrade process, resulting in low automation and susceptibility to update failures and device malfunctions due to human error.

[0004] On the other hand, the network characteristics of embedded network devices make automated deployment difficult to implement. Unlike internet servers, gateways, routers, and other devices typically do not have fixed IP addresses and are deployed in dispersed scenarios. This makes it impossible to achieve direct communication between automation tools and devices via conventional remote control protocols such as SSH. Consequently, it is impossible to adopt the end-to-end pipeline solution of mature automation tools such as automated build servers, encompassing compilation, packaging, and deployment. In existing internet web development, web page code can be compiled using an automated build server, and then the packaged file can be directly deployed to a server with a fixed IP address via SSH, with a single deployment taking only a few minutes. However, this model is completely unsuitable for the network environment and deployment characteristics of embedded devices.

[0005] In existing related technologies, some embedded devices employ online firmware upgrades or differential upgrade schemes in an attempt to optimize update efficiency, but they still cannot escape the core problem of the coupling between firmware and web modules. For example, some routers support local or online firmware upgrades, which essentially replace the entire firmware including the web module, failing to achieve independent updates for the web module. While some differential upgrade technologies can reduce the amount of data transmitted, they still rely on overall verification and flashing at the firmware level, unable to avoid the time-consuming firmware compilation issue, and do not involve a linkage mechanism between automated tools and the device. Furthermore, existing technologies mostly focus on the update stability of the firmware itself, lacking automated solutions for independent iteration of the web module, and failing to consider update triggering and data transmission issues in scenarios where the device has no fixed IP address and cannot be actively accessed.

[0006] In summary, existing methods for updating web modules in embedded devices suffer from low automation, long iteration cycles, and poor adaptability, failing to meet the high-frequency iteration development needs of web modules in devices such as gateways and routers. A technical solution is needed that can decouple web modules from firmware, adapt to device network characteristics, and support full-link automated updates to overcome existing technical bottlenecks and improve the development and iteration efficiency of embedded web modules. Summary of the Invention

[0007] The present invention aims to solve the problems of low update efficiency, long iteration cycle and poor adaptability of web page modules caused by the coupling between web page modules and firmware in embedded devices.

[0008] The technical solution adopted by the present invention to solve the above-mentioned technical problems On one hand, the present invention provides an embedded web update method, comprising the following steps: Step S1: Based on the automated compilation server, independently compile and package the web page module of the embedded device to generate a web page package, and upload the web page package to the static file server; Step S2: The automated compilation server pushes an update notification to the embedded device via the MQTT protocol. The update notification contains the HTTP download address of the web page package. Step S3: After receiving the update notification, the embedded device actively initiates a download request to the static file server based on the HTTP download address to obtain the web page package; Step S4: The embedded device decompresses and verifies the downloaded web page package, deploys it to the local web page storage directory, and updates the web page.

[0009] Furthermore, in step S1, a version number and verification code of the webpage package are generated and uploaded to the static file server together with the webpage package; the format of the version number is: year-month-day-hour-minute-second-submission hash value; the verification code is an MD5 checksum.

[0010] Furthermore, in step S2, the embedded device and the MQTT server maintain a long connection using a fixed heartbeat interval, and the MQTT server continuously receives update notifications pushed by the automated compilation server through the MQTT protocol.

[0011] Furthermore, in step S4, the embedded device automatically backs up the current old version of the web page resources before deploying the web page package, and performs a self-check after the web page package is deployed. If the self-check fails, it automatically reverts to the old version of the web page.

[0012] Furthermore, after an update is completed, fails, or is rolled back, the embedded device sends the update results back to the automated compilation server via the MQTT protocol.

[0013] Furthermore, the automated compilation server supports precise updates for a single device, and also supports batch push of update notifications to multiple embedded devices via the MQTT topic grouping mechanism.

[0014] On the other hand, the present invention also provides an embedded web update system, the system comprising: Automated compilation server: Used to compile web page modules separately, generate web page packages, and push update notifications via the MQTT protocol; Static file server: Used to receive web page packets uploaded by automated compilation server and provide HTTP download service; Embedded devices include MQTT clients, HTTP downloaders, decompression tools, and web deployment controllers; The MQTT client is used to receive update notifications pushed by the automated compilation server; the HTTP downloader is used to actively download updated web page packages according to the update notifications; the decompression tool is used to decompress the downloaded web page packages; and the web page deployment controller is used to deploy the web page packages. MQTT message server: Used to establish message communication links between automated build servers and embedded devices.

[0015] On the other hand, the web page deployment controller in the embedded device is also used to: back up the current web page before deploying the updated web page package, perform a self-check after successful deployment, and automatically revert to the current web page version when the self-check fails.

[0016] The beneficial effects of this invention are: 1. Significantly improves the efficiency of web page module iteration and reduces development costs: This invention achieves complete decoupling between web page modules and device firmware. The automated compilation server compiles and packages only the web page modules independently, without participating in the time-consuming and lengthy overall firmware compilation process, thus shortening the cycle of a single web page update. At the same time, the entire process does not require manual intervention in compilation, packaging, deployment, and result verification, avoiding the efficiency loss and error risks caused by manual operation, reducing repetitive work for developers, lowering R&D manpower and time costs, and adapting to the development needs of high-frequency changes in web page modules. 2. Better adapted to the network characteristics of embedded devices and overcomes deployment limitations: This invention adopts a combination of MQTT long connection notification and HTTP active retrieval, initiating connection and resource requests proactively by the device. It does not require changing the original network deployment architecture of the device or configuring a fixed public IP address, successfully solving the core problem that existing Internet Web automated deployment solutions cannot adapt to embedded devices. 3. Adaptable to diverse application scenarios: This invention supports precise updates for single devices and batch updates for multiple devices. Through the MQTT topic grouping mechanism, it can achieve differentiated update management for different types of embedded devices such as gateways and routers, adapting to the web page iteration needs of large-scale device clusters. At the same time, the solution is not bound to a specific front-end technology stack and is compatible with web page modules compiled by mainstream front-end frameworks such as Vue and React. It supports the replacement of different compression formats, verification algorithms, and message servers. Only minor parameter adjustments are needed to adapt to embedded devices with different hardware specifications and system architectures, demonstrating broad scenario adaptability and technical compatibility, reducing the cost of solution reuse and migration. Attached Figure Description

[0017] Figure 1 This is a flowchart of an embedded WEB update method according to the present invention. Detailed Implementation

[0018] In traditional solutions, the webpage is part of the firmware. Any minor interface adjustment requires recompiling the entire device firmware, a process that can take tens of minutes to several hours. Furthermore, embedded devices generally lack a fixed public IP address, making them unsuitable for direct access and deployment by automated tools like internet servers. The core of this invention is to construct a method and system that completely decouples the embedded device's webpage module from the device firmware. By introducing an automated compilation server, only the webpage module is independently compiled and packaged, completely avoiding the lengthy and time-consuming firmware compilation. Simultaneously, a long-term connection channel actively maintained by the device is established using the MQTT protocol, enabling the server to push update notifications in real time even when the device lacks a fixed IP address. The device then actively retrieves the webpage packet via HTTP based on the address in the notification, eliminating the need for manual intervention. This effectively improves the efficiency of webpage firmware updates and perfectly adapts to the network characteristics of distributed deployments and lack of fixed IP addresses for embedded devices such as gateways and routers.

[0019] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solutions of the present invention and should not be construed as limiting the scope of protection of the present invention.

[0020] This implementation uses a gateway device as the application platform, Git as the version control system, ZIP as the compression format, MD5 as the verification algorithm, MQTT protocol version 3.1.1, a static file server, and EMQ X as the MQTT message server. Figure 1 As shown, the embedded WEB update method of the present invention includes: Step 1: Code Commit and Deployment Trigger After developers complete the functional development, style optimization, or bug fixing of web page modules based on the preset front-end technology stack, they commit the locally modified web page source code to the remote code repository via a Git client. The commit includes a version log containing feature changes, the modifier, and a timestamp, ensuring code traceability. Developers log into the automated build server visualization platform and click the "Build Now" button in the preset embedded web page automated deployment task to trigger the full-chain automated process. Before starting, the automated build server task performs a pre-validation check, verifying the legality of code repository commit records and checking for syntax error warnings in the front-end code. Only after the validation passes can the automated build server continue with the subsequent build process, avoiding invalid builds.

[0021] Step 2: Independent compilation and packaging of web pages The automated build server node pulls the latest webpage code from the corresponding branch in the remote code repository via a Git plugin and calls a pre-defined front-end build script to start the build process. The build script first obfuscates and compresses JavaScript files, removing comments, redundant code, and debugging statements to improve loading efficiency and ensure code security; it merges and compresses CSS files, unifying style prefixes to adapt to different browser engines; and it streamlines and optimizes HTML files, removing whitespace and optimizing the document object model structure, while automatically replacing the paths of the compiled JavaScript and CSS files with local paths recognizable by the device. After compilation, the automated build server packages all front-end resources into a ZIP format webpage package according to a pre-defined directory structure.

[0022] The default directory structure includes a web resource folder, a configuration file folder, and a version information file in the root directory. The automated build server simultaneously generates a unique version number and an MD5 checksum; the version number uses a format combining year, month, day, hour, minute, second, and a commit hash value; the MD5 checksum is calculated from the entire ZIP package and is a 32-bit string. The automated build server writes the version number and MD5 checksum into a separate version information file and compresses this file along with the web package to ensure traceability of updates and file integrity.

[0023] Step 3: Uploading and Hosting the Webpage Package The automated compilation server automatically uploads the compiled and packaged ZIP web page package and version information file to the static file server via an HTTP POST request. Upon receiving the file, the static file server archives and stores it according to a directory structure based on device type and web page version number. The static file server also generates a unique and accessible HTTP download address for each web page package. To ensure security, the static file server is configured with access control, allowing download requests only from the internal network segment to which the embedded device belongs.

[0024] Step 4: Push MQTT update notification After the static file server returns a successful file upload response, the automated compilation server initiates a connection to the MQTT message server by executing a script. Upon successful connection, the automated compilation server pushes update commands to preset topics. These topics use a unique device identifier as their topic suffix. To enable simultaneous updates from multiple devices, the automated compilation server can push commands to group topics, supporting batch reception by different device types. Update commands are encapsulated in JSON format, containing core fields such as the HTTP download address of the webpage, version number, MD5 checksum, file size, validity period, and command number. A default validity period is set; devices exceeding this period must re-request. The command number uniquely identifies this update task. After push completion, the automated compilation server waits for confirmation from the MQTT message server. If the push fails, the automated compilation server retryes at set time intervals. If the retry also fails, the automated compilation server logs the changes, terminates the process, and sends an alert to the developers.

[0025] Step 5: The device receives the instruction and downloads it. The gateway device's built-in service module runs automatically after device startup. The MQTT client within this module continuously maintains a long-lived connection with the MQTT message server, with a heartbeat interval set to 60 seconds to ensure connection stability. The MQTT client also subscribes to its own uniquely identified topic and group topics. When the MQTT client receives an update command, the device first parses and validates the command. Validation includes: whether the command's JSON format is correct, whether the version number is higher than the current local webpage version to avoid downgraded updates, and whether the validity period has expired. If downgraded updates are required, version validation can be disabled through configuration. After successful validation, the device's HTTP downloader proactively initiates a GET request to the HTTP address in the command. The request includes the device's unique identifier as a header parameter for secondary permission verification by the static file server. After downloading, the device reads the locally calculated MD5 checksum of the webpage packet and compares it with the checksum in the command. If they do not match, the device proactively initiates a re-download. After five failed downloads, the device logs an error message containing the reason for the failure and the number of retries, terminates the update, and sends the download failure result to the automated compilation server via MQTT.

[0026] Step 6: Unzip and deploy the webpage package After the MD5 checksum matches, the device-side decompression tool decompresses the ZIP web page package. The decompression tool is developed based on the zlib library. Before decompression, the device checks the remaining storage space in the preset web page storage directory to ensure it is at least twice the size of the web page package, preventing decompression failure due to insufficient space. During decompression, the tool extracts resource files to the storage directory according to the internal directory structure of the web page package, overwriting older files. Simultaneously, the device automatically backs up older web page resources, compressing them into a backup package. The backup file retains three most recent versions; if this number is exceeded, the oldest version is automatically deleted, providing support for rollback operations. After deployment, the web page deployment controller immediately initiates a self-check. The self-check simulates a user's access to the core paths of the device configuration page, including the login page, network configuration page, and status monitoring page. The self-check includes checking the integrity of HTML page loading, whether JavaScript scripts execute errors, whether CSS styles render correctly, and whether static resources are accessible. If the self-check passes, the device updates its local web page version record, writing the latest version number to the version configuration file. The device configuration interface automatically loads the new web page by refreshing the cache, without needing to restart the device's core services. If the self-check fails, for example, if a page times out or a script error occurs, the device immediately performs a rollback operation, deletes the newly deployed new version files, decompresses the most recently backed-up old version web page package and restores it to the storage directory, and records a rollback log, which clearly states the specific page that failed the self-check and the reason for the failure.

[0027] Step 7: Update the results feedback After a gateway device completes an update, fails to update, or rolls back, it pushes a result message to the pre-defined feedback topic on the automated compilation server via an MQTT client. The result message is in JSON format and includes the command number, unique device identifier, update status, current webpage version number, execution time, and error information. The update status includes three states: success, failure, or rollback. Error information is mandatory for update failures or rollbacks. Upon receiving the feedback message, the automated compilation server synchronizes the update status to the visualization panel, displaying it categorized by device identifier, and simultaneously writes the update record to the database. For devices that fail to update or roll back, the automated compilation server annotates the failure reason in the visualization panel, such as download failure, verification inconsistency, or self-check error, facilitating quick troubleshooting by developers. Once all target devices have provided feedback, the automated compilation server generates a visual update report. The report includes the trigger time of the update, version number, number of devices involved, success / failure ratio, and average execution time. Developers can export the report for future reference, forming a complete update loop.

Claims

1. An embedded web update method, characterized in that, Includes the following steps: Step S1: Based on the automated compilation server, independently compile and package the web page module of the embedded device to generate a web page package, and upload the web page package to the static file server; Step S2: The automated compilation server pushes an update notification to the embedded device via the MQTT protocol. The update notification contains the HTTP download address of the web page package. Step S3: After receiving the update notification, the embedded device actively initiates a download request to the static file server based on the HTTP download address to obtain the web page package; Step S4: The embedded device decompresses and verifies the downloaded web page package, deploys it to the local web page storage directory, and updates the web page.

2. The embedded WEB update method according to claim 1, characterized in that, In step S1, a version number and verification code of the webpage package are also generated and uploaded to the static file server together with the webpage package; the version number is in the format of: year-month-day-hour-minute-second-submission hash value; the verification code is an MD5 checksum.

3. The embedded WEB update method according to claim 1, characterized in that, In step S2, the embedded device and the MQTT server maintain a long connection using a fixed heartbeat interval. The MQTT server continuously receives update notifications pushed by the automated compilation server via the MQTT protocol.

4. The embedded WEB update method according to claim 1, characterized in that, In step S4, before deploying the web page package, the embedded device automatically backs up the current old version of the web page resources, and performs a self-check after the web page package is deployed. If the self-check fails, it automatically reverts to the old version of the web page.

5. The embedded WEB update method according to claim 1, characterized in that: After an update is completed, fails, or is rolled back, the embedded device sends the update results back to the automated compilation server via the MQTT protocol.

6. The embedded WEB update method according to claim 1, characterized in that: The automated build server supports single-device updates and also supports batch push of update notifications to multiple embedded devices via the MQTT topic grouping mechanism.

7. An embedded web update system for implementing the embedded web update method according to any one of claims 1 to 6, characterized in that, include: Automated compilation server: Used to compile web page modules separately, generate web page packages, and push update notifications via the MQTT protocol; Static file server: Used to receive web page packets uploaded by automated compilation server and provide HTTP download service; Embedded devices include MQTT clients, HTTP downloaders, decompression tools, and web deployment controllers; The MQTT client is used to receive update notifications pushed by the automated compilation server; the HTTP downloader is used to actively download updated web page packages according to the update notifications; the decompression tool is used to decompress the downloaded web page packages; and the web page deployment controller is used to deploy the web page packages. MQTT message server: Used to establish message communication links between automated build servers and embedded devices.

8. An embedded WEB update system according to claim 7, characterized in that: The web page deployment controller in the embedded device is also used to back up the current web page before deploying the updated web page package, perform a self-check after successful deployment, and automatically revert to the current web page version if the self-check fails.

Images