This project contains multilingual documentation. Please select your language:
I am David, an IoT development engineer at Zendure, and I am passionate about Zendure IoT products.
In past projects, we encountered several challenges. To address these, I have been dedicated to developing a new IoT architecture, ZenSDK. I am eager to hear your suggestions to enhance the user experience. Now, I am opening up the Local API Interface, allowing developers to:
- Retrieve their own device information
- Receive device data
- Control devices via API
- Perform creative secondary development to optimize user experience
If you have innovative ideas for Zendure products, feel free to contact me! In my spare time, I will continue optimizing to provide every Zendure enthusiast with an exceptional product experience! 🚀
This document currently supports the following products:
| Product Name | Firmware Version | Notes |
|---|---|---|
| SolarFlow 800 | 1.1.7 | |
| To be updated |
Local control is achieved through a combination of mDNS service and HTTP Server service, enabling automatic device discovery and efficient communication.
- Device Discovery: Utilizing the mDNS (Multicast DNS) protocol, devices within the same local network are automatically discovered, dynamically retrieving service information such as IP address and service port.
- Device Communication: Based on the HTTP protocol, devices can exchange data through RESTful APIs, ensuring efficient and stable local control and collaboration.
| Term | Description |
|---|---|
| mDNS (Multicast DNS) | Azero-configuration network discovery protocol for local networks, allowing devices to resolve and discover each other without a central DNS server. |
| HTTP (HyperText Transfer Protocol) | Arequest/response communication protocol widely used for data exchange between clients and servers, suitable for local network device communication. |
| RESTful API | AHTTP-based API design style that provides a uniform resource access interface with excellent scalability and simplicity. |
- mDNS Broadcast: When a device starts and connects to the network, it broadcasts its service name and type via mDNS. The hostname always follows the format
Zendure-<model>-XXXXXXXXXXXX, providing the device's IP address and HTTP service port. Other devices listen for mDNS broadcasts within the local network to obtain new device information. - Service Name Convention: Device names can include device type and serial number (SN) to help other devices quickly identify their function or role.
- Example:
Zendure-<model>-XXXXXXXXXXXX
- HTTP API Communication: Each device runs an HTTP server within the local network, allowing other devices to communicate via HTTP. With a RESTful API design, the following operations are supported:
- GET Requests: Retrieve device status or data. For example, obtain all device attributes.
- POST Requests: Send control commands. For example, toggle device power.
API Example:
GET /properties/report # Retrieve all current device properties
POST /properties/write # Send control commands, such as switching the device on/off- Communication Message Format: The POST method uses JSON for data transmission, ensuring easy parsing and cross-platform compatibility. Each device should follow a unified JSON data structure for seamless communication.
{
"sn": "WOB1NHMAMXXXXX3", // Required
"properties": {
"acMode": 2 // Corresponding readable/writable attribute
}
}
Get-Service | Where-Object { $_.Name -like "*Bonjour*" }dns-sd -B _zendure._tcpavahi-browse -r _zendure._tcp- C Example
- C# Example
- Java Example
- JavaScript Example
- PHP Example
- Python Example
- Home Assistant Example
- Windows/MacOS/Linux Command Line
curl -X GET "http://<server-ip>/properties/report"
curl -X POST "http://<server-ip>/properties/write" -H "Content-Type: application/json" -d '{"sn": "your_device_sn","properties":{"acMode":2}}'