I’m working on integrating the KL8300-HV83G controller with the KL8-3H-FACE3 panel (spa/pool management system) into Home Assistant using ESPHome and an ESP32.
Goal: Retrieve useful data, especially the water temperature.
What I’ve tested so far
1. Documentation research
No public technical documentation available (pinout, protocol, datasheet).
Researched across:
Forums (Home Assistant, Domoticz, Jeedom…)
GitHub (e.g., bbqkees/BalboaSpaWifi)
Chinese sites (1688, Alibaba – PCB photos, no docs)
Distributors (Poolstar, iPool…)
Wayback Machine
→ Conclusion: The 8-pin connector on the KL8300 is likely UART TTL 5V.
2. Hardware tests
Voltage measured on each pin:
GND and 5V lines clearly identified
Other pins are either 0V, floating, or fixed at ~5V
UART sniffing with ESP32:
Voltage reduction using resistor divider (2×1kΩ in series for R1, 1kΩ for R2 to GND)
Attached are photos of the pinouts.
The ESP power is taken from connector 2.
The pin numbers in the image are the order in which I consider the pins.
The goal is to find the TX so that I can listen to the communication.
Yes the measured voltage is stable at 5V, I am sending a photo of the second connector to follow (being new to the forum I can only send one image at a time)
Unfortunately, I am not equipped with an oscilloscope.
below is the table of connector 1 measured by voltmeter:
Pin , Idle , voltage , Voltage when pressed Notes
1 , 5.09 V , 2.22 V , Sharp drop → possible TX line?
2, 5.09 V , Oscillates around 3.78 , V Fluctuations → suspected TX too
3 , 2.90 V , Rises to 5.09 V quickly , Transient behavior
4 , 5.09 V , Oscillates around 3.78 V , Identical to pin 2
5 , 0.07 V , Rises to 1.40 V , Could be a logic control line
6 , 0.03 V , 0.03 V , Inactive
7 , 0.00 V , 0.00 V , GND likely
8 , 0.00 V , 0.00 V , GND likely
Hello — I would like to communicate directly with the KL8-3H-FACE3 from an ESP32.
My goal is to replace the PIC on the control board and command the power board directly while keeping the original keypad and display. Any information about the nature of the communications between the topside and the control module would be extremely helpful. thanks
Hello,
I’ve resumed working on this project following ziporah’s post. The link to the thread on the Aqara forum is, I think, spam… because there’s nothing truly substantial being discussed, and besides, it’s almost identical to my post here.
I removed the stickers from the ICs on the board:
201SAVER3 = HT48R10A, Holtek 8-bit MCU
KL8300-HV83G = HT46R23, Holtek 8-bit MCU with ADC
After analyzing the LCD connector with a logic analyzer, it’s not UART as initially assumed, but a proprietary SPI-like protocol (3 wires).
The LCD bus only carries the display, specifically the temperature. The states of the equipment (pumps, lighting, etc.) are not present on the LCD bus and seem to be transmitted via the keypad connector.
The display encoding corresponds to a standard 7-segment format (gfedcba table), with the segments embedded within the address byte.
I am now continuing the analysis on the KEY side to identify usable states.
Thanks for picking it up again. Have you setup a github repo already somewhere which documents your findings ? If the buttons contain no real magic status leds, is it just defined as a remote button matrix then, with the display defined seperatly over the other cable ?
Thank you.
I haven’t created a public GitHub repository yet. The priority was first to validate the protocol and architecture to avoid documenting false assumptions. The publication will come once the KEY part is confirmed.
Regarding the keyboard: at this stage, it’s very likely not just a simple passive button matrix.
Initial measurements show active levels and persistent variations, suggesting that the KEY connector is used both for:
button scanning and for receiving feedback on internal states (pumps, lighting, etc.).
Analysis in progress: capturing signals from the keyboard connector with a logic analyzer, using a 74HC125 buffer to avoid disrupting operation, as the commands would otherwise be blocked.
The display is indeed handled separately via the LCD connector, but the states visible to the user don’t seem to be sent back on this bus. This is precisely what I’m analyzing on the KEY side with the logic analyzer.
Regarding the LCD (temperature) protocol, which has already been decoded:
Decoding via lookup table (non-standard encoding)
Examples of captured correspondences:
10°C = 0x0C/0x0E
11°C = 0xF8/0xFA
16°C = 0xBC/0xBE
22°C = 0xB4/0xB6
25°C = 0xF4/0xF6
The STATUS byte (0x09 or 0x89) varies but does not appear to be correlated with the equipment states.
I used to have a bestway spa which I integrated wifi in it using this repo:
I love the way the ESP is set in the middle of the connection between the display board and the controller. It might be an idea to design a circuit that just sits in the middle with 2 db-15 connectors. One part to sniff on the display data and another part as man in the middle to use as controller or still have manual control over the spa. I am happy to assist in the designing of the pcb
Hello,
Thank you for the link. Yes, indeed, the goal is to create something similar, but we’re only at the beginning… And thank you for your suggestion.
I started capturing some data yesterday on pump 1. I’m making slow progress given my schedule…
