FAQ
TL;DR: If you own the ZMAi-90 CBU version with BK7231N, back up the 2MB flash first, then remove the RN8209C or it will block UART writes. As one expert put it, “TX1/RX1 is for both flashing and TuyaMCU.” This FAQ is for users who want local OpenBeken control, relay switching, and RN8209 power metering without Tuya cloud. [#20827152]
Why it matters: This thread shows the exact failure points, safe flashing path, GPIO map, and early RN8209 support for the BK7231N-based ZMAi-90.
| Method |
Read backup |
Write OpenBeken |
Main limitation |
| bkWriter 1.60 |
Unreliable on BK7231N |
Unreliable |
Better on BK7231T than BK7231N |
| BK7231GUIFlashTool / newer flasher |
Yes |
Yes |
Still blocked if RN8209C holds UART |
| VDD “trick” with RN8209C still present |
Yes, with hack |
No |
Read worked, write current was insufficient |
| Desolder RN8209C first |
Yes |
Yes |
Requires SMD rework |
Key insight: The blocker is not the CBU module itself. The RN8209C shares UART lines with the BK7231N, so reliable flashing required desoldering the RN8209C before writing OpenBeken.
Quick Facts
- The confirmed backup size for the CBU BK7231N module was 2MB, and the thread explicitly recommends taking that dump before flashing so the Tuya firmware can be restored if needed. [#20821174]
- Confirmed GPIO map for one black-board ZMAi-90 CBU variant: P6 = WiFi LED, P7 = pair button, P14/P16 = bridge relay pair, P26 = tipped LED. [#20840241]
- The RN8209 test driver was calibrated with a 60W bulb; voltage and power worked first, while current remained inconsistent on at least one device. [#20857064]
- Bench tests showed the meter being checked at 220V, 247V, and 194V with an autotransformer, which helped validate voltage tracking after driver work began. [#20850811]
- Home Assistant discovery later exposed voltage, current, power, and total energy, but one derived counter stayed Unknown for at least one user. [#20867145]
How do I flash a ZMAi-90 smart energy meter with a CBU BK7231N module to OpenBeken step by step?
You flash it by backing up the CBU first, then isolating the BK7231N from the RN8209C, then writing OpenBeken. 1. Connect to the CBU pads for
GND, RX, TX, and 3.3V, and make a
2MB backup. 2. Desolder the RN8209C, because it blocks UART flashing on this board. 3. Use the newer BK7231 flasher to write OpenBeken, then restore the RN8209C and apply the GPIO template. That was the first reliable write path confirmed for this CBU black-board version.
[#20838678]
Why does the RN8209C chip block flashing on the ZMAi-90, and why do people end up desoldering it first?
The RN8209C blocks flashing because it shares the BK7231N UART lines used for programming. On this board, the RN8209C sits on the same UART path as
TX1/RX1, and its
RST_N is tied to
RX, so holding it in reset also breaks UART access. A read-only hack worked by starving the rest of the board, but writes still failed. That is why desoldering the RN8209C became the practical solution for reliable OpenBeken flashing.
[#20838936]
What is TuyaMCU, and how do I tell whether my ZMAi-90 uses TuyaMCU or a custom protocol?
TuyaMCU is one possible control method, not a guarantee on every ZMAi-90.
"TuyaMCU" is a serial control protocol that lets a main MCU exchange datapoints with the Wi-Fi module over UART, using structured packets instead of direct GPIO control. To identify it, check whether the CBU
TX1/RX1 lines connect to the device MCU and whether packet datapoints can be decoded. The thread also warns that there are
at least three separate ZMAI-90 versions, so board inspection matters before assuming TuyaMCU support.
[#20856983]
What is a dpID in Tuya devices, and how can I find the datapoints for a ZMAi-90 energy meter?
A dpID is the numeric identifier for each Tuya datapoint.
"dpID" is a Tuya datapoint identifier that labels a specific function or measurement, such as relay state, voltage, or energy total, inside UART or cloud-reported packets. The thread gives three ways to find them: capture hex traffic and feed it to TuyaMCUAnalyzer, inspect datapoints in the Tuya developer platform after pairing the device, or infer them from values like
2300 = 230.0 kWh. The safer path recommended there was the Tuya platform route.
[#20821311]
Which UART pins on the CBU board are used for flashing and TuyaMCU communication, and what is TX2 used for?
Use
TX1 and RX1 for both flashing and TuyaMCU communication. The thread states clearly that
TX2 is only for
debug log output, not for normal flashing. That distinction matters because several failed attempts happened before the pin roles were clarified. One expert answer in the thread said, “TX2 is only for debug log output. TX1/RX1 is for both flashing and TuyaMCU.”
[#20827152]
What's the correct way to make a 2MB flash backup of a BK7231N CBU module before installing OpenBeken?
Start the flash read first, then reset power so the BK7231N can enter the boot path. 1. Connect
GND, RX, TX, and 3.3V to the CBU. 2. In the flash tool, click
Read before cycling power. 3. Disconnect and reconnect
3.3V, or briefly discharge the module side as described, so it can “get bus” and begin the
2MB read. The thread used this order repeatedly and confirmed that a backup was successfully extracted from the Wi-Fi module, not the RN8209C.
[#20827069]
Why doesn’t bkWriter 1.60 work reliably with BK7231N, and how does BK7231GUIFlashTool compare for reading and flashing?
bkWriter 1.60 was reported as unreliable on BK7231N because it worked better on BK7231T. The thread explicitly says
bkWriter 1.60 may not work good for N platform, then recommends
hid_download_py or
BK7231GUIFlashTool instead. In practice, the newer tooling matched the BK7231N better, but it still could not solve hardware UART contention from the RN8209C. So the software choice mattered, yet board-level interference still determined success or failure.
[#20827069]
What safety precautions should I follow when probing UART or flashing a mains-powered ZMAi-90 energy meter?
Never connect a USB-UART adapter directly to the device while it is powered from mains. The thread warns that the power supply may not be isolated, so UART probing on a live
230V unit can be dangerous. Use an
optoisolator if you must inspect serial traffic on a mains-powered board. A safer alternative is to remove the Wi-Fi board or power only the detached CBU from
3.3V during backup and flashing work.
[#20821311]
How can I stop the RN8209C from interfering with UART flashing without damaging the board?
The least ambiguous method is to desolder the RN8209C or cut the UART trace. Reset tricks were discussed, but on this board the RN8209C
RST_N shares the
RX path, so reset does not cleanly free UART. A temporary read-only hack worked by forcing the Wi-Fi module to power while the MCU side stayed unpowered, but that did not support writing firmware. If you want reliable flashing without repeated failures, remove the RN8209C first and solder it back afterward.
[#20838936]
Which GPIO template works for the ZMAi-90 CBU version, including relay, WiFi LED, tipped LED, and pair button pins?
The working template for one confirmed CBU BK7231N black-board version maps
P6 = WifiLED_n,
P7 = Btn,
P14 = BridgeFWD,
P16 = BridgeREV, and
P26 = LED. Relay control used the
P14-P16 bridge pair, not a single GPIO. Another user later simplified the relay mapping to
Rel and
Rel_n, but the original bridge template was the first published map tied to this teardown. Use that template only after confirming your board matches this variant.
[#20840241]
How do I start and calibrate the RN8209 driver in OpenBeken for the ZMAi-90 using a known load like a 60W bulb?
Start the RN8209 driver with a startup command, wait a few seconds, then calibrate against a known load. The exact command given was
startDriver RN8209. After starting it, wait about
3 seconds, because early driver updates were slow, then calibrate using a
60W bulb as the reference load, similar to Tasmota practice. The developer reported that voltage and power responded after this process, even before current behavior was fully solved.
[#20857064]
Why do I get CRC BAD errors and zero readings from the RN8209 driver after flashing my ZMAi-90?
CRC BAD usually means the RN8209 communication path is wrong or physically disturbed. In the thread, one user saw repeated bad CRC and all-zero voltage, current, and power, then revealed a missing
SMD capacitor near the communication path after rework. The reply noted that if that capacitor was on
RX/TX, it could directly affect metering communication. Old firmware builds also caused issues, so the user was told to move from a
Dec 5 build to a
Dec 7 build first.
[#20857903]
How do I publish ZMAi-90 RN8209 voltage, current, power, and total energy readings to Home Assistant through MQTT discovery?
Start the RN8209 driver before running Home Assistant discovery. The developer added the missing discovery check, then instructed users to
startDriver RN8209 first, run
HASS discovery second, and verify the entities afterward. After that fix, users reported voltage, current, power, and later
Total Energy appearing through MQTT discovery, although one counter entity still stayed
Unknown. If discovery runs before the driver starts, some entities may not appear.
[#20865267]
What causes the current measurement on the ZMAi-90 RN8209C to be inaccurate even when voltage and power look correct?
The thread points to an incomplete RN8209 communication or calibration issue, not a finished hardware fault diagnosis. The developer repeatedly said voltage and power looked correct after calibration, while current stayed wrong and “something must be missing” in the implementation. Another tester reported smaller current mismatch:
0.010 A on a clamp meter versus
0.033 A in the web UI when off, but matching
0.051 A when on. That pattern suggests the driver was usable but not fully mature for low-current accuracy.
[#20866430]
Which LCD controller chip is used on the ZMAi-90 display board, and how could OpenBeken support that screen?
The LCD controller was not confirmed in the thread. The display IC on the tested board had
no visible marking, so the developer could not identify it directly. Another participant suggested it might match an
HT1621B-family 48-pin controller, but that remained an informed guess, not a verified finding. OpenBeken support would require first identifying the controller and then writing a custom display driver, just as the RN8209 driver had to be written from scratch.
[#20864564]
Generated by the language model.
