After update 6.6.0.12 the PZEM004T no value is shown. #6585

wongnam · 2019-10-07T10:56:16Z

BUG DESCRIPTION

After update 6.6.0.15-2.5.2 the PZEM004T no value is shown.

Read the Contributing Guide and Policy and the Code of Conduct
Searched the problem in issues
Searched the problem in the wiki
Searched the problem in the forum
Searched the problem in the chat
Device used (e.g., Sonoff Basic): WEMOS D1 Mini/PZEM004T-V2.0
Tasmota binary firmware version number used: 6.6.0.15 Core2.5.2
- Pre-compiled
- Self-compiled
  - IDE / Compiler used: VSC/PlatformIO-IDE
Flashing tools used: OTA URL http://thehackbox.org/tasmota/release/sonoff.bin

Provide the output of command: Backlog Template; Module; GPIO:

Configuration output here: {"NAME":"Energy","GPIO":[17,62,52,63,255,255,255,255,29,255,255,255,255],"FLAG":15,"BASE":18}

If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:
```
Rules output here:
```
Provide the output of this command: Status 0:

12:00:59 CMD: status 0
12:00:59 SRC: WebConsole from 192.168.12.125
12:00:59 CMD: Group 0, Index 1, Command "STATUS", Data "0"
12:00:59 MQT: stat/emonitor/STATUS = {"Status":{"Module":0,"FriendlyName":["Energy Monitor"],"Topic":"emonitor","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
12:00:59 MQT: stat/emonitor/STATUS1 = {"StatusPRM":{"Baudrate":9600,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T00:11:53","StartupUTC":"2019-10-07T10:49:06","Sleep":50,"CfgHolder":4617,"BootCount":10,"SaveCount":27,"SaveAddress":"F9000"}}
12:00:59 MQT: stat/emonitor/STATUS2 = {"StatusFWR":{"Version":"6.6.0.15(48ec64c-sonoff)","BuildDateTime":"2019-10-07T12:06:27","Boot":31,"Core":"2_5_2","SDK":"2.2.2-dev(c0eb301)"}}
12:00:59 MQT: stat/emonitor/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":4,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["iot-2","Wong"],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","280500000100060000005A64000000000000","00000000"]}}
12:00:59 MQT: stat/emonitor/STATUS4 = {"StatusMEM":{"ProgramSize":564,"Free":436,"Heap":24,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"164020","FlashMode":3,"Features":["00000809","8FDAE397","043683A0","22B617CD","01001BC0","00000081"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24","Sensors":"1,2,3,4,5,6,7,8,9,10,14,15,17,18,20,22,26,34"}}
12:00:59 MQT: stat/emonitor/STATUS5 = {"StatusNET":{"Hostname":"emonitor-0307","IPAddress":"192.168.12.103","Gateway":"192.168.12.1","Subnetmask":"255.255.255.0","DNSServer":"210.245.31.220","Mac":"DC:4F:22:58:41:33","Webserver":2,"WifiConfig":4}}
12:00:59 MQT: stat/emonitor/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.12.155","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_584133","MqttUser":"admin","MqttCount":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":30}}
12:00:59 MQT: stat/emonitor/STATUS7 = {"StatusTIM":{"UTC":"Mon Oct 07 11:00:59 2019","Local":"Mon Oct 07 12:00:59 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+01:00","Sunrise":"06:58","Sunset":"18:17"}}
12:00:59 MQT: stat/emonitor/STATUS9 = {"StatusPTH":{"PowerDelta":0,"PowerLow":0,"PowerHigh":0,"VoltageLow":0,"VoltageHigh":0,"CurrentLow":0,"CurrentHigh":0}}
12:00:59 MQT: stat/emonitor/STATUS10 = {"StatusSNS":{"Time":"2019-10-07T12:00:59","ENERGY":{"TotalStartTime":"2019-10-07T11:34:49","Total":0.608,"Yesterday":0.000,"Today":0.608,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.000}}}
12:00:59 MQT: stat/emonitor/STATUS11 = {"StatusSTS":{"Time":"2019-10-07T12:00:59","Uptime":"0T00:11:53","UptimeSec":713,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"ON","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":62,"LinkCount":1,"Downtime":"0T00:00:08"}}}

- [ ] Provide the output of the Console log output when you experience your issue; if applicable:
_(Please use_ ``weblog 4`` _for more debug information)_

Console output here:


### TO REPRODUCE
_Steps to reproduce the behavior:_
Flash a pre-compiled dev_latest sonoff.bin FW 6.6.0.15 2.5.2 or Stage

### EXPECTED BEHAVIOUR
It has to function as it should be.


### SCREENSHOTS
![image](https://user-images.githubusercontent.com/36041520/66306394-b6211e00-e92b-11e9-8fdb-08489aaf2ad9.png)

The text was updated successfully, but these errors were encountered:

wongnam · 2019-10-07T14:02:23Z

Please note that the problem occurred after I updated from 6.6.0.6 to 6.6.0.15, I hope this information can narrow the problem window for you.

pablozg · 2019-10-07T15:39:00Z

There are a lot changes since 6.6.0.6, try do a 'reset 2' or 'reset 3' command to set firmware defaults and configure again the device.

Jason2866 · 2019-10-07T15:47:54Z

Cant confirm. Compiled latest development version with LCD support (exactly as https://github.com/arendst/Sonoff-Tasmota/wiki/PZEM004T,-Wemos-D1-Mini-and-a-1602-I2C-display)
and i do get all values

Jason2866 · 2019-10-07T15:51:00Z

btw, dont use 2.5.2 anymore. It has a big known bug. Memory Manager is not in iRam.
This causes now and than exceptions.
Use core pre 2.6. MANY bugs fixed! It is the most reliable core for Tasmota

arendst · 2019-10-07T16:00:42Z

@Jason2866 do you use hardware or software serial?

Jason2866 · 2019-10-07T16:05:49Z

hardware serial

arendst · 2019-10-07T16:10:41Z

Thought so. I suspect a software serial issue. Haven't time to investigate now.

s-hadinger · 2019-10-07T17:36:24Z

Argh. Software Serial biting again.

Aren't there any logs of received data?

wongnam · 2019-10-07T17:46:42Z

No signal log receive yet.

00:44:45 CMD: weblog 4
00:44:45 MQT: stat/emonitor/RESULT = {"WebLog":4}
00:44:46 CFG: Saved to flash at F7, Count 13, Bytes 4096
00:44:48 MQT: tele/emonitor/STATE = {"Time":"2019-10-08T00:44:48","Uptime":"0T00:01:18","UptimeSec":78,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":22,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":50,"LinkCount":1,"Downtime":"0T00:00:08"}}
00:44:48 MQT: tele/emonitor/SENSOR = {"Time":"2019-10-08T00:44:48","ENERGY":{"TotalStartTime":"2019-10-08T00:40:59","Total":0.000,"Yesterday":0.000,"Today":0.000,"Period":0,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.000}}
00:44:58 MQT: tele/emonitor/STATE = {"Time":"2019-10-08T00:44:58","Uptime":"0T00:01:28","UptimeSec":88,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":44,"LinkCount":1,"Downtime":"0T00:00:08"}}
00:44:58 MQT: tele/emonitor/SENSOR = {"Time":"2019-10-08T00:44:58","ENERGY":{"TotalStartTime":"2019-10-08T00:40:59","Total":0.000,"Yesterday":0.000,"Today":0.000,"Period":0,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.000}}
00:44:58 WIF: Checking connection...
00:44:58 WIF: Connected
00:45:08 MQT: tele/emonitor/STATE = {"Time":"2019-10-08T00:45:08","Uptime":"0T00:01:38","UptimeSec":98,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":44,"LinkCount":1,"Downtime":"0T00:00:08"}}
00:45:08 MQT: tele/emonitor/SENSOR = {"Time":"2019-10-08T00:45:08","ENERGY":{"TotalStartTime":"2019-10-08T00:40:59","Total":0.000,"Yesterday":0.000,"Today":0.000,"Period":0,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.000}}

wongnam · 2019-10-07T17:50:26Z

BTW. how do i switch it to hard serial?

Jason2866 · 2019-10-07T17:54:34Z

Connect gpio 1 and 3 and use
{"NAME":"PZEM004TV3","GPIO":[0,62,0,98,6,5,0,0,0,0,0,0,0],"FLAG":0,"BASE":1}

wongnam · 2019-10-07T17:58:39Z

I used the same configuration like your template except I used a PZEM004T V2.

Jason2866 · 2019-10-07T18:00:53Z

If you restart Tasmota writes a message when hardware serial is used at the beginning in the console
So your config is
{"NAME":"PZEM004","GPIO":[0,62,0,63,6,5,0,0,0,0,0,0,0],"FLAG":0,"BASE":1}

wongnam · 2019-10-07T18:18:58Z

version 6.6.0.15-2.5.2

go back to version 6.6.0.6-2.5.2

Jason2866 · 2019-10-07T18:28:51Z

@s-hadinger and @arendst So it is not a software serial issue!
Difference is version of modul
@wongnam could you try core pre 2.6 too?

arendst · 2019-10-07T19:59:38Z

Did some investigation and indeed I do not think it's serial related.

There were changes in the PZEM004T driver to accomodate three of them connected in serial. In addition the address of the PZEM004T device changed from bogus IP address 192.168.1.1 to 0.0.01

As far as I know only the last octet is used by the PZEM004T software so it should still read a 1 and work.

Since the change I only had positive reactions by people using one or three PZEM004T's. I was unable to test this on my PZEM004T as the esp8266 currently refuses to connect to my network.

Anyway, this address is written to the device at power on or restart of the esp8266 only once. It may be this writing fails.

HOLD ON. While scanning the code it seems this address writing doesn't work as before. You must do it yourself by executing command ModuleAddress 1 only once. This was introduced to make it possible for users to connect three devices with three different addresse.

How could I forget....

arendst · 2019-10-07T21:09:09Z

SUCCESS!!!

I just replaced my esp8266 with a new one and verified the PZEM004T worked fine on v6.5.0.2

Then upgraded to 6.6.0.15 and indeed the PZEM004 is gone. After executing command ModuleAddress 1 it all works again.

This behaviour is expected since version 6.6.0.12 where up to three PZEM004T's are supported on one serial channel.

So this is certainly a big note once the new version is released. Thx for testing.

wongnam · 2019-10-08T03:44:08Z

the first time:

6.6.0.15 Follow your advised and apply ModuleAdress 1 -> success.

the second time: (replicated)

reset 2, to erase all setting to default
apply template {"NAME":"PZEM004","GPIO":[0,62,0,63,6,5,0,0,0,0,0,0,0],"FLAG":0,"BASE":1}
apply ModuleAddress 1-> MQT: stat/sonoff/RESULT = {"Command":"Error"}
not success

00:00:00 CFG: Loaded from flash at F6, Count 6
00:00:00 Project sonoff Sonoff Version 6.6.0.15(sonoff)-STAGE
00:00:00 SNS: Hardware Serial
00:00:00 WIF: Connecting to AP1 iot-2 in mode 11N as sonoff-0307...
00:00:08 WIF: Connected
00:00:08 HTP: Web server active on sonoff-0307 with IP address 192.168.12.103
10:34:01 RSL: tele/sonoff/STATE = {"Time":"2019-10-08T10:34:01","Uptime":"0T00:00:09","UptimeSec":9,"Heap":30,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":56,"LinkCount":1,"Downtime":"0T00:00:08"}}
10:34:01 RSL: tele/sonoff/SENSOR = {"Time":"2019-10-08T10:34:01","ENERGY":{"TotalStartTime":"2019-10-08T10:32:57","Total":0.401,"Yesterday":0.000,"Today":0.401,"Period":0,"Power":[0,0],"ApparentPower":[0,0],"ReactivePower":[0,0],"Factor":[0.00,0.00],"Voltage":[0,0],"Current":[0.000,0.000]}}
10:34:02 MQT: Attempting connection...
10:34:02 MQT: Connected
10:34:02 MQT: tele/sonoff/LWT = Online (retained)
10:34:02 MQT: cmnd/sonoff/POWER = 
10:34:02 MQT: tele/sonoff/INFO1 = {"Module":"PZEM004","Version":"6.6.0.15(sonoff)","FallbackTopic":"cmnd/DVES_584133_fb/","GroupTopic":"sonoffs"}
10:34:02 MQT: tele/sonoff/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff-0307","IPAddress":"192.168.12.103"}
10:34:02 MQT: tele/sonoff/INFO3 = {"RestartReason":"Software/System restart"}
10:34:02 MQT: stat/sonoff/RESULT = {"POWER":"OFF"}
10:34:02 MQT: stat/sonoff/POWER = OFF
10:34:10 MQT: tele/sonoff/STATE = {"Time":"2019-10-08T10:34:10","Uptime":"0T00:00:18","UptimeSec":18,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":54,"LinkCount":1,"Downtime":"0T00:00:08"}}
10:34:10 MQT: tele/sonoff/SENSOR = {"Time":"2019-10-08T10:34:10","ENERGY":{"TotalStartTime":"2019-10-08T10:32:57","Total":0.401,"Yesterday":0.000,"Today":0.401,"Period":0,"Power":[0,0],"ApparentPower":[0,0],"ReactivePower":[0,0],"Factor":[0.00,0.00],"Voltage":[0,0],"Current":[0.000,0.000]}}
10:34:11 MQT: stat/sonoff/RESULT = {"POWER":"ON"}
10:34:11 MQT: stat/sonoff/POWER = ON
10:34:12 MQT: stat/sonoff/RESULT = {"POWER":"OFF"}
10:34:12 MQT: stat/sonoff/POWER = OFF
10:34:19 CMD: ModuleAddress 1
10:34:19 MQT: stat/sonoff/RESULT = {"Command":"Error"}
10:34:20 MQT: tele/sonoff/STATE = {"Time":"2019-10-08T10:34:20","Uptime":"0T00:00:28","UptimeSec":28,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":20,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":56,"LinkCount":1,"Downtime":"0T00:00:08"}}
10:34:20 MQT: tele/sonoff/SENSOR = {"Time":"2019-10-08T10:34:20","ENERGY":{"TotalStartTime":"2019-10-08T10:32:57","Total":0.401,"Yesterday":0.000,"Today":0.401,"Period":0,"Power":[0,0],"ApparentPower":[0,0],"ReactivePower":[0,0],"Factor":[0.00,0.00],"Voltage":[0,0],"Current":[0.000,0.000]}}
10:34:30 MQT: tele/sonoff/STATE = {"Time":"2019-10-08T10:34:30","Uptime":"0T00:00:38","UptimeSec":38,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":58,"LinkCount":1,"Downtime":"0T00:00:08"}}
10:34:30 MQT: tele/sonoff/SENSOR = {"Time":"2019-10-08T10:34:30","ENERGY":{"TotalStartTime":"2019-10-08T10:32:57","Total":0.401,"Yesterday":0.000,"Today":0.401,"Period":0,"Power":[0,0],"ApparentPower":[0,0],"ReactivePower":[0,0],"Factor":[0.00,0.00],"Voltage":[0,0],"Current":[0.000,0.000]}}
10:34:40 MQT: tele/sonoff/STATE = {"Time":"2019-10-08T10:34:40","Uptime":"0T00:00:48","UptimeSec":48,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":58,"LinkCount":1,"Downtime":"0T00:00:08"}}
10:34:40 MQT: tele/sonoff/SENSOR = {"Time":"2019-10-08T10:34:40","ENERGY":{"TotalStartTime":"2019-10-08T10:32:57","Total":0.401,"Yesterday":0.000,"Today":0.401,"Period":0,"Power":[0,0],"ApparentPower":[0,0],"ReactivePower":[0,0],"Factor":[0.00,0.00],"Voltage":[0,0],"Current":[0.000,0.000]}}

weblog 4:

10:42:02 CMD: weblog 4
10:42:02 MQT: stat/sonoff/RESULT = {"WebLog":4}
10:42:03 DMP: 88 A0 00 E1 07 00 00
10:42:03 DMP: 88 A0 00 E1 07 00 00
10:42:03 CFG: Saved to flash at F9, Count 11, Bytes 4096
10:42:04 DMP: 88 A0 00 E1 07 00 00
10:42:04 DMP: 88 A0 00 E1 07 00 00
10:42:05 DMP: 88 A0 00 E1 07 00 00
10:42:05 DMP: 88 A0 00 E1 07 00 00
10:42:06 DMP: 88 A0 00 E1 07 00 00
10:42:06 DMP: 88 A0 00 E2 01 00 00
10:42:07 DMP: 83 A0 00 E2 01 00 00
10:42:07 DMP: 83 A0 00 E2 01 00 00
10:42:08 DMP: 83 A0 00 E2 01 00 00
10:42:08 DMP: 83 A0 00 E2 01 00 00
10:42:09 DMP: 83 A0 00 E2 01 00 00
10:42:09 DMP: 83 A0 00 E2 01 00 00
10:42:10 DMP: 83 A0 00 E2 01 00 00
10:42:10 MQT: tele/sonoff/STATE = {"Time":"2019-10-08T10:42:10","Uptime":"0T00:08:18","UptimeSec":498,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":27,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"70:3A:0E:39:0A:E1","Channel":6,"RSSI":54,"LinkCount":1,"Downtime":"0T00:00:08"}}
10:42:10 MQT: tele/sonoff/SENSOR = {"Time":"2019-10-08T10:42:10","ENERGY":{"TotalStartTime":"2019-10-08T10:32:57","Total":0.401,"Yesterday":0.000,"Today":0.401,"Period":0,"Power":[0,0],"ApparentPower":[0,0],"ReactivePower":[0,0],"Factor":[0.00,0.00],"Voltage":[0,0],"Current":[0.000,0.000]}}
10:42:10 DMP: 83 A0 00 E2 00 00 00
10:42:11 DMP: 82 A0 00 E2 00 00 00
10:42:11 DMP: 82 A0 00 E2 00 00 00
10:42:12 DMP: 82 A0 00 E2 00 00 00

screenshot:

the third time: (you can bring it back to working)

flash the same firmware again -> apply ModuleAddress 1-> it will works again.

the fourth time:

go back to all steps in 2nd time testing above.

arendst · 2019-10-08T07:15:40Z

The command ModuleAddress x is available when the system detects only ONE connected PZEM004T. If more are detected it is impossible to know which PZEM004T needs to receive which address. So as long as there is not only one PZEM004 found the command will report error.

During power on the software expects three connected PZEM004T with addresses 3, 2 and 1. If no valid response is detected it lowers the amount of detected PZEM004T's and tries the next one. This process is only executed at restart/power on and will take a few seconds per PZEM004T.

From your screenshot it appears it has detected two PZEM004T's and therefore the ModuleAddress command will fail.

Your weblog shows a valid response from the PZEM004T reporting voltage but it is a byte out of sync. I will need to find a way to become in sync again. This may well be the cause why you see these unexpected results.

To be continued...

wongnam · 2019-10-08T07:38:01Z

During` power on the software expects three connected PZEM004T with addresses 3, 2 and 1. If no valid response is detected it lowers the amount of detected PZEM004T's and tries the next one.

Please allow the original to act as a PZEM004T as ModuleAddress 1 to avoid affecting the current configuration of multiple user devices. If more than 1 module, assign the required address.

wongnam · 2019-10-08T07:50:22Z

I even need to permanently save the address of this module so that when it resets it is not lost.
The purpose is that I want all the settings already declared to be in fw when compiling, so that when the hardware is reset it will still run as it should without having to intervene from the beginning.
in fact my Energy monitors were working under this mechanism and it was fine until this new FW affected my idea that it no longer worked.

One last word is to allow the option to declare number of PZEM004 module in my_user_config.h or settings.ino or auto detect by scanning. Thank you.

arendst · 2019-10-08T08:58:51Z

Please allow the original to act as a PZEM004T as ModuleAddress 1 to avoid affecting the current configuration of multiple user devices. If more than 1 module, assign the required address.

I'll revert the change from address 0.0.0.x to 192.168.1.x. This will solve the issue for users coming from a previous Tasmota version. It won't solve the issue for new users as the newly connected PZEM004T most probably will not have a default address of 192.168.1.1. In those cases the users will need to connect the PZEM004T and use command ModuleAddress 1. It needs to be this way as Tasmota has no way of knowing if more PZEM004T are connected at the same time; the previous way of always writing the Tasmota address of 192.168.1.1 can no longer be used (unless I decide to make an option available where a user only allows one PZEM004T to be connected.)

I even need to permanently save the address of this module so that when it resets it is not lost.

The address is written to the PZEM004T and should be permanent. I see no info in the PZEM004T docs where it can be reset. There is not even a default address in the PZEM00T; initial connection can only be completed if the user software writes a known address to it first. Tasmota used to ise 192.168.1.1. I will reinstate this.

One last word is to allow the option to declare number of PZEM004 module in my_user_config.h or settings.ino or auto detect by scanning.

Scanning is the current functionality. It fails so I'll need to investigate.

Jason2866 · 2019-10-08T10:36:29Z

Mhh, just curios i came from a old version too. Never did command ModuleAddress 1
After first start with new version i noticed there where three columns for the values,
after a short while it reduced itself to the "one" value display.
Why did it work for me but not for wongnam?
@wongnam Have you done the serial mod with 1k resistor? I have...

* Change PZEM004T default address mask from 0.0.0.x to 192.168.1.x for legacy reason (#6585) * Fix PZEM004T, PZEMAC and PZEMDC autodetection (#6585)

arendst · 2019-10-08T11:21:06Z

After first start with new version i noticed there where three columns for the values,
after a short while it reduced itself to the "one" value display.

That's the brief period after restart where the PZEM's are being probed. Within some seconds it should stabilize to the once recognized.

Why did it work for me but not for wongnam?

I do not know. It didn't work for me either. At least with the latest fixes it should continue to use the legacy address of 192.168.1.1.

meingraham · 2019-10-08T11:52:38Z

For non-Modbus PZEM, doesn't Tasmota "know" how many are connected (or plan to be connected) by the number of Rx/Tx pairs configured so it can start the detection countdown with that number instead of starting with 3 each time? Yes, it's nice for Tasmota to detect, but if it's going to cause issues, perhaps an explicit parameter to manually set the number modules (1..3) to be connected?

arendst · 2019-10-08T11:59:21Z

Both modbus and non-modbus are using only one Tx/Rx pair as that's just what is only supported.

It should not cause issues with the latest fixes. I will see if I find a valid usecase...

wongnam · 2019-10-08T13:38:32Z

Hi @arendst It's working well now. Thank you!.

meingraham · 2019-10-12T17:06:47Z

@arendst

6.6.0.18
For non-Modbus PZEM-004T, is the address syntax just ModuleAddress 1?

arendst · 2019-10-12T17:39:42Z

Correct. Only 1, 2 or 3 are supported.

This results in fake addresses 192.168.1.1, .2 and .3

amagr0 · 2019-10-19T23:17:01Z

Hello,

I'm having troublems connecting PZEM-004T(v2.0) to a D1mini with Tasmota 6.6.0 (2.5.3).
Where can I find the Tasmota realease 6.6.0.18?

Thanks

ascillato · 2019-10-19T23:40:23Z

http://thehackbox.org/tasmota/sonoff.bin

amagr0 · 2019-10-20T14:12:58Z

Thanks @ascillato.

I already flashed D1mini with the 6.6.0.20, but unfortunatly I'm still having problems.
There's a lot of diferents configurations (electrical and Tasmota Config Module) through the web, and I already tried most of them without success.
Following the configuration discussed in this post and with the Tasmota 6.6.0.20 I'm still not getting data from PZEM004T.

I don't know if the problem is with the physical connection between D1mini and PZEM004T.
The following commands are retreving:

14:55:45 CMD: ModuleAddress 1
14:55:45 RSL: stat/sonoff/RESULT = {"ModuleAddress":"Done"}

14:54:15 CMD: I2CScan
14:54:15 RSL: stat/sonoff/RESULT = {"I2CScan":"No devices found"}

Is this the expected result for the I2CScan command?

Btw, I already tried with 3 different PZEM-004T boards (these boards are getting 5V from external source).

Thanks

wongnam · 2019-10-20T14:17:19Z

PZEM004T is using serial to communication, not I2C.
If your issue is compilation problem, please address it to the Tasmota Support Chat

amagr0 · 2019-10-20T14:40:42Z

Hello @wongnam.

Thanks for your reply, I did not have problems flashing the 6.6.020 version, so I think the problem is not related with the compilation.

What type of logs could I check to see if everything is alright?
And how can I confirm that the connection with PZEM is also alright?

Thanks

wongnam · 2019-10-20T15:05:19Z

if you have read through in this article that you will see this info https://github.com/arendst/Sonoff-Tasmota/wiki/PZEM004T,-Wemos-D1-Mini-and-a-1602-I2C-display

amagr0 · 2019-10-20T19:03:15Z

Hello @wongnam,

I connected PZEM-004T to an Arduino and with the PZEM library I could get data from the PZEM board, so, the board is ok, and the connections too.

This was the steps that I made with Tasmota:

Download Tasmota 6.6.0.20 release
Flash D1mini with NodeMCU-PyFlasher
Config D1mini Wifi parameters
Define template: {"NAME":"HW-655 PZEM","GPIO":[0,63,0,62,6,5,0,0,0,0,0,0,0],"FLAG":0,"BASE":18}
Apply command: ModuleAddress 1

And again, no data from PZEM-004T.
What should I do next?

Thanks

wongnam · 2019-10-21T00:39:05Z

It seems that you haven't followed the instructions in the wiki yet, I see that your template parameters(TX, RX) are completely different from the instructions. Please double check the parameters and wiring.
By the way, if you are facing any more issues, please go through the Tamota support chat https://discord.gg/Ks2Kzd4 because this thread is closed. Thank you.

amagr0 · 2019-10-21T19:21:44Z

Hello @wongnam

I don't understand how my template parameters are completely different from the instructions, I simply did a copy and paste, the parameters are the same as you can see:

My parameters

Template parameters

I also already tried every possible combinations with this template, and manually configurated the ports in Module Configuration and also tried all combinations.

For every configuration I also changed the physical connections (TX and RX) in PZEM004T.

Sorry to bother you again, but this is upseting me a lot.
I'm configurating a home-assistant setup, with switchs and sensors with D1m1 and NodeMCU boards, everything is alright (I used ESPHome firmware), and I'd like to do some energy monitoring with 4 PZEM004T, and I'm complety blocked with this.

I also already tried with 3 other PZEM, and other ESP boards, always wihout success.
Only in an Arduino I could get data from PZEM board.

If you could help again, I would highly appreciate it.

Thanks.

amagr0 · 2019-10-25T21:35:51Z

My issue was related with the external 5V and GND.
I mod the PZEM in the 1K ohm, and connected directly to the D1mini.

rotarucosminleonard · 2022-03-13T00:49:29Z

I am also having problems with the Pzem-004t 100A V3 hardware on esp32. I have it connected to the hardware pins, but PZEM simply does not respond to it. Blank data, and the TX led of the PZEM does not blink, only the RX. If I change the RX pin with PZEM17 instead of PZEM04, it starts responding, but obviously, the values are messed up.

AlfaBravoX · 2022-05-25T20:29:10Z

I am also having problems with the Pzem-004t 100A V3 hardware on esp32. I have it connected to the hardware pins, but PZEM simply does not respond to it. Blank data, and the TX led of the PZEM does not blink, only the RX. If I change the RX pin with PZEM17 instead of PZEM04, it starts responding, but obviously, the values are messed up.

I am not sure why, but try to include i2c definitions as well(even it is not i2c sensor) like this:

vsaravind007 · 2023-01-10T17:08:51Z

I am also having problems with the Pzem-004t 100A V3 hardware on esp32. I have it connected to the hardware pins, but PZEM simply does not respond to it. Blank data, and the TX led of the PZEM does not blink, only the RX. If I change the RX pin with PZEM17 instead of PZEM04, it starts responding, but obviously, the values are messed up.

Have you fixed the issue @rotarucosminleonard ? Having the same problem and pulling my hairs out now!

@AlfaBravoX's solution didn't work as well!

Leapo · 2023-08-24T20:13:29Z

I am also having problems with the Pzem-004t 100A V3 hardware on esp32. I have it connected to the hardware pins, but PZEM simply does not respond to it. Blank data, and the TX led of the PZEM does not blink, only the RX. If I change the RX pin with PZEM17 instead of PZEM04, it starts responding, but obviously, the values are messed up.

Yup, seeing exactly the same issue here on Tasmota 13.1.0.1. Has any solution for this been found?

Edit: I think I figured it out. Set your TX pin to "PZEM0XX TX" and your RX pin to "PZEM016 RX", and everything works perfectly with PZEM004 sensors.

jeromefischer · 2023-12-20T21:58:24Z

@Leapo this was the solution for my setup, too. I am using an NodeMCU ESP8266 with a PZEM-004T-100A and had set the following configuration:

ascillato2 added the troubleshooting Type - Troubleshooting label Oct 7, 2019

arendst added the fixed Result - The work on the issue has ended label Oct 7, 2019

arendst changed the title ~~After update 6.6.0.15-2.5.2 the PZEM004T no value is shown.~~ After update 6.6.0.12 the PZEM004T no value is shown. Oct 7, 2019

ascillato2 added the add to wiki label Oct 7, 2019

arendst added a commit that referenced this issue Oct 8, 2019

Fix PZEM default address and detection

6d31608

* Change PZEM004T default address mask from 0.0.0.x to 192.168.1.x for legacy reason (#6585) * Fix PZEM004T, PZEMAC and PZEMDC autodetection (#6585)

wongnam closed this as completed Oct 8, 2019

pablozg mentioned this issue Oct 10, 2019

Cannot reset Energy Today/Total for external meter #6561

Closed

12 tasks

localhost61 mentioned this issue Oct 10, 2019

Adding support for PZEM004T energy monitor for 3 phase - request #2315

Closed

Jason2866 mentioned this issue Oct 25, 2019

Tasmota 6.7.0 - PZEM-004T (v2) - only received Voltage data #6746

Closed

After update 6.6.0.12 the PZEM004T no value is shown. #6585

After update 6.6.0.12 the PZEM004T no value is shown. #6585

Comments

wongnam commented Oct 7, 2019 • edited Loading

BUG DESCRIPTION

wongnam commented Oct 7, 2019

pablozg commented Oct 7, 2019

Jason2866 commented Oct 7, 2019

Jason2866 commented Oct 7, 2019

arendst commented Oct 7, 2019

Jason2866 commented Oct 7, 2019

arendst commented Oct 7, 2019

s-hadinger commented Oct 7, 2019

wongnam commented Oct 7, 2019

wongnam commented Oct 7, 2019

Jason2866 commented Oct 7, 2019

wongnam commented Oct 7, 2019

Jason2866 commented Oct 7, 2019 • edited Loading

wongnam commented Oct 7, 2019

version 6.6.0.15-2.5.2

go back to version 6.6.0.6-2.5.2

Jason2866 commented Oct 7, 2019 • edited Loading

arendst commented Oct 7, 2019 • edited Loading

arendst commented Oct 7, 2019 • edited Loading

wongnam commented Oct 8, 2019 • edited Loading

the first time:

the second time: (replicated)

weblog 4:

screenshot:

the third time: (you can bring it back to working)

the fourth time:

arendst commented Oct 8, 2019

wongnam commented Oct 8, 2019 • edited Loading

wongnam commented Oct 8, 2019 • edited Loading

arendst commented Oct 8, 2019

Jason2866 commented Oct 8, 2019 • edited Loading

arendst commented Oct 8, 2019

meingraham commented Oct 8, 2019

arendst commented Oct 8, 2019 • edited Loading

wongnam commented Oct 8, 2019

meingraham commented Oct 12, 2019 • edited Loading

arendst commented Oct 12, 2019

amagr0 commented Oct 19, 2019

ascillato commented Oct 19, 2019

amagr0 commented Oct 20, 2019

wongnam commented Oct 20, 2019

amagr0 commented Oct 20, 2019 • edited Loading

wongnam commented Oct 20, 2019 • edited Loading

amagr0 commented Oct 20, 2019 • edited Loading

wongnam commented Oct 21, 2019 • edited Loading

amagr0 commented Oct 21, 2019

amagr0 commented Oct 25, 2019

rotarucosminleonard commented Mar 13, 2022

AlfaBravoX commented May 25, 2022 • edited Loading

vsaravind007 commented Jan 10, 2023

Leapo commented Aug 24, 2023 • edited Loading

jeromefischer commented Dec 20, 2023

wongnam commented Oct 7, 2019 •

edited

Loading

Jason2866 commented Oct 7, 2019 •

edited

Loading

Jason2866 commented Oct 7, 2019 •

edited

Loading

arendst commented Oct 7, 2019 •

edited

Loading

arendst commented Oct 7, 2019 •

edited

Loading

wongnam commented Oct 8, 2019 •

edited

Loading

wongnam commented Oct 8, 2019 •

edited

Loading

wongnam commented Oct 8, 2019 •

edited

Loading

Jason2866 commented Oct 8, 2019 •

edited

Loading

arendst commented Oct 8, 2019 •

edited

Loading

meingraham commented Oct 12, 2019 •

edited

Loading

amagr0 commented Oct 20, 2019 •

edited

Loading

wongnam commented Oct 20, 2019 •

edited

Loading

amagr0 commented Oct 20, 2019 •

edited

Loading

wongnam commented Oct 21, 2019 •

edited

Loading

AlfaBravoX commented May 25, 2022 •

edited

Loading

Leapo commented Aug 24, 2023 •

edited

Loading