1. Temperature Control Screen Gateway Protocol

1.1. 1. Document information

• Protocol version: V1.1
• The temperature control screen acts as a gateway and is called the server; the MCU or other devices communicate with the temperature control screen via Wi-Fi or 485 and are called clients
• It is recommended to read the overall interaction sequence diagram in Section 6 first to get an overview

1.2. 2. Communication methods

1.2.1. 2.1 485:

  Connect to the 485 port of the temperature control screen for communication. Because the temperature control screen has only one 485 port, once it is occupied, the temperature control screen can only use the relay interface on its rear cover for the water system function

  485 communication parameters are as follows:

1.2.2. 2.2 Wi-Fi network communication flow

  A UDP broadcast discovery + TCP persistent connection mechanism is used. The MCU obtains the temperature control screen gateway's IP address via broadcast, then establishes a TCP link for data exchange

It is recommended to read point 5 of this section (interaction sequence diagram) first to understand the general flow

2.2.1. Device discovery phase (UDP Broadcast)

  The MCU sends a UDP broadcast packet to the local network to detect online temperature control screen devices

• Local listening port: 5567
• Target port: 43708
• Broadcast address: xxx.xxx.xxx.255 (for example 192.168.1.255)
• Broadcast packet definition:

2.2.2. Temperature control screen gateway response phase (UDP Response)

  After receiving the broadcast, the temperature control screen gateway replies to the MCU with its own IP address information.

• Response data example: FF B0 FF FF 52 30 30 30 34 39 32 35 34 32 33 37 38 31 39 34 32 C0 A8 16 85
• Packet structure parsing:

[!TIP] Parsing note: the MCU must extract the gateway's dynamic IP address from the last 4 bytes of the response packet

2.2.3. Connection establishment phase (TCP Connection)

  After obtaining the IP address, the MCU, acting as the Client, actively initiates the TCP connection

• Target IP: the gateway IP parsed in step 2
• Target port: 9999
• Next action: after the connection succeeds, both parties enter business communication mode.

2.2.4. Business Communication

  During communication, the MCU periodically sends heartbeat PING packets; if the gateway is online, it replies with a heartbeat PONG packet

PING packet

PONG packet

2.2.5. Interaction sequence diagram

sequenceDiagram
    participant MCU as MCU (Client)
    participant GW as Temperature control screen gateway (Server)

    Note over MCU: Listen on UDP 5567
    MCU->>GW: UDP broadcast (Port: 43708)
    Note right of MCU: Send {0xFF, 0xB0...0xAF}

    GW-->>MCU: UDP response (contains the gateway IP)
    Note left of GW: To UDP port 5567, return {0xFF, 0xB0, 0xFF, 0xFF, IP...}

    MCU->>GW: TCP connection request (Port: 9999)
    GW-->>MCU: TCP ACK (connection established)

    MCU->>GW: TCP heartbeat PING (Port: 9999)
    GW-->>MCU: TCP ACK (heartbeat PONG)

    Note over MCU, GW: Start normal business communication

1.3. 3. Data structure

1.3.1. 3.1 Command sent (MCU -> temperature control screen gateway)

1.3.2. 3.2 Data feedback (temperature control screen gateway -> MCU)

• Temperature control screen address: the temperature control screen's own 485 address, 0x01 by default
• Function code: query and control commands
• Function parameter: the parameter value of the function code
• HVAC device address definition:
  • Address length: composed of 2 bytes
  • Air conditioner address: composed of (outdoor unit address, indoor unit address). 01 ????
  • Fresh air address: the first byte is fixed to 0x41 (65), the second byte is the fresh air 485 address
  • Floor heating address: the first byte is fixed to 0x42 (66), the second byte is the floor heating 485 address
• HVAC device status value:
  • Length: composed of 8 bytes
  • Room: defaults to 00

• Checksum calculation: the sum of all data bytes from the "temperature control screen address" up to (but not including) the "checksum", keeping the low 8 bits (overflow ignored)

1.3.3. 3.3 Active status report (temperature control screen gateway -> MCU)

  When the status of a device behind the temperature control screen gateway changes, it proactively sends the status to the MCU; the data format is the same as in Section 3.2, with the HVAC device count in the data being 1

1.4. 4. Query command set

• Query AC status:

• Query fresh air status:

• Query floor heating status:

• Query temperature control screen temperature and humidity:

Command

Response

[!TIP] Actual temperature/humidity value (one decimal place) = (temperature|humidity) / 10

1.5. 5. Control command set

1.5.1. 5.1 Air conditioner control

Air direction parameters

1.5.2. 5.2 Fresh air control

1.5.3. 5.3 Floor heating control

1.5.4. 6. Interaction sequence diagram

sequenceDiagram
    participant MCU as MCU (Client)
    participant GW as Temperature control screen gateway (Server)


    MCU->>GW: 0x50-Query AC status, obtain all AC information
    GW-->>MCU: Send all AC information

    MCU->>GW: Send control command
    GW-->>MCU: Reply with AC status changes

1.6. 7. Command sending examples

1.6.1. 7.1 Query example

• Query all AC parameters under the temperature control screen gateway with address 01:

Send: 01  50  FF  FF  FF  FF  4D
Receive: 01  50  FF  06
01  01  01  14  02  03  20  00  00  00  (10-byte status of indoor unit 01-01)
01  02  00  14  02  01  23  00  00  00  (10-byte status of indoor unit 01-02)
01  03  01  14  02  03  24  00  00  00  (10-byte status of indoor unit 01-03)
02  00  01  14  03  01  20  00  00  00  (10-byte status of indoor unit 02-00)
02  01  00  14  02  03  20  00  00  00  (10-byte status of indoor unit 02-01)
02  02  00  14  03  01  20  00  00  00  (10-byte status of indoor unit 02-02)
3C

1.6.2. 7.2 Control command examples

• Power on the AC at address 1-3:

Send: 01  31  01  01  01  03  38
Receive: 01  31  01  01  01  03  38

• Set the temperature of the AC at address 1-3 to 26°C:

Send: 01  32  1A  01  01  03  52
Receive: 01  32  1A  01  01  03  52