Experiment record
SwitchBot Plug Mini OpenAPI: investigating electrical values that stop updating and repeat for long periods
A public Experiment Log investigating SwitchBot Plug Mini (JP) OpenAPI electrical values that remain unchanged for long periods, including the manufacturer-confirmed layered reporting mechanism and a secondary conclusion that the weight field likely represents instantaneous active power.
Summary
SwitchBot Plug Mini (JP) is a smart plug placed between a household outlet and an appliance. It can switch power on and off and expose electrical status information through the SwitchBot app and OpenAPI.
During this experiment, the Plug Mini was polled through SwitchBot OpenAPI v1.1. The API requests succeeded normally, yet power- and current-related values sometimes remained unchanged for 10–20 minutes or longer and the same values were returned repeatedly.
To investigate the cause, the experiment used short-interval polling, longer log comparisons, independent collector environments, a device reset, Bluetooth and Wi-Fi connectivity changes on the phone, SwitchBot app traffic observation, and escalation to SwitchBot support.
SwitchBot support later reported that Plug Mini uses a load-dependent layered reporting mechanism. For the approximately 110 W load in this case, support described a 30 W change threshold as the relevant reporting condition; in the threshold table supplied by the manufacturer, the ≤300 W band is listed as requiring a change greater than 30 W.
The investigation also reached a secondary conclusion: analysis of the OpenAPI weight field was consistent with instantaneous active power in watts.
Background
The original goal was to collect long-running household electricity data by polling a SwitchBot Plug Mini through OpenAPI.
The main returned fields involved in the investigation were:
| OpenAPI field | Interpretation used in this experiment |
|---|---|
voltage | Voltage |
electricCurrent | Current (returned in mA) |
weight | A value believed to represent power |
electricityOfDay | Likely daily usage time [min] |
The logs contained intervals in which these values remained exactly identical across many successful API requests.
For example, even with one-minute polling, returned values could remain unchanged for close to 20 minutes. That raised the possibility that a one-minute API retrieval interval was not equivalent to a one-minute device reporting interval.
The investigation therefore focused on the conditions under which new OpenAPI values are actually reported.
Methods
SwitchBot Plug Mini
The tested device was a Japanese-market SwitchBot Plug Mini. The model number on the experiment-used unit was W2001401, confirmed from the device label.
It can be controlled through the SwitchBot app and cloud service, and its device status can also be retrieved through OpenAPI.
SwitchBot OpenAPI
Data acquisition used SwitchBot OpenAPI v1.1.
The problem was not failed API requests. The endpoint returned successful responses while electrical values inside those responses could remain unchanged for extended periods.
Independent collection paths
The same Plug Mini was queried through two separate environments:
- a Python logger
- a Google Apps Script logger
Comparing independent environments helped test whether the behavior could be explained by one logger implementation or runtime alone.
Experiment Log
2026-08-12 — Five-second polling
The first test used short polling to see how frequently values changed under normal conditions.
A five-second run collected 151 samples over about 12 minutes 32 seconds.
During this period, weight and electricCurrent did change. electricityOfDay also increased by roughly one unit per minute. The device was therefore not simply returning one permanently fixed state.
2026-08-12 — One-second polling
The polling interval was then reduced to one second.
A total of 223 samples were collected over about 3 minutes 43 seconds.
Polling once per second did not produce a new value on every request. Repeated identical values were common, while changes were seen mainly on a roughly two- to three-second timescale.
This suggested that OpenAPI request frequency and Plug Mini reporting frequency might be separate mechanisms.
2026-08-12 — A roughly 20-minute unchanged interval
Longer logs revealed behavior clearly different from the short repeated values above.
voltage, electricCurrent, weight, and electricityOfDay could remain unchanged for extended periods.
One representative interval lasted about 20 minutes before multiple fields changed to newer values.
This showed that higher polling frequency alone does not guarantee correspondingly fresh measurements.
2026-08-12 — Python and Google Apps Script comparison
A Python logger polling once per minute was compared with an independent Google Apps Script logger polling once every five minutes.
Both environments returned the same stale values during the same interval.
That made explanations limited to a cache or defect in only one collector environment less plausible.
2026-08-12 — Opening the SwitchBot app detail screen
While OpenAPI values were stale, the target Plug Mini detail screen was opened in the SwitchBot mobile app.
Multiple times, the next OpenAPI values refreshed after the detail screen had been opened. In one recorded example, the usage time shown in the app matched the refreshed electricityOfDay value.
At that point, one possibility was that the detail screen caused some form of state retrieval or synchronization between the app, cloud service, and device.
The observation alone did not reveal what communication actually occurred.
2026-08-12 — Bluetooth disabled
The same test was repeated with Bluetooth disabled on the phone.
The OpenAPI refresh after opening the detail screen was still observed.
This made a simple Bluetooth-only explanation insufficient.
2026-08-12 — Wi-Fi disabled, cellular data only
The phone’s Wi-Fi was then disabled and the SwitchBot app was used over cellular data only.
The same app-detail-screen-associated OpenAPI refresh was observed.
This indicates that being on the same local network as the Plug Mini was not required for the observed effect.
The specific synchronization mechanism, if any, was still not identified.
2026-08-12 — Inspecting app traffic with mitmproxy
Traffic generated while opening the app detail screen was observed through mitmproxy.
No clear new HTTP refresh request corresponding to the app’s connecting state was identified. At the same time, app metadata contained device-specific pub/sub-like topic information.
This observation did not identify the concrete messaging protocol or the contents of any refresh command that the detail screen might send.
2026-08-13 — Plug Mini reset
The Plug Mini was reset to test whether the long unchanged intervals were caused by a temporary device fault.
The stale behavior still occurred afterward.
A simple transient device fault therefore became a less satisfactory explanation.
2026-08-13 — Contacting SwitchBot support
Because the behavior could not be explained from the client side alone, SwitchBot support was contacted.
The report included the long unchanged OpenAPI values, agreement between independent collectors, and the fact that a device reset did not eliminate the behavior.
2026-08-16 — Development-team escalation
SwitchBot support reported that the case had been escalated to the development team.
No detailed explanation was available at that stage.
2026-08-19 — Manufacturer response on layered reporting
SwitchBot support later provided the development-team result: Plug Mini uses a layered reporting mechanism in which a new report depends on the magnitude of load change.
| Approximate load band | Change required for a new report |
|---|---|
| ≤ 10 W | > 4 W |
| ≤ 100 W | > 10 W |
| ≤ 300 W | > 30 W |
| ≤ 500 W | > 50 W |
| ≤ 700 W | > 70 W |
| ≤ 1000 W | > 100 W |
| ≤ 1500 W | > 100 W |
The experiment load was about 110 W. Support described a 30 W change threshold as the reporting condition for this case, while the supplied table lists the ≤300 W band as requiring a change greater than 30 W.
This matched the earlier working idea that the device might use a change-of-value style reporting mechanism rather than continuously publishing every measurement change.
Sensitivity change request
Support also stated that, for the investigated device, the 100–300 W threshold could be changed from 30 W to 10 W through a backend command.
A request was made to change the threshold from 30 W to 10 W.
However, the later correspondence did not provide a response or measurement confirming that the change had actually been applied.
2026-08-19 — Follow-up questions
Two additional questions were sent to the manufacturer:
- When a power change crosses the reporting threshold, are
voltage,electricCurrent, andelectricityOfDaynecessarily refreshed at the same time? - Does opening the SwitchBot app detail screen trigger a state retrieval or synchronization process separate from normal layered reporting?
2026-08-21 — Follow-up still under investigation
SwitchBot support replied that the additional questions were being checked with the development team.
No substantive specification answer to those two questions had been received at that point.
Conclusion
Main conclusion — layered reporting mechanism
The investigated Plug Mini uses a load-dependent reporting mechanism in which a new report is sent only after a sufficiently large load change.
For the approximately 110 W condition examined here, support described a 30 W change threshold as the relevant reporting condition; the supplied threshold table lists the ≤300 W band as requiring a change greater than 30 W.
Direct observations during the experiment included repeated values even with one-second polling, roughly 20-minute unchanged multi-field intervals, agreement between Python and Google Apps Script collectors, and app-detail-screen-associated OpenAPI refreshes under multiple phone connectivity conditions.
Secondary conclusion — likely meaning of the weight field
While investigating the stale-value behavior, the experiment also provided useful evidence about what the OpenAPI weight field represents.
For the 223 samples from the one-second run, the retained analysis calculated:
weight [W] / (voltage [V] × electricCurrent [A])
The reported mean was about 0.893 and the median about 0.945. Because OpenAPI returns electricCurrent in mA, the current values were converted to A before this calculation.
If voltage represents RMS voltage, electricCurrent represents RMS current, and weight represents active power, this ratio corresponds to AC power factor. The observed values are physically plausible for a household AC load.
The data therefore support the interpretation that weight likely represents instantaneous active power in watts.
No manufacturer specification directly confirming the formal meaning of the weight field was found in the material available for this experiment.
Evidence summary
The Evidence States for the information obtained in this Experiment are as follows.
| Recorded content | Evidence State |
|---|---|
| Load-dependent layered reporting mechanism; for the approximately 110 W case, support described a 30 W change threshold and the supplied ≤300 W band is listed as >30 W | VERIFIED |
| Repeated one-second-poll values, roughly 20-minute unchanged intervals, agreement between independent collectors, and app-associated refresh observations | OBSERVED |
Interpretation that weight likely represents instantaneous active power [W] | INFERRED |
See Evidence State for the shared definitions.
Unresolved questions
As of 2026-08-22, the retained Evidence does not establish:
- whether a threshold-triggered power report always refreshes the other electrical fields at the same time;
- whether opening the app detail screen triggers a specific state-synchronization operation;
- which protocol or message path would carry that synchronization if it exists;
- whether the same thresholds apply identically to every Plug Mini (JP) hardware and firmware revision;
- whether the requested 30 W to 10 W threshold change was actually applied.
Resolving these points requires additional manufacturer specification or direct observation of the relevant reporting/synchronization behavior.
Operational implications
The timestamp at which OpenAPI is queried and the time at which the Plug Mini generates or reports a new value should be treated as different concepts.
Polling once per minute does not mean the Plug Mini produced a fresh measurement report once per minute.
For long-running electricity datasets, retrieval time, duration of identical snapshots, transition time to a new value, and any evidence about the device’s true update time should be modeled separately where possible.
Treating API polling frequency as sensor measurement frequency can otherwise make the dataset appear to have finer temporal resolution than the device reporting behavior actually supports.
Experiment data
Sample counts, run durations, and representative statistical values from the short-poll experiments remain in the experiment notes.
However, the complete raw data files generated by the original logger are not present in the records currently available.
The full original time series therefore cannot be reconstructed from the summary and representative values on this page alone.
This limits how deeply the experiment can be reanalyzed after the fact.
Reproduction resources
The equipment and experimental environment used in this experiment, together with current purchase information kept separate from the Experiment’s Evidence and Conclusion, are documented on SwitchBot Plug Mini OpenAPI — equipment, experimental environment, and purchase information.
Machine-readable experiment record
A machine-readable canonical record of this Experiment is published as JSON.