Summary
The Cloud HTTP API (/api/set) allows setting the amp parameter to a value
higher than the device's own ama (Absolute Max Ampere) limit, instead of
rejecting the request or clamping it to ama.
Expected behavior
According to the API documentation, ama defines "the maximum value for
ampere setting" (e.g. "can not be set to more than 20A in the app"). I
expected the Cloud API to enforce this limit server-side or on the charger
firmware itself, independent of the official app's UI restriction.
Actual behavior
On my charger, ama is set to 16 (matches the physical 16A installation).
I sent a request via /api/set?token=...&=18 through the Cloud API.
The request was accepted (HTTP 202), and a subsequent /api/status query
showed amp = 18A
Why this matters
ama appears to only be enforced as a UI restriction in the official app,
not as a hard limit in the charger firmware or Cloud API. Any third-party
integration or custom app relying on ama as a safety boundary could
therefore set a charging current that exceeds the electrical installation's
rating, which is a potential safety issue (overload of wiring/breaker) if
the installation isn't otherwise protected independently.
Steps to reproduce
- Query
/api/status?filter=ama to confirm the charger's configured
ama value.
- Send
/api/set?token=...&=<value greater than ama>.
- Query
/api/status?filter=amp again and observe that the value was
accepted rather than rejected/clamped.
Suggested fix
Either reject amp values above ama with an appropriate error response,
or clamp the value to ama before applying it, both in the Cloud API and
ideally in the charger firmware itself as the authoritative safety layer.
Summary
The Cloud HTTP API (
/api/set) allows setting theampparameter to a valuehigher than the device's own
ama(Absolute Max Ampere) limit, instead ofrejecting the request or clamping it to
ama.Expected behavior
According to the API documentation,
amadefines "the maximum value forampere setting" (e.g. "can not be set to more than 20A in the app"). I
expected the Cloud API to enforce this limit server-side or on the charger
firmware itself, independent of the official app's UI restriction.
Actual behavior
On my charger,
amais set to 16 (matches the physical 16A installation).I sent a request via
/api/set?token=...&=18through the Cloud API.The request was accepted (HTTP 202), and a subsequent
/api/statusqueryshowed
amp= 18AWhy this matters
amaappears to only be enforced as a UI restriction in the official app,not as a hard limit in the charger firmware or Cloud API. Any third-party
integration or custom app relying on
amaas a safety boundary couldtherefore set a charging current that exceeds the electrical installation's
rating, which is a potential safety issue (overload of wiring/breaker) if
the installation isn't otherwise protected independently.
Steps to reproduce
/api/status?filter=amato confirm the charger's configuredamavalue./api/set?token=...&=<value greater than ama>./api/status?filter=ampagain and observe that the value wasaccepted rather than rejected/clamped.
Suggested fix
Either reject
ampvalues aboveamawith an appropriate error response,or clamp the value to
amabefore applying it, both in the Cloud API andideally in the charger firmware itself as the authoritative safety layer.