Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
9 of 14 tasks
wongnam opened this issue Oct 7, 2019 · 44 comments
Closed
9 of 14 tasks

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

wongnam opened this issue Oct 7, 2019 · 44 comments
Labels
fixed Result - The work on the issue has ended troubleshooting Type - Troubleshooting

Comments

@wongnam
Copy link

wongnam commented Oct 7, 2019

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)

@ascillato2 ascillato2 added the troubleshooting Type - Troubleshooting label Oct 7, 2019
@wongnam
Copy link
Author

wongnam commented Oct 7, 2019

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
Copy link
Contributor

pablozg commented Oct 7, 2019

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Owner

arendst commented Oct 7, 2019

@Jason2866 do you use hardware or software serial?

@Jason2866
Copy link
Collaborator

hardware serial

@arendst
Copy link
Owner

arendst commented Oct 7, 2019

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

@s-hadinger
Copy link
Collaborator

Argh. Software Serial biting again.

Aren't there any logs of received data?

@wongnam
Copy link
Author

wongnam commented Oct 7, 2019

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
Copy link
Author

wongnam commented Oct 7, 2019

BTW. how do i switch it to hard serial?

@Jason2866
Copy link
Collaborator

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
Copy link
Author

wongnam commented Oct 7, 2019

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

@Jason2866
Copy link
Collaborator

Jason2866 commented Oct 7, 2019

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
Copy link
Author

wongnam commented Oct 7, 2019

version 6.6.0.15-2.5.2

image

go back to version 6.6.0.6-2.5.2

image

image

@Jason2866
Copy link
Collaborator

Jason2866 commented Oct 7, 2019

@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
Copy link
Owner

arendst commented Oct 7, 2019

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
Copy link
Owner

arendst commented Oct 7, 2019

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.

@arendst arendst added the fixed Result - The work on the issue has ended label Oct 7, 2019
@arendst 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
@wongnam
Copy link
Author

wongnam commented Oct 8, 2019

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:

image

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
Copy link
Owner

arendst commented Oct 8, 2019

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
Copy link
Author

wongnam commented Oct 8, 2019

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
Copy link
Author

wongnam commented Oct 8, 2019

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
Copy link
Owner

arendst commented Oct 8, 2019

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
Copy link
Collaborator

Jason2866 commented Oct 8, 2019

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...

arendst added a commit that referenced this issue Oct 8, 2019
 * 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
Copy link
Owner

arendst commented Oct 8, 2019

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
Copy link
Collaborator

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
Copy link
Owner

arendst commented Oct 8, 2019

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
Copy link
Author

wongnam commented Oct 8, 2019

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

@meingraham
Copy link
Collaborator

meingraham commented Oct 12, 2019

@arendst

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

@arendst
Copy link
Owner

arendst commented Oct 12, 2019

Correct. Only 1, 2 or 3 are supported.

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

@amagr0
Copy link

amagr0 commented Oct 19, 2019

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
Copy link
Contributor

@amagr0
Copy link

amagr0 commented Oct 20, 2019

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
Copy link
Author

wongnam commented Oct 20, 2019

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

@amagr0
Copy link

amagr0 commented Oct 20, 2019

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
Copy link
Author

wongnam commented Oct 20, 2019

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
Copy link

amagr0 commented Oct 20, 2019

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:

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

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

Thanks

@wongnam
Copy link
Author

wongnam commented Oct 21, 2019

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
Copy link

amagr0 commented Oct 21, 2019

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
image

Template parameters
image

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.

image

image

image

image

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
Copy link

amagr0 commented Oct 25, 2019

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

image

@rotarucosminleonard
Copy link

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
Copy link

AlfaBravoX commented May 25, 2022

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:
image

@vsaravind007
Copy link

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
Copy link

Leapo commented Aug 24, 2023

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
Copy link

@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:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed Result - The work on the issue has ended troubleshooting Type - Troubleshooting
Projects
None yet
Development

No branches or pull requests