Technical decision guide · Connected products

How to plan device management and OTA updates for connected products

Just because an IoT device sends initial data to the server does not mean that the product is manageable. Initial setup, device identification, authorization, disconnections, remote command and software update should be designed together. This guide explains which behaviors and technical deliverables should be determined at the outset in a customer-specific device and server project.

Product development guide · · Publication: · Update:

Describe your project Read the guide
Identity, telemetry, commands and software updates flow between the connected device and the server
Conceptual technical illustration · Technical decision guide · Connected products
life cycleFrom production to field maintenance
ArchitectureDevice, connection and server together
DeliverySource files, interface and operating information

VOMRO engineering approach

Turn connectivity from a demo function into a maintainable product feature.

In a pilot, it may seem sufficient for several devices to appear on the same panel. When the field grows, questions such as which device belongs to which customer, when the last data arrived and which version is running come to the fore. The device may be reinstalled, network information may change, or it may remain without internet for a period of time. Delay of remote command and interruption of update should also be predictable behavior of the product.

The solution is to define responsibilities and scenarios before choosing a cloud provider. Embedded software, APIs, databases and management screens must share the same data dictionary. The following steps help establish requirements for the customer's product. VOMRO develops the hardware and software scope of your project; hosting, operation and maintenance responsibilities are clarified separately rather than bundled into an off-the-shelf device-management subscription.

01

1. Separate the device ID, user account and installation record

Device serial number, communication ID and user's account play different roles. A unique record of the manufactured device is created; It is tracked which hardware revision it carries and which software it is programmed with. Initial setup requires a defined flow to assign the device to the correct customer or facility. Knowing the identity of a device should not mean authorization to access it.

Determine what happens when the product changes hands, is serviced, or is restored to factory settings. The old user's access may need to be turned off and the new installation connected to the correct record. It is defined where the information assigned during production will be kept, who will use it, and what data the service team will see. Thus, device management is not left only to a name field on the panel; It becomes a traceable process in the life cycle of the product.

  • Unique device registration and hardware/software version
  • Assignment relationship with customer, facility and user
  • Service, handover and reset scenarios
02

2. Scope initial configuration and access information

Provisioning gives the device the information needed to join its network and service. User-entered Wi-Fi credentials, the device's server identity and the user's account must not be treated as the same secret. Depending on product use, provisioning may involve BLE, a local connection or the production programming step. Recovery and retry behaviour are also defined for interrupted setup.

The access authority given to the device is limited to the resources it needs. Ensuring that a device does not access other customers' data requires server-side authorization control. Renewal or cancellation of access information is evaluated in lost device and service scenarios. Confidential information is not unnecessarily exposed in logs or in the client interface. These design principles are applied according to the project requirements; A single protocol selection does not guarantee security for the entire system.

  • Initial setup and reconfiguration flow
  • Restricted access by device and role
  • Rules for credential renewal, revocation and logging
03

3. Plan the use of MQTT and HTTP based API with the data flow

HTTP API request/response exchanges and MQTT publish/subscribe messaging support different data flows. Both can serve different functions in one product. Measurement frequency, server-to-device commands, connection behaviour and existing software infrastructure are assessed together. MQTT topics or HTTP API routes, data fields and versions are documented. Transport protection such as TLS, server authentication and access authorisation remain distinct design responsibilities.

MQTT delivery levels refer to message transfer. Receiving a message does not mean that the valve has opened or that the setting has been physically applied. The possibility of redelivery and session behavior must be evaluated on the application side. Device time, network reconnection, and lifecycle of server certificates also enter into connectivity tests. The choice is made not only on the ability to send small packages, but on the entire operating scenario of the product.

  • Topic/API dictionary, data schema and versioning
  • Transport protection, authentication and authorization separation
  • Separating message delivery from the outcome of the physical action
04

4. Store offline data with time and quality

If local measurement or control needs to continue when the Internet connection is interrupted, the recording capacity and storage method are determined. Which data has priority, what to do when the buffer is full, and memory write limits are evaluated. The moment the measurement is taken and the moment it reaches the server should be kept separate. Time quality or sequence information is required for recordings where the device time has not yet been verified.

Once the connection is restored, transferring records should not prevent new measurements from running. If the same record is sent again, how the server will distinguish this and where the transmission will continue is designed. The last communication time and the last measurement time are not mixed in the panel. The user should be able to understand this when looking at old data. Data retention time and recording volume are product requirements that affect both device memory and server storage.

  • Buffer size, occupancy and recording priority
  • Measurement time, arrival time and data validity
  • Identifying duplicate records and resuming after an outage
05

5. Monitor acceptance, execution and result of remote command

Commands have identifiers, creation times and, where needed, validity periods. Version information helps prevent an older device from silently misinterpreting an unfamiliar new command. A device can check a command's suitability before accepting it; accepted, rejected or deferred states follow the application's requirements. The physical outcome is reported separately.

Executing an old command after a connection outage is not appropriate for every project. A retransmitted command may also need to avoid triggering a second operation. If local and remote users change the same setting, priorities or version checks are defined. Connectivity, local control and safety responsibilities are clarified together for machine and field control. Showing a successful button action on the dashboard may require more evidence than the server having sent a message.

  • Command ID, version and validity period
  • Received, accepted, and applied statuses
  • Repetition, delayed command and local/remote priority
06

6. Plan OTA updates before selecting the board

OTA is a remote update of the firmware; memory partitions are associated with the bootloader and energy behavior. It is determined where the new software will be kept, what happens when the download is interrupted, and which hardware revision it is compatible with. Signed software verification and secure transport are designed according to the requirements of the project. The signature serves to verify that the software comes from the authorized source; It does not alone prove that it will work without errors.

Appropriate architecture is created when first boot verification and rollback from failed version are required. The availability of rollback does not mean that every old version can be rolled back unconditionally; security version and data compatibility are also evaluated. Espressif OTA and MCUboot documentation provide different implementation examples. Which approach to use depends on the hardware chosen. During the update, scenarios such as power cut and unsuccessful startup are tried in the prototype.

  • Memory, bootloader and hardware compatibility
  • Signature and version verification as per project requirement
  • Tests for interruption, first boot, rollback and recovery
Network and power outage test setup prepared for software update of the connected electronic device
Representative application image.
07

7. Define concrete requirements for fleet visibility and update acceptance

For the management screen, whether the device is online or not may not be enough. Last measurement, last communication, software version, hardware revision and update status are kept in separate areas. The information the installation team, customer, and developer see is determined by their roles. Error logging should aid diagnosis without unnecessarily revealing sensitive data.

We assess pilot-group testing and staged rollout before distributing new software to every device. Success is defined explicitly: completion of the download, or verified operation with the new version. Deferral conditions cover unreliable connectivity, insufficient energy and incompatible hardware. If the data model changes, compatibility between old and new versions is also tested. Operational responsibilities and support procedures are agreed before handover.

  • Separation of version, last contact and update status
  • Pilot group and phased deployment requirements
  • Workflow for incompatibility, deferral and errors
08

8. Include installation and operating information as well as source code in the delivery list

Alongside embedded and server source code, the handover list should include the API/data dictionary, build and installation information, database changes and test scenarios. It documents programming, device identification and update release procedures. Responsibility for access credentials and project keys is assigned; secrets are not placed in public source files. Licence and operating terms for third-party services and libraries are stated separately.

We will sign NDA upon your request before technical sharing on VOMRO. Source codes, design files and technical documents of the project are delivered at the end of the project. In the first meeting, you can share the expectation of the number of devices, data frequency, connection type, need for offline operation and remote command. If there is an existing server or API, the integration conditions are examined. The scope of hosting, backup, updating and maintenance is clarified along with technical development outputs.

  • Device and server source files with interface documentation
  • Installation, identification, update and testing information
  • NDA, technical deliverables and operational responsibilities
States that must be distinguished in a connected product
Information on the screenTechnical meaningRelated information to monitor
Device connectedRecently contactedLast valid measurement time
Command sentThe server started the transferDevice acceptance and physical outcome
Update downloadedThe file has arrived on the deviceValidation, boot and version confirmation

How it works

Turn decisions into a project plan.

Not every project looks the same; however, the measurable requirement, controlled revision, and field verification steps remain unchanged.

  1. 01

    Document the lifecycle

    Determine production, initial installation, usage, service and handover scenarios.

  2. 02

    Define the interface

    Establish a shared dictionary for identity, permissions, data, commands and versions.

  3. 03

    Test interruptions

    Apply scenarios of loss of connection and power, stale data, and failed updates.

  4. 04

    Take delivery of the source files

    Receive the code, designs, installation and operating documents against the technical delivery list.

Frequently asked questions

Before starting the project

The technical scope, deliverables and test plan are clarified together according to the requirements of your project.

Does using MQTT mean the device is secure?

No. MQTT defines messaging behavior. Transport protection, authentication, access authorization, key management and application behavior are separately designed and verified in project conditions.

Can OTA be added later?

It can be added to some designs, but may require changes to memory, bootloader, hardware and recovery approach. It is useful to define the need for remote updates before the board and software architecture are selected.

Does data have to be lost when the internet goes out?

No. Local buffering can be designed with suitable memory and energy resources. Capacity, timestamps, behaviour when full and duplicate handling after reconnection are defined at the outset.

Is VOMRO selling its own cloud product?

This service is customer-specific connected device and software development. The server application scope is determined for the integration or project with your existing infrastructure. Hosting and maintenance responsibilities are further explained; project resources and technical documents are delivered at the end.

Related content

From device to management panel

Server software and device management

 Reliable data from field to system

IoT, communication and automation integration

 We design the behavior of the device

Embedded software and embedded system development

 From idea to a product under your brand

Consumer electronics and end-user product development

All product development services

Your project, your product

Developed confidentially and delivered with source files.

We may work with a confidentiality agreement (NDA) before sharing technical details. At the end of the project, we deliver the source codes, design files and technical documents we have developed to you.

  • NDA before sharing technical information
  • Clear deliverables agreed at the outset
  • Source and technical files at the end of the project
Our confidentiality and delivery process
Let's start with your idea

Let's talk about the product you dream of and the need you want to solve.

Submit a project request +90 534 487 98 02