mandulaj/PZEM-004T-v30

Direction of energy

ruimiguelsa opened this issue · 29 comments

Hello all, in PZEM-004Tv3.0 version, how do we can see the direction of energy? In the older version the IC have a output that indicate the direction of energy ... like this article [https://github.com/apreb/eNode ].... it's possible in the new V3.0 version?

I see what you mean... Huh, I have not thought of this, but reading and deciphering the datasheet, I can't find anything about this feature. Will have a look. Thanks

Reading the datasheet multiple times, I have found nothing about this feature. As we are talking about AC, the current moves back and fourth. In order to determine the direction of power, one would have to determine the phase angle between the voltage and current. However this chip does not appear to have this ability. Perhaps if you modify the firmware, but that is beyond my skills.

I am going to close this as I suspect that this isn't possible 😞

Hi sorry for replying to a closed issue but I think there is a way around is....
Consider Registers

0x1005 Raw waveform of voltage
0x100A Raw waveform of Current I1

With this 32bit data, you can see if the current and voltage are out of phase by 90degrees or not.

Also Registers:
0x10F0 is the Positive active energy accumulator
0x10F1 is the Negative active energy accumulator

I have not tested yet to see if I can see the info...but I thought you might want to consider it?

Hey @milGus, Thanks for your reply! I am intrigued by this information. I was unable to find any information about these registers in the basic PZEM datasheets but if this works, it could change everything! Could you let me know where you have obtained this information? Perhaps attach the specific datasheet.

But even so this has helped a lot! Googling for the 0x10F0 i found this forum https://forum-photovoltaique.fr/viewtopic.php?t=41777&start=40 I will have a look into it.

Researching a bit, I don't think we can read those registers through the modbus protocol. The registers are defined in the power meter ic datasheet. Maybe the PZEM has an extra microcontroller to implement the "simplified" modbus protocol?

Well the V9401 is the micro controller, though a very simple one. So unless we can get access to the firmware running on it an perhaps tweak it, or if there is some kind of back door to read these high registers with modbus, we are out of luck.

It may be possible peacefair have put this info into holding registers 0x03 for that...I need to do poll on more registers to see what it gives back....So far they are using 0x04 input registers only...according to their documentation.

Have you tried accessing beyond the 0x0009 offset?

ok I've scanned and for 0x03, offset 1 to 10 I get:
image

and for 0x04 offset 1 to 7 I get:
image

I suspect you can write to the holding registers values like baudrate alarm etc..
I wonder what offet 3 and 1 are? They have a value 1...

Any ideas?

Have you tried accessing beyond the 0x0009 offset?

I have not, since the pandemic started I am cut off from my PZEMs so can't do testing of my own... I have ordered new ones from AliExpress, but they still have not arrived.

Try reversing the wire in the current transformer to simulate current flowing in opposite direction if that changes anything....

I would love to see this done! Maybe the PZEM engineers can help, since it would be an extra selling point

It would appear that unless we can find out how to flash new firmware for the onboard 8052 MCU, the basic modbus RTU firmware they got isnt going to give us full access to the registers we desire out of the chip...a shame really.

One thing I will test as soon as I can is to try to connect the JTAG circuit on the chip and pull down the firmware. Perhaps it can be modified?

To do this the chip needs to be put into "MODE1" by pulling pin 6 LOW on startup.

Then JTAG will work as follows:

Pin 7 TDO
Pin 8 TDI
Pin 9 TMS
Pin 10 TCK
Pin 19 RESET
Pin 23 VDD
Pin 12 VSS

Any updates on this?

Not as yet.

That feature is the most important one that users want why so many time to implement?

Hey @marine1988 As was said before, this would require to flash a new firmware onto the PZEM chips. This is far beyond the scope of this library.

Screenshot_20220126-205601
Could the solution be as simple as this? Use 2 PZEM pr. phase at the correct measuring points. See drawing.

@knas4ever yes sure but that means now we need two UARTs or some sort of UART enumerator....

Just think it will solve the problems people have with PV production in a practical easy way. Is the way I will setup my system when I get my remaining PZEM's 🙂 then setup sensor templates to calculate the net power usage in Home Assistant.

@milGus, not sure what you mean that you would need two UARTs? The entire joke with the PZEMs is that they use ModBus to communicate and can have independent addresses. Meaning they can all use the same UART.

As for @knas4ever, yes you could do this provided that you can get at the correct wires in the house wiring. For the solar people, this approximation could work but it is not a true energy direction measurement. Though the distributors almost always charge and pay you by the real power so who cares about the VA. Only the nerds...

Hy! Can I read these registers somehow? ^_^

"10.13.1. Energy Accumulation

In E1 path, positive and negative active powers are accumulated into the energy accumulators according to their signs; for example, positive active power is accumulated into PPCNT (0x10F0), and negative active power is accumulated into NPCNT (0x10F1). Besides, other data, such as I1 current RMS or a constant (preset in the register DATACP, 0x10FC), also can be selected to be accumulated into PPCNT via configuring bits PSEL1~PSEL0 (bit[1:0] of PMCtrl4, 0x287D) when the chip is used for low power applications.

In E2 path, positive and negative active/reactive powers are accumulated into the energy accumulators according to their signs; for example, positive power is accumulated into PQCNT (0x10F6), and negative power is accumulated into NQCNT (0x10F7)." - Page 119

Hey @amiazma, Can I ask which datasheet you are referring to?

I see, well I remember looking into it a while back and concluded that the firmware, that comes on the chips from the manufacturer, does not for some reason expose these registers over the ModBus interface. @milGus scanned some higher addresses where he found some interesting values, but to my knowledge, we haven't yet reverse-engineered what they correspond to. It's possible that there are some undocumented addresses, through which the firmware exposes the internal accumulation registers. But unfortunately, I have been quite busy lately and couldn't look further into it.

@amiazma you are welcome to run your own modbus scan but Ive provided the details of my scan above. I tried writing into and reading from the registers in the datasheet but yeah as @mandulaj says the manufacturer has an abstraction layer that only exposes certain registers. You are welcome to try to reprogram the chip firmware to expose more registers. That could work....

@milGus I programmed before "simple" esp32 things, but this kind of register scan programming thing new to me. 😄 Can you share your code for reading and writing registers? From @mandulaj 's code I will tring to cut the relevant part, but I like your output, and this way it could be faster for me. I will search UART keywords then in the documentation. Thans both of you!

Im not sure this is the best forum for it. But you can try from https://freemodbus.com/index.html and use this as a guide: https://www.youtube.com/watch?v=WVKulzrpaiM

I readed the pdf while searched with the "UART" keyword without success. Then I tried your two registers. The 0x04xx a register for programming. Page 51. The text suggest programs for this chip, and help you to enter Mode1. It says you can read out the program, and there is an - I think - Assembler arithmetic sheet.

"In V98XX, the on-chip Flash memory is divided into 256 pages with 512 bytes each. The codes in the Flash memory can be read, erased, or programmed in pages or mass erased. Notes: The third page of the Flash memory, at addresses “0400h” ~ “05FFh”, is pre-programmed with codes by the manufacturer, so this part cannot be used for application codes. When the low logic level is input on the pin “MODE1”, the chip will be in the debugging mode. In this mode, the 4 pins of Group P0 work as JTAG interfaces. Users can use the DLL codes and simulators provided by Vango to download and debug the applications in Keil μVision IDE or IAR IDE via the JTAG interfaces."

I dont really understand, because I never done someting like this. I hope somehow we can read out the 0x10F6 0x10F7 registers with this then! :D

@amiazma
I tried accessing the IC using UrJTAG on my Raspberry Pi 4.
I desoldered R5, and pulled MODE1 (pin 7) to ground using a 10k resistor to enable debug mode.
I wired VDD5 (pin 23) to the 3.3V source on my Pi to avoid having to attach my Pi to mains voltage.
I then powered it all on and tried to use the GPIO of my Pi in UrJTAG, with no success.
UrJTAG could not detect the IC at all.
I am not certain whether this is simply a bad connection somewhere, or if it has something to do with the Encryption bit:

There is an encryption bit (“bit0” of byte located at address “0x0400”) in the Flash memory. The
configuration of this bit has effect on the access to the Flash memory. When the high logic level is input on
the pin “MODE1”, the chip will be in the metering mode. In this mode, the on-chip Flash memory is IAP
supportive, and the access to the Flash memory will not be affected by the encryption bit configuration.
When the low logic level is input on the pin “MODE1”, the chip will be in the metering mode. In this mode,
the on-chip Flash memory is IAP and ISP supportive, and the encryption bit configuration will affect the
access to the Flash memory.

I am only curious about this as I am trying to create a custom PCB around this IC, and it would save me a lot of time to simply clone the ROM of the PZEM's IC instead of writing firmware from scratch.

I am afraid we are out of luck when it comes to modifying the firmware of the PZEM.