Perform OTA Update

[TCP/WebSocket <--> InvisOutlet]

Perform an OTA update for InvisOutlet, InvisDeco, or both devices as one ordered full update.

Request

• packetID: The packet ID. This can be any six-digit number with no leading zeros.

• payload:

  • callbackName: 21

  • callbackArgs :

    • 1 : Update target; 1 - InvisOutlet only, 2 - InvisDeco only, 3 - Update all (InvisDeco first, then InvisOutlet)

    • 2 : InvisDeco update method; 0 - Update via Wi-Fi, 1 - Update via InvisOutlet

The update method value is ignored when the target is 1.

callbackArgs	Operation
[1,0]	Update InvisOutlet over Wi-Fi
[2,0]	Update InvisDeco over Wi-Fi
[2,1]	Update InvisDeco through InvisOutlet.
[3,0]	Update all: InvisDeco over Wi-Fi, then InvisOutlet over Wi-Fi
[3,1]	Update all: InvisDeco through InvisOutlet, then InvisOutlet over Wi-Fi.

Use [3,0] for the normal update-all flow. If InvisDeco Wi-Fi is unreliable, or if InvisDeco must be force-updated, use [3,1].

[3,1] always transfers the InvisDeco image via InvisOutlet. The InvisDeco will be updated regardlessly if the firmware version is already up-to-date.

Update all using InvisDeco Wi-Fi

{
    "packetID": 414883,
    "payload": {
        "callbackName": 21,
        "callbackArgs": [3, 0]
    }
}

Update all using InvisDeco via InvisOutlet

{
    "packetID": 414884,
    "payload": {
        "callbackName": 21,
        "callbackArgs": [3, 1]
    }
}

Update-all sequence

For target 3, InvisOutlet treats both device updates as one ordered transaction:

1. InvisDeco starts using the selected update method.

2. When InvisDeco succeeds, InvisOutlet starts its update over Wi-Fi.

3. If InvisDeco is already up-to-date during [3,0], its stage is treated as a successful no-op and InvisOutlet still starts.

4. If InvisDeco fails, the pending InvisOutlet stage is cancelled.

InvisOutlet owns the handoff. A client must not send a second callback 21 request after receiving the successful InvisDeco result.

If InvisOutlet loses power or unexpectedly restarts before the transaction finishes, refresh both firmware versions and issue a new request if required.

Progress and result events are emitted separately for each device. Clients receive InvisDeco events first (callbackArgs[0] = 2), followed by InvisOutlet events (callbackArgs[0] = 1). When an InvisOutlet WWW partition update is included, its events use callbackArgs[0] = 3.

An already-current InvisDeco may complete its [3,0] stage without download-progress events. Wait for the InvisDeco result, then continue listening for InvisOutlet events.

Immediate response

The immediate response confirms whether the request was accepted.

• sn: InvisOutlet serial number.

• packetID: The request packet ID.

• PUBACK:

  • 1 — Request accepted and the first stage will start.

  • 0 — Request rejected or could not initialize. Target 3 is also rejected when InvisDeco is offline, the arguments are invalid, or another OTA transaction is active.

{
    "sn": "0003C44076",
    "packetID": 414883,
    "PUBACK": 1
}

Synchronous stage-start response

• payload.callbackName: 21

• payload.callbackArgs[0]: Device whose OTA stage is starting.

  • 1 — InvisOutlet

  • 2 — InvisDeco

• payload.callbackArgs[1]:

  • 1 — OTA stage can continue

  • 0 — OTA stage failed to initialize

{
    "sn": "0003C44076",
    "packetID": 301551,
    "payload": {
        "callbackName": 21,
        "callbackArgs": [2, 1]
    }
}

For an accepted update-all request, the normal order is:

1. InvisDeco stage-start/progress/result events with device role 2.

2. InvisOutlet stage-start/progress/result events with device role 1.

3. Optional InvisOutlet WWW progress/result events with role 3, when a WWW update is included.

A successful InvisDeco result is an intermediate result, not completion of the update-all operation.

InvisOutlet revB disconnects and reboots while installing OTA firmware. Reconnect the TCP client and continue listening, but do not automatically resend callback 21.

Follow the transaction through OTA Download Progress (Synchronous) and OTA Result Update (Synchronous). Synchronous messages use newly generated packet IDs, not the original request packet ID.