wongnam commented 4 years ago

BUG DESCRIPTION

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

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

[x] 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

wongnam commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@Jason2866 do you use hardware or software serial?

Jason2866 commented 4 years ago

hardware serial

arendst commented 4 years ago

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

s-hadinger commented 4 years ago

Argh. Software Serial biting again.

Aren't there any logs of received data?

wongnam commented 4 years ago

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 commented 4 years ago

BTW. how do i switch it to hard serial?

Jason2866 commented 4 years ago

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 commented 4 years ago

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

Jason2866 commented 4 years ago

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 commented 4 years ago

version 6.6.0.15-2.5.2

go back to version 6.6.0.6-2.5.2

Jason2866 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

meingraham commented 4 years ago

@arendst

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

arendst commented 4 years ago

Correct. Only 1, 2 or 3 are supported.

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

amagr0 commented 4 years ago

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 commented 4 years ago

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

amagr0 commented 4 years ago

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 commented 4 years ago

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

amagr0 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 10 months ago

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 commented 6 months ago

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

arendst / Tasmota

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

BUG DESCRIPTION

TO REPRODUCE

EXPECTED BEHAVIOUR

SCREENSHOTS

version 6.6.0.15-2.5.2

go back to version 6.6.0.6-2.5.2

the first time:

the second time: (replicated)

weblog 4:

screenshot:

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

the fourth time: