It would be great because up until now I have failed miserably when trying to read the firmware. I've found the way to power up the board but I'm having problems with TX and RX due to lack of experience.
I was trying to connect directly to CSE but without any luck.
[Edit] And where should I cut if that is a solution for backup fw? I can remove CSE for the time being but I'm not so sure that I will be able to place it back due to my soldering skill.
CSE7759B may interfere with the flashing of WiFi module. Once the connection to CSE7759B is temporarily removed, you can first make a 2MB backup of the flash, maybe extract Tuya Config from that, if possible, and later try to flash the OBK
So, where do you connect them currently? Which two of four pins on the white ribbon are VDD and GND? The RX/TX port of CB2S is at the PCB side, so it may be hard to follow it.
Are you sure that CSE7759B and CSE7766 are using the same protocol? I don't remember checking my driver on CSE7759B, you may be the first one with it.
I may need to adjust the driver if there is a difference
Is only current read broken, voltage and power are correct?
Make sure the serial link is set to 4800bps. Each meter reading (from the CSE chip) is 24 bytes. The code below assumes you have read the 24 bytes from the CSE chip into inData[] (byte array) (starting with 55 5A) .
Extract the volts from the inData byte array like this:
Extracting the watts & amps is the same except use a different position in the inData array (as the instructables link above shows).
Hope this helps. I find these CSE chips are sensitive and very accurate but they don't tell you the direction of the current.
BTY, a NAN float value is probably caused by a division by zero. The most common mistake is shifting the data left in a byte and making it zero. The ULONG (unsigned long) data conversion in the GetData() function prevents this.
Looking at the photos of the Tuya WiFi Energy Meter in taktlos's original post, the circuit does not appear to have the live AC side isolated from the DC side. If you try to flash that with it connected to the power it could destroy your computer. This also makes it hard to debug and the circuit could be dangerous to touch. So, maybe it is better to use a power meter that is properly built?
Most cheap power meters from China have the CSE7759 chip in them which we know is easy to read with an arduino. The meter shown below came with an inverter I bought from AliExpress. I expect most cheap meters with an LED display from AliExpress are similar.
The bottom photo shows the meter main PCB with the display PCB removed. I have connected the CSE7759 chip and 5V power to the Arduino pro-mini and been able to read the power meter with the code I described in my posts above. The meter still works and displays the watts and volts on the display board if you fit it to the main board.
Looking at the main PCB (bottom photo), positioned at the bottom left is the 5V power supply module. Position at the mid-right on the main PCB is the ZMPT107 transformer which acts as an isolation transformer for reading the voltage. The CT current sensor is plugged into the top right connector. This totally isolates the DC side from the AC side and makes the DC side safe to work on and debug with the meter functioning.
The bottom connector is for power. Above the ZMPT107 is the CSE7759 chip which is easy to connect to the arduino with just 2 wires.
Another reason why this solution may be better is because many places (like Australia) have the home power meter in a metal meter box on the side of the house. So the WiFi won't work if it is in a grounded metal box. So, this way we can have the arduino+wifi+antenna mounted in a separate case on top of the meter box and connected to the power meter with a 3 or 4 wires. A proper antenna would also provide more wifi range. You might need to check that the arduino and wifi module does not overload the 5V power supply module on the main meter PCB.
Will this read negative power? It seems most Tuya devices are configured from the factory not to, even when having a supported power meter IC such as the BL0942
No, that's a big deficiency with the CSE7759 chip. Apparently, China hasn't learned how to read the direction of AC power yet. The only power meters I can find from China that read import/export power do it with two current sensors. Here is one from Tuya, but it is one of those non-isolated meters, so be careful. If you clip one CT sensor onto the AC output from the solar inverter and the other one onto the home mains, the difference should be the import/export power.
Alternatively, one way to read AC power and direction with an Arduino and one CT sensor is to use the Emon lib. See here: Link
To do this you will have to construct the CT sensor and Voltage sensor circuits given in the schematic. Link
That's not too hard. The website explains the calibration procedure. Link
I am considering building a phase detector circuit for the CSE7759 chip which will indicate the direction of the current. I will post it here if I make progress on that.
BTY, this is the meter in my post above. Apparently, it is the only one I can find with an isolated DC circuit. Just search AliExpress for: "Current Limiter Sensor for Soyosource GTN" Link
If you want to read this meter directly from its RS485 port, there is code for that available. This code simulates the meter's RS485 serial output and explains the protocol. Link
Thanks for sharing. I wasn't aware of that sensor, using the two halls. That explains right the home assistant configuration with the strange two sensor input and 'calculations'.
Meters based on the BL0942 can measure bi-directional. The problem is that the Chinese don't implement this feature on their firmware (it needs flashing with open Becken) and it's not always easy to know which ones have this chip. While they are not isolated, it is easy to isolate the BL0942 chip using a Silicon labs SI8621 or other equivalent, right at the serial interface, if the MQQT readings method is not suitable.
PS: Calibration (and drift) from a hall sensor are a nonsense. With a standard shunt resistor, calibration is done once and fairly accurate throughout the load range. Super easy to do on OpenBecken too. Just connect a resistive load of known consumption and set the values on the web interface.
I started a thread about it here: Link, so as not to hijack this one
Hi p.kaczmarek2, your help is more than welcome. Same with anyone else.
A safe bidirectional power meter module for arduino is desperately needed. The wifi in those cheap non-isolated wifi meters from China won't work inside a metal meter-box because it is inside a Faraday cage. If someone tries fit an external antenna to the wifi module it could cause a big problem. This is because the ground (0V) in those non-isolated meters is connected directly to the AC neutral (N) wire. So if you use a coax cable to put an external antenna on top of your meter-box and use the meter-box as the ground plane, this will trip the earth leakage detector in the AC power circuit breaker. This is because some of the AC power going into the meter will return via the meter box earth (E) and not the neutral wire (N). The other problem is with trying to code, debug and calibrate a live circuit.
The circuit below is based on the isolated CSE7759 power meter in my posts above. Both the CSE7759 and BL0942 chips use a 0.001 ohm shunt resistor for the amps and a 1000:1 divider circuit to measure the volts, so this should work. We could make the burden resistors variable for calibration?
I have ordered all the components and will try to get a prototype working. Any suggestions are welcome. If, you want to start a new thread for this project that's ok with me.
If you want to use the BL0942 as above, then my suggestion is to keep the mains referenced stuff and isolate at the RS232 level. I attach one such reference design for you to have a look - But in practice you can use any design and just add the opto-isolators to the serial line. You'll probably want to keep the WiFi chip on reset and instead use one externally, if WiFi range is a problem.
I had a look at the CSE7759, but it doesn't appear to have a feature to measure the direction of the power flow. So you can't use that for a bidirectional power meter. It will give you the absolute value, but not the direction. It seems similar to the BL0937.
Attachments:
BL0942模块原理图.pdf(159.69 KB)
You must be logged in to download this attachment.
✨ The discussion revolves around the challenges faced while programming the EARU EAWEM-T-CT power meter, which utilizes the CSE7759B chip. Users share experiences regarding firmware reading, UART communication issues, and the need for proper connections to successfully flash the device with OpenBeken firmware. Several users suggest methods for connecting the CSE7759B and CB2S chips, including desoldering components and using specific programming adapters. The conversation also touches on the differences between the CSE7759B and CSE7766 chips, calibration issues, and the importance of isolating the device during programming to prevent damage. Additionally, there are discussions about the limitations of the CSE7759B in measuring bidirectional power and the potential need for a new driver to support it. Generated by the language model.
TL;DR: If your EARU EAWEM-T-CT uses a BK7231N-based CB2S and a CSE7759B, first back up the 2MB flash and isolate the UART path; as one expert put it, "CSE7759B may interfere" with flashing. This FAQ is for OpenBeken users who can flash the WiFi module but still get missing readings, bad packets, or NaN current values. [#20843806]
Why it matters: This meter can accept OpenBeken, but successful flashing, safe debugging, and usable energy readings depend on the exact UART wiring, startup commands, and CSE7759B protocol behavior.
Option
What the thread shows
Main advantage
Main limitation
CSE7759B in EARU EAWEM-T-CT
OpenBeken can be flashed; current parsing may fail
Uses the device you already own
Non-isolated design and protocol mismatch issues
BL0942-based meter
Reported as suitable for bidirectional power
Can support negative/import-export power
Often still non-isolated and needs firmware work
Isolated meter with RS485/CT
Suggested as safer inside metal boxes
Safer debugging and easier external interface
Different hardware path and extra wiring
Key insight: Flashing the CB2S is only the first milestone. The harder problem is that several EARU units output CSE7759B UART frames the current OpenBeken CSE7766 driver does not parse correctly, including headers seen as 0x55 0x5B instead of 0x55 0x5A. [#21154820]
Quick Facts
The original firmware backup discussed in the thread is 2MB, and removing the CSE7759B connection was recommended before reading or flashing the CB2S. [#20843806]
The CSE serial link was explicitly described as 4800 bps, with each reading expected to be 24 bytes starting with 0x55 0x5A in the working decode example. [#21007540]
A real OpenBeken reading showed 240.594451 V, 22.981819 W, 35.924919 apparent value, and 0.637960 power factor, while current returned nan. [#20843887]
One user verified live app readings around 236.6 V, 7-11 mA, and 1.5-2.3 W on an original EARU unit, yet the UART header still appeared as 0x55 0x5B. [#21154820]
The thread repeatedly warns that this EARU design is not isolated, so powering or probing it from a USB programmer while mains is present can damage a computer or create a shock hazard. [#21010697]
How do I flash OpenBeken onto an EARU EAWEM-T-CT with a BK7231N CB2S module when the CSE7759B is interfering with RX/TX communication?
Disconnect the CSE7759B path first, then back up and flash the CB2S. The thread’s working sequence was: 1. temporarily remove the CSE connection, often by desoldering the white ribbon or isolating the UART path; 2. make a 2MB flash backup; 3. upload OpenBeken and restore hardware. One user finally succeeded only after unsoldering the CB2S, programming it directly, and soldering it back. That is the clearest confirmed recovery path when the meter chip blocks UART access. [#21065077]
Where should I connect RX, TX, VDD, and GND on the EARU EAWEM-T-CT board to back up the original 2MB firmware from the CB2S module?
Use the CB2S UART, not the CSE7759B UART, for the firmware backup. The thread states GND was identified on the 4th wire of the 4-wire ribbon, while the CB2S RX/TX lines were said to be on the PCB side and hard to trace. One user initially connected to the CSE’s 8th and 6th pins and later managed to back up the original firmware, but that was a workaround, not a confirmed CB2S pin map. For this board, VDD and GND come from the ribbon, and RX/TX must ultimately land on the CB2S serial pins. [#20843887]
Why does the EARU EAWEM-T-CT show voltage and power in OpenBeken but return NaN for current readings with the CSE7759B?
The current field returns NaN because the driver is likely decoding the CSE7759B stream incorrectly. A working OpenBeken snapshot showed about 240.59 V and 22.98 W, yet current stayed nan, even after calibration. The thread later identified a likely cause: the existing OpenBeken code targets CSE7766 behavior, while this meter’s CSE7759B may use a different packet format or header. Another contributor also noted that NaN often comes from division by zero during value extraction. [#20852687]
What startup commands and pin configuration do I need in OpenBeken to make a CB2S-based EARU EAWEM-T-CT start reading from a CSE7759B?
Use startDriver CSE7766 in autoexec.bat, then enable the alternate UART path. The thread also says to set Flag 26, described as using the alternate UART for BL0942, CSE, and similar chips. One user added startDriver NTP and startDriver CSE7766, then enabled Flag 26, but still saw no CSE logs. That means the startup side is necessary, yet not sufficient if the board wiring or packet format differs. The missing piece may be driver compatibility rather than a menu pin assignment. [#21068506]
How do I calibrate voltage, current, and power in OpenBeken for a CSE7759B energy meter using commands like VoltageSet?
Calibrate it the same way Tasmota-style CSE meters are calibrated in OpenBeken. The thread explicitly recommends commands such as VoltageSet, and later notes that calibration can also be done from the Web App Tools tab. One user tried calibration multiple times with different loads and still got NaN current, which shows calibration only works after valid UART parsing. Start with known mains voltage and a known resistive load, then adjust voltage, current, and power scaling values until the readings match. [#21065924]
What is the difference between the CSE7759B and CSE7766 protocols, and why might the existing OpenBeken CSE7766 driver fail on a CSE7759B?
The thread shows they are similar enough to share a driver name, but not similar enough to guarantee correct parsing. OpenBeken currently starts CSE7766 for both, yet multiple EARU users captured CSE7759B frames that did not match the expected header or decode logic. That mismatch explains why voltage may appear while current fails, checksums break, or no packets parse at all. The practical conclusion was direct: a separate CSE7759B driver may be required instead of reusing drv_cse7766.c unchanged. [#21154826]
Why would a CSE7759B serial stream start with 0x55 0x5B instead of the expected 0x55 0x5A from the datasheet?
Because at least some real EARU units output 0x55 0x5B, even though the datasheet excerpt cited in the thread says 0x55 0x5A. One user captured repeated 24-byte frames from both OpenBeken-flashed and original-firmware devices and consistently saw 0x55 0x5B. That strongly suggests either a device-specific variant, a board-level inversion or corruption effect, or a CSE7759B revision that differs from the referenced document. In practice, OpenBeken will miss valid packets until the driver accepts the actual header observed on hardware. [#21154820]
How do I decode the 24-byte UART packets from a CSE7759B or CSE7766 to calculate volts, amps, and watts correctly?
Read 24 bytes at 4800 bps, then build 24-bit values from three bytes each before dividing coefficient by cycle. The thread gives a concrete method: GetData(h,m,l) = ((ULONG)h << 16) | ((ULONG)m << 8) | l. It also warns to cast to ULONG before shifting, or the math can collapse to zero and produce NaN. "CSE7759B is a metering IC that streams 24-byte UART frames, each carrying coefficients, cycle counts, and a checksum for voltage, current, and power calculation."[#21007588]
What causes bad checksums and corrupted packets when reading CSE7759B or CSE7766 data over UART, and how can I filter them?
Bad packets come from dropped bytes, merged frames, or serial noise, and the thread shows all three. OpenBeken logs included repeated Skipping packet with bad checksum messages and reports that unwanted non-header bytes had to be consumed before resynchronizing. A contributor also states that not every CSE reading is good and gives a checksum rule: sum bytes 2 through 22 and compare that result with the last byte. Filter by header, enforce exactly 24 bytes, verify the checksum, and discard frames that fail any one test. [#21007588]
What is CB2S, and how does it relate to the BK7231N and Tuya WiFi devices like the EARU EAWEM-T-CT?
CB2S is the Tuya WiFi module fitted on this meter, and the thread identifies it as the board built around a BK7231N. In this EARU design, CB2S runs the Tuya or OpenBeken firmware, handles WiFi, and communicates with the metering chip over UART. That is why users flash OpenBeken onto the CB2S rather than onto the CSE7759B. "CB2S is a Tuya WiFi module that hosts the BK7231N SoC, provides wireless control, and links the main firmware to peripherals such as the CSE7759B energy chip."[#20840240]
What is OpenBeken, and how does it replace Tuya firmware on energy meters built around BK7231N modules?
OpenBeken is replacement firmware for Tuya-style BK7231N modules such as the CB2S used here. In this thread, users backed up the original 2MB flash, uploaded OpenBeken, and then configured the meter driver and calibration from the web interface. That lets the device join WiFi without the Tuya cloud and expose energy readings locally. It does not guarantee full metering support, though, because the WiFi module can flash correctly while the CSE7759B data path still fails. [#20843887]
CSE7759B vs BL0942: which chip is better for OpenBeken-based power monitoring, especially if I need bidirectional or negative power measurement?
BL0942 is the better fit if you need bidirectional or negative power measurement. The thread says the CSE7759B does not report current direction and only yields absolute power, while BL0942-based devices were discussed as capable of import-export measurement once firmware support is added. That makes CSE7759B acceptable for ordinary consumption metering, but a poor choice for solar or net-flow monitoring. If your main requirement is negative power, choose hardware built around BL0942 instead of trying to force that feature into CSE7759B. [#21013413]
How should I safely power and debug a non-isolated Tuya energy meter without risking damage to my USB programmer or computer?
Do not connect a grounded USB programmer to this meter while mains is present. The thread explicitly warns that the EARU circuit does not appear isolated between the AC side and the DC side, and says flashing it live could destroy a computer. Safer approaches discussed were powering only the low-voltage side for UART tests, using an isolated serial adapter, or choosing an isolated meter design with RS485 or CT sensing. That safety point matters more than convenience because the board can also be dangerous to touch during live debugging. [#21010697]
What are the best alternatives if WiFi signal is poor inside a metal meter box, such as RS485, PLC, or using an external isolated interface?
Use a wired or isolated external interface instead of relying on onboard WiFi. The thread recommends RS485, PLC, or moving the controller and antenna outside the metal box, because a grounded meter box acts like a Faraday cage. One contributor described an isolated meter with RS485, while another proposed mounting Arduino plus WiFi externally and linking the meter over 3 or 4 wires. PLC was also discussed as a long-range option, with one module claimed to reach over 1 km, though low-bandwidth tradeoffs were noted. [#21015381]
How do I create or modify an OpenBeken driver for a CSE7759B if the existing drv_cse7766.c code does not parse the device's serial data correctly?
Copy the existing CSE driver, change the parser for the CSE7759B stream, and build a custom OpenBeken image. The thread’s maintainer points directly to drv_cse7766.c, says online builds can compile it without a full toolchain, and later advises creating a new driver file by copying most of the existing CSE code. For this EARU meter, the first change should be packet detection, because users captured 0x55 0x5B headers instead of 0x55 0x5A. After that, recheck 24-byte framing, checksum logic, and field extraction math. [#21177187]