Setting outputLimit to negative value: allowed but unintended effect

[geostag]

The Zendure SDK is quite fine and enables me to accurately control the device based on my local data and algorithms. Thanks a lot for implementing and documenting this!

Today I realized by accident, that it is possible to set "outputLimit" to negative values. The effect is, that Zendure PF 800 sets the real output power to some very high value - at least I see high output power (more then 500W) on the plug.

I would expect, that negative values are rejected for outputLimit.

To reproduce:

curl -X POST "http://<device-ip>/properties/write" \
  -H "Content-Type: application/json" \
  -d '{"sn": "your_device_sn", "properties": { "outputLimit": -5 }}'

[jquenee]

Don't play with that. I'm suspecting the device is not protected against stack overflow.. And it can probably corrupt your firmware for good. And I almost sure this device is not thread safe.. Concurrent access could have the same effect.
After that, in best scenario, your device becomes unstable forever and in worst scenario, it can becomes a brick.

I'm pretty sure Zendure dev team is not using Rush language and they probably has junior developers...

And for what I know, they don't have factory reset. Which is insane for IoT device !

[geostag]

I just reported an unexpected behaviour which I suggest should be fixed.

I have no evidence concerning the other points you mentioned. In fact, I appreciate very much, that zendure makes the API public and a developer responds to the issues here.

Thank you @dav1dBoy !

[jquenee]

Don’t make me wrong. API initiative is great.
But it is also dangerous knowing firmware is far to be stable. You have been warned.

[dav1dBoy]

The Zendure SDK is quite fine and enables me to accurately control the device based on my local data and algorithms. Thanks a lot for implementing and documenting this!

Today I realized by accident, that it is possible to set "outputLimit" to negative values. The effect is, that Zendure PF 800 sets the real output power to some very high value - at least I see high output power (more then 500W) on the plug.

I would expect, that negative values are rejected for outputLimit.

To reproduce:

curl -X POST "http://<device-ip>/properties/write" \
  -H "Content-Type: application/json" \
  -d '{"sn": "your_device_sn", "properties": { "outputLimit": -5 }}'

Don't play with that. I'm suspecting the device is not protected against stack overflow.. And it can probably corrupt your firmware for good. And I almost sure this device is not thread safe.. Concurrent access could have the same effect. After that, in best scenario, your device becomes unstable forever and in worst scenario, it can becomes a brick.

I'm pretty sure Zendure dev team is not using Rush language and they probably has junior developers...

And for what I know, they don't have factory reset. Which is insane for IoT device !

Hi ALL ！ @jquenee @geostag
Thanks a lot for your detailed feedback and for taking the time to report this behavior. We really appreciate it.

Regarding the outputLimit accepting negative values:
you are right — this is an input validation issue on the API side, and we agree that negative values should be explicitly rejected.

To clarify the observed behavior:
the zenSDK and the device-side HTTP server are implemented in C, and the parameter is currently parsed as an integer type. When a negative value is passed, it can be incorrectly interpreted due to signed/unsigned conversion, resulting in a very large number. Internally, the firmware applies range clamping, so values exceeding the allowed range are capped to the device’s maximum output (e.g. 800 W for SF800), which explains the high output you observed.

This does NOT cause stack overflow, memory corruption, or permanent firmware damage.
The device remains protected by internal safety limits, and invalid values do not bypass hardware or firmware safeguards.

That said, your point is absolutely valid:
parameter validation should happen at every API entry point, and we will record this as a bug and improve input checks to explicitly reject invalid or negative values in future updates.

Regarding thread safety and concurrent access concerns:
the HTTP server is built on ESP-IDF and FreeRTOS. API handlers are designed as stateless request entry points, and device control logic is internally serialized. While concurrent HTTP requests are supported, they do not directly modify hardware state in parallel or bypass internal protection mechanisms.
At present, there is no evidence that concurrent access leads to firmware corruption or device bricking. Still, we take robustness seriously and continuously review concurrency handling and architecture design.

We truly value community feedback like yours. Making the API public is a deliberate choice, and reports like this help us make zenSDK and Zendure products safer and more reliable for everyone.

Thanks again for your warning and for engaging constructively with us 🙏
We will keep listening and improving.