In order to use the IPC through OpenAPI, the user need to get the IP address of the IPC first.
The first step is to connect the IPC to the network. There are two ways to connect the device to Internet, wired and wireless. Wired network is preferred for its high stability and reliability.
1. Wired Network
For an IPC device with an Ethernet Port, you can connect it to a gateway(such as a wireless router) with an Ethernet cable, then the device can obtain the IP address through the DHCP server.
If the network is available, the LED on the IPC will soon turn blue, indicating that the IPC has connected to the Internet.
2. Wireless Network
The steps to connect to a wireless network are as follows:
- Use your mobile phone or PC to scan the wireless hotspot of the IPC. The SSID of the wireless hotspot is SUNMI_XXXX, where XXXX is the hexadecimal number of the last 2 bytes of the MAC address. The MAC address can be found on the label on the back of the device or on the packaging box.
- Use your mobile phone or PC to connect to the wireless hotspot. The mobile phone or PC will obtain an IP address assigned by the IPC, which is usually 192.168.200.XXX. The gateway address of mobile phone or PC is the address of IPC, which is usually 192.168.200.1.
- Use the wireless configuration API to connect to wireless network. If everything is done correctly, the IPC will obtain the IP address from the gateway.
- If the network is available, the LED on the IPC will soon turn blue, indicating that the IPC has connected to the Internet.
3. Get the Device’s IP address
After the setup of IPC’s network, the next step is to get the IP address of the IPC.
SUNMI provides Device Discovery Protocol for discovering all SUNMI devices that support this protocol on the same LAN. It’s used to scan and collect the basic information of the SUNMI devices, including serial number and IP addresss.
4. SUNMI Device Discovery Protocol
The SUNMI Device Discovery Protocol is for one device to broadcast UDP messages to find SUNMI devices in the same LAN, and other devices supporting this protocol will respond to those messages, which include basic informations of themselves.
4.1 Message Format
The Payload of UDP message is shown in the figure below. The whole message consists of header, Payload and CRC checksum.
4.1.1 Header
The Message Header, including flag, protocol version, message type and length.
Flag: currently fixed to 0xFFFF33FF.
Version: protocol version, currently only version 0x1 is supported.
Type: message type, 0x1 for the discovery request message and 0x2 for the discovery response message.
Len: length of the payload before base64 encoding.
4.1.2 Payload
This field contains the final payload. The raw data is in json format, and it needs to be base64 encoded before put on the payload.
4.1.3 CRC
This field contains the CRC32 (32-bit Cyclic Redundancy Check) value calculated from the header and payload fields. The receiver use this value to verify the message.
4.2 Protocol Port
Both sender and receiver use port 10001.
4.3 Discovery Request
When the sender wants to find devices support the SUNMI Device Discovery Protocol in the LAN, it need to send UDP broadcast message. The details are as follows:
In this message, field Type is 0x01, Len is 0x0, it means that the payload is empty.
4.4 Discovery Response
This message is sent by the receiver. It is used to tell the sender the informations of itself. The type is 0x02, and the length is calculated according to the data.
The payload content is shown in the figure below, which is the device information in json format.
ip: the IP address of the device.
mac: the MAC address of the device.
firmware: the firmware version of the device, such as 1.0.0
name: device name, currently fixed as SUNMI.
model: device model, such as FM020.
type: device type, currently fixed as IPC.
network: the mode of network connection about the sender. If the sender is connected to the wireless hotspot of IPC, the value is “AP”. If the sender is connected to same LAN of router with IPC, the value is “LAN”.
deviceid: device serial number.
4.5 Timeout handling
It is suggested to send Discovery Request messages with an interval of 1s, and 3 times at most. This is to prevent loss of messages from some devices.
After sending 3 Request Messages, the sender should set a timeout period of 2s, after which the Discovery Response message will not be received. That means the Discovery Response message can only be received in 5s after the first Discovery Request message.
After receiving a Discovery Request message, the receiver should reply with a Discovery Response message in unicast mode immediately.
