This archive covers main firmware from 0.1.0 through 0.6.34, as reviewed on 2 September 2026. Explore the technical evidence for changes to energy measurement, remote relay control, SNMP, REST API, local and cloud OTA, HTTPS, email alarms and BLE Smart Sensor.
The records were compiled by comparing packaged firmware images, their embedded version metadata, release notes, build outputs, API and interface text, and the available source structure. Because no Git commit history was available in the project, only versions supported by evidence appear as individual entries; no changes were assigned to skipped version numbers. “Distribution package” does not mean that a package was automatically deployed to every device in the field.
This page is not an announcement of the latest stable release. Later mobile setup documentation requires main firmware 0.6.38 or newer for password-protected Bluetooth setup, and records verification of 0.6.40 on a test device. These records do not establish deployment to all customers or designation as a stable release.
Distribution package: a package candidate with verified version metadata.
Internal development: an intermediate version preserved only as a build artefact.
Sensor firmware: the signed BLE Smart Sensor package series.
Main device and sensor firmware history
Choose a firmware version to see its changes.
Select a verified firmware version on the left to open its technical changes, user impact and evidence level in the panel on the right.
Archived source + package
FW 0.6.34
Cold-start fix for the Smart Sensor alarm list
The firmware 0.6.34 entry in this archive describes correct management of an accepted sensor’s alarm settings even when BLE sensor data has not yet arrived or has temporarily become stale.
What changed?
The accepted sensor summary loads from device state without waiting for a live scan result.
Temperature, humidity and CO₂ alarm fields remain editable while the sensor association is retained.
Unassociated old sensor records are cleared, while the accepted sensor is shown as offline.
Why does it matter?
Prevents the sensor from appearing to disappear, and environmental alarm controls from being disabled unnecessarily, after a restart or an infrequent BLE advertising window.
BLE Smart Sensoralarm UIcold startoffline state
Verification: The project version reviewed for this archive, package metadata and sensor/alarm request-liveness tests agree.
Distribution package
FW 0.6.33
Local HTTPS request liveness and session management
Addressed conditions that could leave requests stuck in a queue after extended use of the local web panel, navigation between pages or session expiry.
What changed?
Unauthorised responses use one secure session-ending flow.
Timers, request queues and active requests are cleared when a page closes.
Request timeouts and browser back-navigation scenarios are handled explicitly.
Why does it matter?
Reduces the likelihood of the HTTPS panel remaining in a loading state and reliably returns users to sign-in when their session expires.
HTTPSsessionrequest queue401 handling
Verification: Package name, firmware metadata and local request-liveness tests.
Distribution package
FW 0.6.32
BLE OTA transport safeguards
Improved data framing, transmission pacing and retry behaviour for signed firmware transferred to a BLE sensor through Smart Kablo.
What changed?
Smaller SMP frames and controlled packet intervals are used.
Retry counts are bounded to fit the sensor’s connection window.
Avoids unnecessary retransmission of a critical TEST operation or first chunk when its response is uncertain.
Why does it matter?
Reduces repeated transfer loops at the same point on weak or brief BLE connections and preserves the sensor’s safe boot and rollback process.
BLE OTAMCUmgr SMPpacingretryMCUboot TEST
Verification: Package metadata, transport-recovery tests and the OTA flow constants in the available source.
Distribution package
FW 0.6.31
BLE OTA worker lifecycle fix
Replaced a thread recreated for every firmware chunk with one OTA worker whose lifecycle is controlled throughout the transfer.
What changed?
BLE upload and SMP operations wake one shared worker.
The worker suspends when its work is complete, with cleanup handled in one place.
Fixes early transfer interruptions caused by delayed release of stack memory.
Why does it matter?
Reduces memory pressure, particularly during the first few percent of an OTA update, and keeps resource use predictable throughout a long transfer.
BLE OTA workermemorytask lifecycle
Verification: Package name, worker symbols in the binary and worker-lifecycle tests.
Distribution package
FW 0.6.30
Web-interface performance and asynchronous OTA
Reduced unnecessary background requests from the local management panel and moved BLE sensor OTA chunks into a workflow that does not block web requests for long periods.
What changed?
Polling stops on hidden pages, and requests from closed pages are cancelled.
Settings tabs load when needed, and local API requests run in a controlled sequence.
2 KiB OTA chunks are handed to the worker, with transfer continuing when the next chunk is ready.
Why does it matter?
Keeps dashboard and settings screens responsive during firmware updates and prevents simultaneous requests from exhausting device resources.
UI performancelazy loadingpollingasync OTA
Verification: Package name, interface-performance tests and chunked-OTA tests.
Distribution package
FW 0.6.29
Resumable chunked BLE OTA
Changed the update path from browser to Smart Kablo to BLE sensor into an ordered chunk model that can resume from a verified offset.
What changed?
The firmware file is split into sequential 2,048-byte chunks.
Total size and chunk offset are validated.
After a disconnection, transfer can resume from the last acknowledged position; reselecting the file triggers an integrity check.
Why does it matter?
For low-power sensors with short advertising windows, the verified portion of a transfer is retained instead of sending the entire file again.
chunked uploadresumeoffsetBLE OTA
Verification: Package metadata and the chunked-upload/offset flow in the binary.
Distribution package
FW 0.6.28
TP/v5 sensor data and TLS resource coordination
BLE Smart Sensor battery data moved from raw voltage to an estimated remaining-capacity percentage and operating-hours model; resource coordination was added for concurrent TLS operations.
What changed?
TP/v5 carries estimated remaining battery capacity in the field named SOH, together with sensor operating hours.
The old mV-based battery alarm is migrated to a percentage-based 0–100 model.
Limits simultaneous memory pressure from cloud, email and secure local connections.
Why does it matter?
Makes battery status easier to interpret and reduces conflicts between different TLS tasks during OTA and HTTPS activity.
TP/v5battery SOHoperating hoursTLS gate
Verification: Protocol/migration text in the packaged binary and the available sensor telemetry definition.
Internal development artefact
FW 0.6.21
Persistent sensor intervals and OTA/SMTP coordination
This intermediate development image shows work on retaining sensor measurement-interval requests across restarts and protecting network/TLS resources during OTA.
Verified developments
A pending measurement-interval request can be restored to the queue from persistent storage.
If the accepted sensor changes, its previous pending request is cancelled.
SMTP/TLS work is deferred during OTA to reduce resource conflicts.
Status note
Preserved only as an internal build, not a separate distribution package. Its functions were refined in later packages.
persistent intervalOTASMTPTLS coordination
Verification: Internal binary text and build scope.
Internal development artefact
FW 0.6.16
HTTPS protection for diagnostic data
This internal development version aimed to make diagnostic outputs for fault analysis available only through a secure local connection and after validity checks.
Verified developments
Diagnostic downloads require HTTPS.
Invalid or missing fault images are rejected.
Debug output suitable for service analysis is prepared.
Status note
This image serves internal technical diagnosis and was not packaged in the distribution directory; it should not be treated as an end-user feature.
diagnosticsHTTPS onlyfault analysis
Verification: HTTPS and fault-validation text in the preserved internal firmware image.
Internal development artefact
FW 0.6.15
BLE OTA reconnection and step-level diagnostics
An intermediate version focused on recovering from the last known offset after a sensor disconnects during an update, and identifying the OTA step where a failure occurs.
Verified developments
Added indications of resuming from the saved transfer position after a disconnection.
Improved diagnostics to identify the failed OTA step instead of reporting only a generic error.
Addressed BLE connection parameters and longer pause/recovery scenarios.
Status note
Preserved only as an internal artefact, this work is a technical precursor to the packaged, resumable OTA pipeline in 0.6.29–0.6.32.
BLE reconnectresume offsetOTA diagnostics
Verification: Connection-recovery, PHY and failure-step text in the preserved internal binary.
Internal development artefact
FW 0.6.4
BLE sensor maintenance and signed OTA foundations
The first verified intermediate image for managing an accepted BLE sensor’s measurement interval and streaming its firmware without holding the entire file in memory.
Verified developments
Sensor measurement intervals of 1–60 minutes, with read-back verification from the sensor.
Firmware streaming from the browser through Smart Kablo to the sensor.
MCUboot header, signature, hash and key checks; foundations for TEST boot, health confirmation and rollback.
Status note
This is an internal build. The secure BLE OTA experience was progressively strengthened in later intermediate versions and in packages after 0.6.28.
signed BLE OTAMCUbootsensor intervalstreaming
Verification: Internal binary API text, signature checks and build scope.
Distribution package
FW 0.6.3
Cloud integration of Smart Sensor telemetry and alarm rules
Environmental measurements from the accepted BLE sensor were combined with cloud telemetry, and remotely supplied alarm-rule updates began to be validated and applied.
What changed?
Temperature, humidity, CO₂ and air-quality data were added to the cloud data stream.
Alarm rules can be updated through the cloud command channel.
Invalid alarm payloads are rejected while preserving the existing configuration.
Why does it matter?
Establishes the basis for monitoring energy telemetry and environmental data under the same device association, with centrally managed alarm thresholds.
sensor telemetrycloud commandsalarm validation
Verification: Sensor, cloud and alarm-update markers in the distribution binary.
Distribution package
FW 0.6.2
Sensor cards, CO₂ display and battery alarm
Expanded the Smart Sensor screen with cards that make environmental metrics, data freshness and the battery-voltage model used at the time clearer.
What changed?
Offline or stale sensor data is shown as a separate state.
Environmental measurements, including CO₂, are detailed on sensor cards.
Added battery voltage/status and an mV-based alarm threshold.
Why does it matter?
Helps users distinguish a recent reading from the last known value. The mV-based battery approach later moved to an estimated remaining-capacity model in the SOH field in firmware 0.6.28.
CO₂battery voltagestale datasensor cards
Verification: Interface/text differences between the 0.6.1 and 0.6.2 distribution binaries.
Distribution package
FW 0.6.1
BLE Smart Sensor discovery and management
Added a flow for scanning nearby BLE sensors, accepting one sensor, monitoring it and removing its association when required.
What changed?
APIs for BLE sensor scanning, listing, acceptance and removal.
New alarm types for temperature, humidity and air quality.
Sensor-polling behaviour that follows page visibility.
Why does it matter?
The first packaged main-device release of the Smart Sensor integration that adds environmental conditions to energy measurement.
BLESmart Sensortemperaturehumidityair quality
Verification: Smart Sensor API and alarm symbols in the distribution binary.
Distribution package
FW 0.6.0
Local HTTPS and email-alarm foundations
The 0.6 series added HTTPS for the local management panel using a certificate generated on the device, together with an SMTP notification engine for measurement thresholds.
What changed?
Local HTTPS, activation confirmation and an HTTP recovery flow if activation fails.
SMTP with TLS/STARTTLS, multiple recipients and a test notification.
Alarm rules for current, voltage, power, frequency, RSSI and relay state.
Persistent data migrations for alarms, the event archive, consumption history and relay state.
Why does it matter?
Offers encryption for local management traffic and can email notifications when energy or connection limits are exceeded, without requiring someone to watch the panel.
local HTTPSSMTPemail alertsTLSNVS migration
Verification: The packaged binary and the available certificate, SMTP and alarm-service source structure.
Distribution package
FW 0.5.34
Faster cloud command feedback and synchronised relay countdown
Separated cloud telemetry from frequent command checks and synchronised the automatic power-restoration countdown with the cloud interface after a timed power-off.
What changed?
Telemetry and command checks run in separate cycles of approximately 60 seconds and 5 seconds respectively.
Relay and OTA command results are reported without waiting for the next telemetry upload.
Total automatic-restoration duration is sent alongside the remaining time.
Why does it matter?
Makes remote on/off command results visible sooner and keeps the Smart Cloud countdown aligned with the actual remaining time on the device.
cloud commandsrelay timercommand acktelemetry
Verification: The total-countdown field in the packaged binary and source descriptions of firmware operating intervals.
Distribution package
FW 0.5.33
Separate cloud telemetry and device command channels
Moved energy-data uploads and remote-command polling to separate endpoints and independent error paths.
What changed?
Telemetry uploads and device-command polling use separate address structures.
Command-poll errors are logged independently of telemetry failures.
Responsibilities are separated more clearly within the cloud integration.
Why does it matter?
Makes it easier to identify the failing cloud flow after a command-poll error without confusing it with the state of energy telemetry.
cloud telemetrydevice commandsendpoint separation
Verification: Endpoint and error-text differences between the 0.5.32 and 0.5.33 packaged binaries.
Distribution package
FW 0.5.32
Smart Cloud device-claim experience
As the comprehensive local-management platform accumulated during the 0.5 series was packaged, the interface made the claim-code flow linking a device to a user account more prominent.
What changed?
A flow for loading ownership information and securely copying the code.
A device-pairing link leading to the mobile app.
The dashboard, consumption history, relay, event log, REST API and expanded SNMP foundations are verified together in this package.
Why does it matter?
Makes adding the installed physical device to a Smart Cloud account clearer and connects local management with remote management.
device claimSmart Cloudmobile deep-linkREST API
Verification: Device-claim API, copy and mobile-link text in the distribution binary.
Internal development artefact
FW 0.5.31
Cumulative checkpoint in the transition to the Smart Kablo platform
Individual firmware packages between 0.2.14 and this internal image were not preserved, so an exact intermediate introduction version cannot be assigned to each feature. Version 0.5.31 is the first comprehensive checkpoint where the new Smart Kablo platform can be verified together.
Features verified together in this image
Dashboard, consumption, settings, event-log and device-identity pages.
Remote relay control, timed power-off and power restoration.
Daily/monthly consumption history, local REST API and an expanded SNMP data tree.
Cloud identity/claiming, captive Wi-Fi setup and the mobile BLE service.
Status note
This is an internal build. Read the features as “verified together in 0.5.31”, not “introduced in 0.5.31”.
Verification: Page, API, MIB and device-identity text in the preserved internal binary.
Archive gap: No separate package images were found for 0.3.x, 0.4.x or 0.5.0–0.5.30, so no definite changes are assigned to those version numbers.
Distribution package
FW 0.2.14
User-configurable Wi-Fi and setup access point
The device’s wireless network could now be changed from Settings and saved in persistent memory.
What changed?
The Wi-Fi network name and password are updated through the panel and stored in NVS.
If connection fails, the device opens a setup access point after a short wait.
The saved network is retried regularly; the setup network closes after connection succeeds.
Submitting an empty password for the same network preserves the existing password.
Why does it matter?
Allows a move to another 2.4 GHz Wi-Fi network without rebuilding firmware and keeps the device available for setup when network details are wrong.
Wi‑Fi setupcaptive APNVSreconnect
Verification: Release notes and hardware-verification record preserved with the package.
Distribution package
FW 0.2.11
Measurement conversion and calibration correction
Reworked conversion of raw readings from the energy-measurement system into RMS voltage/current and active and apparent power.
What changed?
Raw-reading conversion moved to the verified measurement approach.
A threshold was applied to suppress low-current noise.
The voltage scale was calibrated, making apparent- and active-power calculations consistent.
Why does it matter?
Ensures that electrical readings in the dashboard, SNMP and cloud telemetry are produced from the same conversion model.
energy meteringRMScalibrationactive powerapparent power
Verification: Conversion, calibration and power formulas in the package release notes.
Distribution package
FW 0.2.10
Controlled expansion of the SNMP MIB
The read-only SNMP tree became a clearer 14-field data model covering network information and essential energy metrics.
What changed?
Network name, subnet, gateway and DNS information.
RMS voltage/current, active and apparent power, power factor, frequency and RSSI.
Uptime in standard TimeTicks format and read-only relay state.
A MIB document matching the firmware data tree.
Why does it matter?
Provides a basis for Zabbix, PRTG, LibreNMS and similar SNMP monitoring systems to read network and energy metrics from one device tree.
SNMP v1/v2cMIBTimeTicksnetwork metrics
Verification: Package release notes and the accompanying MIB mapping.
Distribution package
FW 0.2.9
SNMP startup recovery and persistent web sessions
Prevented SNMP from remaining permanently disabled if network resources were not ready at startup, and moved the web password and time-limited sessions into persistent configuration.
What changed?
The SNMP socket is allocated before the web service and retried on failure.
SNMP v1/v2c GET support and cloud/SNMP sections in Settings.
A configurable web password and a time-limited session model stored in NVS that survives restarts.
Why does it matter?
Improves the likelihood that monitoring resumes after a device restart and makes web-interface sessions controlled and manageable.
SNMP socketlogin sessionpassword settingsNVS
Verification: Descriptions of SNMP retry behaviour and session persistence in the package release notes.
Distribution package
FW 0.2.8
Simpler local management with a light interface
A more readable light interface replaced the original dark theme; raw and repetitive sections with little everyday value were removed from the dashboard.
What changed?
Sign-in and dashboard screens adopted a modern light visual style.
Removed duplicate average/instantaneous tables, status flags and raw diagnostic records.
Retained core information such as voltage, current, power, frequency, RSSI and service switches.
Why does it matter?
Makes the energy-monitoring screen quicker to scan and clearer on smaller screens without losing the relevant technical detail.
dashboard UIlight themeinformation architecture
Verification: Old/new interface scope described in the package release notes.
Distribution package
FW 0.2.7
Live Wi-Fi RSSI indicator
Added an RSSI card to the local dashboard showing wireless signal level as a live dBm reading and an easy-to-read quality category.
What changed?
The instantaneous RSSI value is displayed numerically.
Signal strength is explained through understandable quality categories.
Earlier network/socket stability fixes are retained.
Why does it matter?
Helps assess from the panel whether a cloud or SNMP communication problem is related to weak Wi-Fi signal.
Wi‑Fi RSSIdBmsignal quality
Verification: Package release notes; historical test-network details are omitted for security.
Distribution package
FW 0.2.6
Socket exhaustion and network resilience fixes
Adjusted polling frequency, timeouts and retries to prevent dashboard, local HTTP and cloud HTTPS traffic from exhausting the same limited network resources.
What changed?
The dashboard uses one non-overlapping request cycle of approximately 3 seconds.
HTTP client count and send/receive timeouts are bounded.
Cloud connections use a short connection timeout and progressive backoff.
Removed fixed channel/BSSID locking and expanded 2.4 GHz scanning coverage.
Why does it matter?
Reduces cloud or SNMP interruptions caused by resource shortages while the local panel is open, and helps a lost Wi-Fi connection recover through another access point.
socket limitstimeoutscloud backoffWi‑Fi scan
Verification: Polling, socket, timeout and backoff values in the package release notes.
Distribution package
FW 0.2.5
Wi-Fi RF access performance
Used the permitted high wireless output power and extended passive scanning to find the strongest access point.
What changed?
Wi-Fi transmit power was raised to 20 dBm.
Access points found through a longer passive scan are compared.
Retained selection of the strongest candidate and disabled power saving.
Why does it matter?
Aims to improve connection margin in borderline-signal installations and select the stronger of several access points advertising the same network name.
Wi‑Fi TX20 dBmpassive scanstrongest AP
Verification: RF power and scan settings in the package release notes.
Distribution package
FW 0.2.4
Wi-Fi access-point selection and reconnection
Enabled selection of a strong candidate among access points advertising the same network name, with a new scan after disconnection.
What changed?
2.4 GHz network scanning and selection of the strongest access point.
A new scan and connection attempt after disconnection.
Wi-Fi power saving was disabled to reduce communication latency.
Energy measurement, local/cloud OTA and SNMP remain in the same package.
Why does it matter?
Reduces the tendency to remain connected to the first weak access point found in mesh or multi-access-point environments.
2.4 GHz Wi‑FiBSSID selectionreconnectOTA
Verification: Detailed release notes preserved with the package.
Distribution package
FW 0.2.0
Introduction of local web management and SNMP
Added an authenticated local web interface and a read-only SNMP service for network-monitoring systems to the original firmware core.
What changed?
A browser-based local management panel and sign-in screen.
Basic device configuration through service switches.
A read-only vendor SNMP v2c data tree over UDP/161.
The 2.4 GHz Wi-Fi requirement was stated in the release notes.
Why does it matter?
The first step from a measurement core communicating only with the cloud to a locally manageable network device supplying data to standard monitoring tools.
local web UIloginSNMP v2c2.4 GHz
Verification: Package release notes and binary-text differences between 0.1.0 and 0.2.0.
First distribution package
FW 0.1.0
First preserved Smart Kablo firmware core
The first Smart Kablo firmware image verifiable in the archive, containing the foundations of energy measurement, Wi-Fi, cloud telemetry and OTA updates.
Verified foundations
Electrical measurement foundations for voltage, current and power.
Persistent device identity and the cloud telemetry connection.
Local OTA upload and the core for cloud-triggered OTA checks.
The web sign-in and SNMP text found in 0.2.0 are not yet present in this image.
Why does it matter?
The earliest verified software foundation for the dashboard, REST API, SNMP, relay control, HTTPS and Smart Sensor layers that followed.
energy meteringcloud telemetrylocal OTAcloud OTA
Verification: Firmware-image metadata, binary text and the package checksum record. Scope is kept cautious because detailed release notes are unavailable.
BLE Smart Sensor firmware
FW 1.0.0+1 → +19
Signed low-power BLE sensor firmware series
Nineteen signed Smart Sensor packages, +1 through +19, have been preserved. The sensor sends temperature, humidity, CO₂, air quality and estimated remaining battery capacity to Smart Kablo. Every package contains an OTA BIN, signed HEX, factory HEX and manifest.
Sensor software covered by this archive
Transfer of temperature, humidity, CO₂ and air-quality measurements to Smart Kablo.
Low-power periodic measurements and short BLE connection/maintenance windows.
Signed OTA, test boot, health confirmation and rollback to the previous version on failure.
Estimated remaining battery capacity percentage, operating hours and measurement-interval information.
Scope note
The packages are verified, but records do not establish that every package was deployed to all sensors in the field. Small binary differences without source history have not been assigned definite feature names.
Sensor firmware
Change supported by evidence
Evidence level
1.0.0+1
First preserved signed image; TP/v4 measurements, TD/v1 diagnostics, interval and environmental-alarm characteristics.
Binary + manifest
1.0.0+2
Executable content is identical to +1; the version header and signature were renewed.
Payload comparison
1.0.0+3
A new marker indicating OTA/watchdog protection and significant functional-payload growth.
Binary difference
1.0.0+4 → +6
Functional change in +4; a small configuration difference in +5; executable content in +6 is identical to +5. Complete feature notes were not preserved.
Payload comparison
1.0.0+7 → +10
A maintenance/connectable-window packet was added in +7. Version +8 has the same executable content as +7, and +10 matches +9.
Binary packet markers
1.0.0+11 → +13
Functional-payload change in +11; +12 and +13 are re-signed/re-versioned packages of the same executable content.
Payload comparison
1.0.0+14 → +16
A different payload in +14 and substantial expansion in +15; executable content in +16 is identical to +15. This period is the integration line in which the secure OTA health-confirmation flow matured.
Binary + main-firmware integration
1.0.0+17
Transition to TP/v5: estimated remaining-capacity percentage in the SOH field replaces battery voltage, with a persistent battery-lifetime record and operating-hours model.
Binary + available source
1.0.0+18
Executable content is identical to +17; the version/signature was renewed.
Payload comparison
1.0.0+19
Final sensor version in this archive; a small functional-payload difference exists, but no more specific fix is claimed because a dedicated correction note was not preserved.
VERSION + binary + manifest
temperaturehumidityCO₂estimated capacitysigned OTA
Verification: Nineteen package manifests, signed images, executable-payload comparisons and the available Smart Sensor source documentation.