Skip to content

protocol.md

Latest commit

 

History

History
135 lines (93 loc) · 6.83 KB

protocol.md

File metadata and controls

135 lines (93 loc) · 6.83 KB
Raw

Protocol

Baud rate 115200.

This protocol allows sending and receiving one key/value pair per packet. The client (in this case, an Arudino microcontroller) sends a packet to query or set a value for a key, and the server (in this case, the control board) replies with a packet containing a key/value pair.

After writing a packet, clients must wait for a response packet before sending another packet.

Querying State

To query current state on a given key, clients can issue a packet with the given key and value being 0. Clients can then expect in response a packet with the same key, and the currently set value for that given key.

Setting State

To set state, issue a packet with the key and value to set. Clients can then expect in response a packet with the current state.

Note

There appears to be a bug in the control board firmware causing mismatched responses: apparently the control board always sends the current state of the last queried key, rather than the current state of the key being set.

Packet Format

Length (B) Datum Value
2 Preamble 0x5a5a
1 Length uint8 bytes remaining in this packet
1 Device Type 0x01
1 Key uint8, see Keys
Length-5 Value Key-Dependent
1 Checksum uint8 sum of each preceeding byte in packet
2 Postamble 0x0d0a

Device Type

Device type 0x01 applies to air conditioners.

Other device types appear to be supported, but they lie outside the scope of this project. Source code analysis of U-Frigo, which works atop a very similar wire protocol, revealed other device types including air, water, and dual-mode heaters.

Keys

Key Intent R/W Type Value
1 Power R/W uint8 On/Off Values
2 Mode R/W uint8 Mode Values
3 Set Temperature R uint8 Set Temperature Values
4 Fan Speed R/W uint8 1-5
5 Undervolt Protection R/W uint8 decivolts
6 Overvolt Protection R uint8 Volts
7 Intake Air Temp R int8 °C
8 Air Outlet Temp R int8 °C
10 LCD R/W uint8 LCD Values
16 Swing R/W uint8 On/Off Values
18 Voltage R uint16 decivolts
19 Amperage R uint16 Always 0
28 Light R/W uint8 Light Values
66 Active R/W uint8 See Initialization

Mode Values

Value Intent
1 Cooling
2 Heating
3 Fan
4 Eco Cooling
5 Sleep Cooling
6 Turbo Cooling
7 Wet Mode TODO: What even is this?! Heat + Cool maybe?

Note

There appears to be a bug in the control board firmware causing heating to engage for a few seconds every several minutes when mode is set to 2 (Heating), even if the power is set to 1 (Off). To work around this, always set mode to 1 (Cooling) before setting power to 1 (Off).

On/Off Values

Value Intent
1 Off
2 On

LCD Values

LCD handling in the Summit2 firmware has the following unique behavior:

  1. When the unit mode is anything other than Off (heat, cool, fan only, etc.):
    • A serial-reported value of 1 represents Off.
    • A serial-reported value of 0 represents On.
  2. When the unit is Off, the LCD is physically always off, regardless of the serial-reported value (which persists at whatever value it held before the unit turned off).
  3. When the unit is turned back on in any active mode, the LCD automatically turns back on and reports its status as 0 (On).

Set Temperature Values

The board can be set in Fahrenheit or in Celcius (using the IR remote).

When set to Celcius, values are related in whole degrees Celsius, within the range 17-30 inclusive.

When set to Fahrenheit, values are related in whole degrees Fahrenheit, within the range 61-86 inclusive.

Important

In older versions of board firmware, setting temperature does not work due to a firmware bug. This bug is fixed as of 2025-08.

Light Values

Light handling in the control board firmware appears to be quite buggy:

  1. Though this is an on/off control, the values are opposite to all other on/off controls.
  2. When queried, this value returned is almost always 1, regardless of actual state.
Value Intent
1 On
2 Off

Initialization

Note

This section describes the initialization sequence that the bluetooth module and app perform. It is not necessary and is documented here only for completeness.

The board starts by sending in ASCII an AT command to the bluetooth module.

AT+NAME?\r\n

The module responds in ASCII with its name.

\r\n+NAME:KT2025040004510\r\nOK\r\n

From this point on the board and module communicate in packets as described in the packet format.

The app immediately queries the Active (66) key on connect. If the control board responds with the value 2, the app sets the value to 1.

Following this, keys 2, 3, 7, 8, 18, 19 are queried in the app by writing the value 0, causing the controller to reply with current values.

Finally, the app auto-refreshes values 7, 8, 18, 19 every second or so.