arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.23k stars 4.81k forks source link

S31 Checksum Error #4610

Closed meingraham closed 5 years ago

meingraham commented 5 years ago

IMPORTANT NOTICE If you do not complete the template below it is likely that your issue will not be addressed. When providing information about your issue please be as extensive as possible so that it can be solved by as little as possible responses.

FAILURE TO COMPLETE THE REQUESTED INFORMATION WILL RESULT IN YOUR ISSUE BEING CLOSED

Make sure these boxes are checked [x] before submitting your issue - Thank you!

There are a couple of older issues related checksum errors on the S31 and other power monitoring devices. I'm experiencing similar issues.

Since upgrading to 6.3.0.14, I'd been getting readings on the S31 even when the load was off. Before (6.2.1.16) I would reliably get a zero reading. Also, the readings during operation now fluctuate and I had to "widen" my thresholds in order to trap events properly.

Today, I was playing with implementing SysLog logging and by chance chose this device (S31) to test logging. I set the logging level to 4. To my surprise, this is what I started seeing:

s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 98 DF 4A 9D 90 29 25 A0 71 CD 36 47
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 98 DF 4A 9D 90 29 25 A0 71 CD 36 47
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 98 DF 4A 9D 90 29 25 A0 71 CD 36 47
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 98 DF 4A 9D 90 29 25 A0 71 CD 36 47
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 98 DF 4A 9D 90 29 25 A0 71 CD 36 47
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 98 DF 4A 9D 90 29 25 A0 71 CD 36 47
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 98 DF 4A 9D 90 29 25 A0 71 CD 36 47
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 3B 24 06 98 DF 4A 9D 90 13 C6 26 61 CD 36 48 55
s31_power_monitor-xxxx ESP-CSE: Checksum failure
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 55 5A 02 AD 28 00 05 B6 00 3B 24 06 98 DF 4A
s31_power_monitor-xxxx ESP-CSE: Checksum failure
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 98 DF 4A 9D 90 18 92 55 61 CD 36 48
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 1D 5F 55 5A 02 AD 28
s31_power_monitor-xxxx ESP-CSE: Checksum failure
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 20 91 4E 61 CD 36 A2
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 25 5D 7D 61 CD 36 A2
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 26 F7 E1 61 CD 36 A1
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 28 91 46 61 CD 36 A2
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 2A 2A AB 61 CD 36 A2
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 2B C4 10 61 CD 36 A2
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 2D 5D 75 61 CD 36 A2
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D
s31_power_monitor-xxxx ESP-CSE: Checksum failure
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 30 8F 40 61 CD 36 A2
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 8E 43 4A 9D 90 33 82 4A 55 5A 02 AD
s31_power_monitor-xxxx ESP-CSE: Checksum failure
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 08 0F 4A 9D 90 33 82 4A 61 CD 36 E8
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 08 0F 4A 9D 90 10 3D C5 61 CD 36 FB
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B6 00 3B 24 06 08 0F 4A 9D 90 11 D6 2B 61 CD 36 FB
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 00 3B 24 06 08 0F 4A 9D 90 13 70 8F 61 CD 36 FB 55 5A 02 AD
s31_power_monitor-xxxx ESP-CSE: Checksum failure
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B5 00 3B 24 06 08 0F 4A 9D 90 15 08 F5 61 CD 36 FA
s31_power_monitor-xxxx ESP-SER: Received 55 5A 02 AD 28 00 05 B5 00 3B 24 06 08 0F 4A 9D 90 16 A3 59 61 CD 36 FA

Maybe these checksum errors are the source of the strange readings I've been having.

ascillato commented 5 years ago

Have you turned off seriallog?

Please, could you add in your description the links to the related issues you are refering to?

digiblur commented 5 years ago

Were seeing the zero readings before and now you are not due to this fix?

https://github.com/arendst/Sonoff-Tasmota/commit/665a4abc47cbee81eb32cf5bcd23782ee044561b

andrethomas commented 5 years ago

From status 3

"SerialLog":2

ascillato commented 5 years ago

@meingraham

Please, set seriallog to 0.

The seriallog is interfering with the data sent by the power measurement chip.

When you select the pow R2 or s31 module, Tasmota automatically set seriallog to 0, but if you enable that, is not changed because you may be using serial for a debugging.

This was already addressed in https://github.com/arendst/Sonoff-Tasmota/issues/3425

meingraham commented 5 years ago

Thanks All!

Interesting, I had not been "initializing" SerialLog on any of my devices before during my configuration phase. I'll set it for the S31 and report back. I thought that when one selected the S31 Module, it would make the appropriate settings for SerialLog by default. Is that not the case?

Mike

ascillato commented 5 years ago

Yes, Tasmota does that. But if you have seriallog enabled before doing an OTA, it will be left enabled because it assumes that if you have enabled seriallog, you are debugging.

When you select the S31 module, Tasmota sets the baudrate to 4800 also.

meingraham commented 5 years ago

Yeah, SerialLog setting must have been a leftover... but I had not changed the setting from when I first set the S31 up. That is, I flashed the firmware, set the Module, MQTT, etc., and put the device in operation. I did not change SerialLog. I then updated the firmware a couple of weeks ago via OTA. No settings changes.

Most recent checksum related issues: https://github.com/arendst/Sonoff-Tasmota/issues/3425 https://github.com/arendst/Sonoff-Tasmota/issues/1907

In any case, I set SerialLog to 0 and the checksum errors remained. I restarted the device. Checksum errors remain.

stat/s31_power_monitor/STATUS = {"Status":{"Module":41,"FriendlyName":["S31 Power Monitor"],"Topic":"s31_power_monitor","ButtonTopic":"0","Power":1,"PowerOnState":1,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":1}}
stat/s31_power_monitor/STATUS1 = {"StatusPRM":{"Baudrate":4800,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T00:06:50","StartupUTC":"2018-12-13T12:56:08","Sleep":0,"BootCount":9,"SaveCount":47,"SaveAddress":"F8000"}}
stat/s31_power_monitor/STATUS2 = {"StatusFWR":{"Version":"6.3.0.14(sonoff)","BuildDateTime":"2018-11-30T13:36:30","Boot":31,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
stat/s31_power_monitor/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":2,"SysLog":4,"LogHost":"ha_server","LogPort":514,"SSId":["mySSID",""],"TelePeriod":300,"SetOption":["00008129","558180C0","000000C0"]}}
stat/s31_power_monitor/STATUS4 = {"StatusMEM":{"ProgramSize":435,"Free":568,"Heap":16,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"1640EF","FlashMode":3,"Features":["00000809","0F002790","00000001","0000009E","000000C0"]}}
stat/s31_power_monitor/STATUS5 = {"StatusNET":{"Hostname":"s31_power_monitor-xxxx","IPAddress":"192.168.1.xxx","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"myMAC","Webserver":2,"WifiConfig":4}}
stat/s31_power_monitor/STATUS6 = {"StatusMQT":{"MqttHost":"ha_server","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_xxxxxx","MqttUser":"haUser","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
stat/s31_power_monitor/STATUS7 = {"StatusTIM":{"UTC":"Thu Dec 13 13:02:58 2018","Local":"Thu Dec 13 08:02:58 2018","StartDST":"Sun Mar 11 02:00:00 2018","EndDST":"Sun Nov 04 02:00:00 2018","Timezone":99,"Sunrise":"07:26","Sunset":"17:15"}}
stat/s31_power_monitor/STATUS9 = {"StatusPTH":{"PowerDelta":2,"PowerLow":0,"PowerHigh":0,"VoltageLow":0,"VoltageHigh":0,"CurrentLow":0,"CurrentHigh":0}}
stat/s31_power_monitor/STATUS10 = {"StatusSNS":{"Time":"2018-12-13T08:02:58","ENERGY":{"TotalStartTime":"2018-11-30T12:07:13","Total":214.667,"Yesterday":16.330,"Today":6.956,"Power":2,"ApparentPower":6,"ReactivePower":6,"Factor":0.28,"Voltage":122,"Current":0.053}}}
stat/s31_power_monitor/STATUS11 = {"StatusSTS":{"Time":"2018-12-13T08:02:58","Uptime":"0T00:06:50","Vcc":3.161,"LoopSet":255,"LoadAvg":4,"POWER":"ON","Wifi":{"AP":1,"SSId":"mySSID","BSSId":"apMAC","Channel":6,"RSSI":64}}}
andrethomas commented 5 years ago

Could also be that your "LoopSet":255 is too high to service the serial interface fast enough - also this changed from 6.3.0.15 to be combined with the sleep command and the functionality changed a little because of this. The newer version uses sleep for both and is maximum at 250 - I'm not sure what the baud rate is of that sensor you're using or the amount of data so it could be one of two things - either its not servicing it fast enough or its not servicing it frequently enough.

That is all I can think of for now.

andrethomas commented 5 years ago

LoopSet (also know as SetOption36) was deprecated in 6.3.0.15 in favor of a combined sleep command with SetOption60 being used to select between traditional/normal sleep or dynamic sleep (default which = 0)

ascillato commented 5 years ago

Baudrate is 4800 for S31

@meingraham Please, try to update to latest version 6.3.0.17 If you still have checksum errors, please try the command sleep 0

meingraham commented 5 years ago

@andrethomas,

That was it. Dynamic sleep (setoption36 for 6.3.0.14) set too high. Had to set it to 100. 150 still caused checksum errors. 255 definitely too high!

Thanks.

Mike

meingraham commented 5 years ago

Spoke a bit too soon... Still getting checksum errors but far fewer. Even at 25 it still generates errors often enough that I can them every few seconds.

ascillato commented 5 years ago

@meingraham

Please, try to update to latest version 6.3.0.17 that has an enhanced dynamic sleep.

If you still have checksum errors, please try the command sleep 0

meingraham commented 5 years ago

This is Dynamic Sleep in 6.3.0.14...

I set sleep off completely SetOption36 0 Sleep 0

Still the occasional checksum error... although far fewer.

I'll give 6.3.0.17 a try in a bit.

meingraham commented 5 years ago

Couldn't get a successful OTA upgrade. Tried minimal too, wouldn't complete successfully. I've had this issue with these S31s before. OTA is hit or miss. When it fails, it fails no matter what I try. When it works, I can load new firmware over and over.

In any case... something cleared it's brains. I have it set back to SetOption36 50 and it's stable. AND, the power readings are back to "normal". I wish I'd realized sooner that these checksum errors were at the root of the fluctuations. Would have saved me some troubleshooting on my automations :( Alls well that ends well... I'm hoping. But at least now I understand something new that I can add to my troubleshooting quiver.

ascillato commented 5 years ago

So, if it can't do OTA, there is something wrong in the firmware. If you want to ensure that it is reliable now, you should do a full flash erase and flash latest tasmota by wire.

meingraham commented 5 years ago

I don't think it's the firmware. Same binary on other devices and OTA works reliably. It's just these S31s that are finicky.

I'm TERRIBLE at soldering... so the prospect of taking these apart again usually puts this on my "very last resort" items ;-) In fact, on one of these S31s I ended up having to take it to a professional to get the flashing leads soldered. And, because of the way they fit in the case, of course I had to remove them.

So, right now it ain't broke... so I ain't gonna fix it ;-) If it starts misbehaving again, yes, I'll do whatever it takes to get the firmware updated.

Thanks for your help Adrian & Andre!

Mike

ascillato commented 5 years ago

I meant by a bad firmware to be a bad flashing or wrong information left in the flash for not erasing before flashing or a problem in the OTA process.

An OTA that was unsuccessful won't change anything in your flash. So, if now it is working but nothing has changed, seems that will led to your issue again. So, it is recommended, in these weird cases, to full erase flash and to flash again by wire. This simple process have solved a huge amount of issues.

Thanks for all your testings :+1:

meingraham commented 5 years ago

Adrian,

"will led to your issue again" I agree... I'm just crossing my fingers. The application is not critical (washer machine notifications) so if it misbehaves, I can deal with it in a lower priority task list ;-)

When I build up my stamina and get around to getting the flashing wires back on it, I'll remember to erase completely before uploading. I've gotten into that habit now anyway.

Mike.

P.S. I have two S31s. If either misbehaves like this in the future, I promise to update the firmware before posting an issue ;-)