It looks to me like you drew the diodes the wrong way around in your schematic? You need the TX pin to be able to pull the shared line down...
Are you relying on the internal pull-up for the RX pin on the ESP32? I would hook up something like a 2.2K-4.7K external pull up with so many diodes connected.
Also, why the 10K in the 5V supply path? Isn't that asking for trouble when there are current spikes?
Thanks tve,
you are right 
, I placed the diodes the wrong way round yesterday, I will correct the diagram later.
Today I have the ESP32 running at stabilised 5V.
IO2 and IO4 are set to default. I did not use the internal resistors.
I will think about your suggestion with a smaller resistor and throw the entire path into my calculator.
In this article, I see that they use a single cat cable to connect multiple CT clamps.
Which means one CT clamp per nested pair, which would result in something like this:
Cheers Bart, that article clarified for me how the CT's dealt with the voltage drop over such a long cable.
The reason that it didn't work in that example was that it was incorrectly wired.
IMO, a level shifter is the simplest & most reliable way to go, and if wired correctly I cannot see any reason why it would not work.
Level shifters are not expensive, so probably worth selecting one that can handle the data speed of the circuit, maybe from a reputable supplier who has a datasheet.
The only concern would be data collisions from each of the PZEM's, or do they only TX when data is requested to each of the PZEM's asynchronously?
Using diode forward voltage drop to reduce the signal voltage is a hack, which may work... but then it also depends upon the current flowing through it to create the differential in voltage between anode & cathode to overcome the diode's forward voltage, so you may need additional circuitry to 'tune' the process. It can get messy very quickly 
I had a similar problem a year ago, using diode forward voltage drop, and I found that it didn't work reliably, so I replaced it with a voltage divider (which has worked fine since), but if I were to redo it, I would always use a level shifter.
Hey Paul,
You have my attention again 
Could you please explain what was wrong in their circuit?
That is a good question. But don't know...
Because although there's a 3V connection to the low voltage side (LV pin) of the level shifter, there isn't a 5V supply to the high voltage side (HV pin), therefore it won't work.
EDIT - See Bi-Directional Logic Level Converter Hookup Guide - SparkFun Learn
Nice catch Paul!!
No expert but I believe the diodes are to isolate the PZEMS from each other.
I would test this for you but I can only find 1 spare PZEM at home.
If you have the kit I would set it up on a bench and do some tests.
That's what I would also do, and just start with 1 PZEM at first, before adding others.
I was also wondering if the TX from 1 PZEM would be pulled to ground by the others which are wired in parallel, in which case diodes would definitely be needed as well as a level shifter.
TBH, Ali Express schottky diodes cost next to nothing, and may be worth adding some just to be absolutely sure.
Something like this??
[EDIT-] Circuit diagram updated 18/12/22
ESP RX should go to PZEM TX
Yes, I was showing the labels as where they had come from, not where they were going to (for easy tracing through the circuit). So the TX (LV1) on the level shifter should be connected to RX on the ESP, and RX (LV2) to TX on the ESP.
But yes, maybe confusing 
EDIT - schematic updated to be clearer
Fair point just depends how you think about it
To me the wire going away from LV1 is connecting to ESP RX.
I always have to check when someone says "Normally Open" ie what is normal
Haha, fair point.
I've made it clearer in the schematic above.
Paul, the diodes in your circuit are the wrong way around. You need an AND circuit: the input to the level shifter (and the esp32) should only be high if all the outputs of all PZEM's are high. So any PZEM can pull the line low. To do that, the current needs to flow from the level shifter into the PZEM, hence the "arrow" of the diode needs to be the other way around.
The reason is that the serial protocol line is high when idle. So when all PZEMs are idle they all output a high level. When any starts transmitting it starts with a start bit, which is low.
The final piece you need is a pull-up resistor between all the diodes and the level shifter, The PZEMs can't pull the line high (that's the purpose of the diodes), so you need a resistor to do the trick. I would start in the 4.7k range, but it's gonna depend a bit on baud rate, diodes, PZEM output drive...
Aah OK. Thanks Thorston. The difficulty we have is that neither Bart or myself possess, or are familiar with the PZEM's, and I made the assumption that the line would be low when idle, backed up by some of the other circuit examples being quoted by other users.
So in that case, yes, I need to update my circuit, and I also agree that if the diodes are reversed, then a pull up would be necessary.
[EDIT-] Circuit now updated in post above
OK, so now if that circuit works, you can get rid of the level shifter...
On the ESP-TX -> PZEM-RX path no shifter is necessary 'cause the ESP produces the signal and it's plenty sufficient to be recognized by the PZEM.
On the PZEM-TX -> ESP-RX path you can connect the pull-up to 3.3V instead of 5V. There will be some leakage through the diodes but between the ESP pins being pretty 5V resistant and the resistor to 3.3V it's hard to imagine a problem, e.g., there's no way for milliamps to flow into the ESP pin to potentially cause havoc.
(Of course, 'til someone puts it all together and does some tests & measurements all this is hot air...)
I have some pzem on order, so will try this out when/if they get here
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarksā¢ or registeredĀ® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
