Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Firmware Update Methods
THiNX Firmware update can be currently initiated only using HTTP/S transport on device checkin. However there is a feature in progress, that would allow providing new firmware update immediately using MQTTT transport.
OTT request cannot be initiated using MQTT, however may be initiated from the device-library-side, when MQTT reports new firmware version availability. The device can then initiate OTT request and will retrieve a token using HTTP/S transport.
API endpoint for accessing the firmware update is
/device/firmware but the
FIRMWARE_UPDATE message will be send as a response instead of
OK on device-checkin in cases, where the device has new firmware available on the server-side.
Firmware update will be commenced immediately only, if the
THINX_AUTO_UPDATE environment variable in the device firmware is changed from default value
false to true.
In case the auto-update is disabled by default, device owner will receive retained MQTT message forwarded through websocket upon his login to the administration UI (RTM).
For development and service purposes, there's also a Forced Update available. It will be commenced in case the request body contains a
Different methods for performing the firmware update are available:
Device must send HTTPS POST request to the API endpoint (
/device/firmware) in order to download the firmware binary immediately.
This method may deprecate in favour of optinally multi-file uploads using OTT (because OTT can store all incoming request params, AND single-file/simple-download can be initiated using a http body key).
Device sends HTTP(S) POST request to the API endpoint (
/device/) while having
"use":"ott" as a part of the request. The request is authenticated by API Key only and will support plain HTTP transfers in the future, in order to support legacy low-performance devices without TLS and/or security gateway.
Higher level of security (TLS) can be enforced by starting THiNX-Connect on your local network. THiNX-Connect is a HTTP-to-HTTPS gateway that serves as a secure tunnel between your HTTP-only devices and the THiNX cloud.
useattribute is not set, Simple transfer will be falled back to.
Device will retrieve only the OTT (one-time-token) and can asynchronously use it to retrieve data using simple HTTPS GET (request is not authenticated) anytime in next 24 hours or in 1 hour from first attempt to use the token.
OTT request is currently supported only by single-file/whole-firmware updates (Arduino, Platformio).
On the API side, while request is stored to Redis saved as "ott:" to the Redis store.
Request is the retrieved using the OTT value when the
/device/firmware API is called using HTTP GET method instead of POST.
Device sends HTTPS POST request to the API endpoint (
/device/firmware) and will retrieve JSON object with multiple files immediately.
All the update requests should end-up in device/updateFromPath method, that requires two parameters:
FILE (or basename) that will be uploaded to device after validation (file must be at least readable)
OTT, optionally – identifier of the OTT token that will to be invalidated on successful upload
The OTT request may be validated.
RTM – Remote Things Management; administrative UI part of the THiNX platform
OTT – One-Time-Token; part of or whole URL that can be used only once to fetch firmware update for given device.
TLS - Transport Layer Security. Standard set of features that prevents attacker to inspect or modify network traffic (e.g. steal your password from pre-build firmware on update).