Command SaveData breaks BME280 sensor

[simonmicro]

PROBLEM DESCRIPTION

When using the SaveData command with any parameter (or even none) the BME280 sensor only reports the following - regardless of the real values. On the current release 8.4.0 the "Dew point" is null instead of the value below.

BME280 Temperature | 23.8 °C
BME280 Humidity | 100.0 %
BME280 Dew point | 23.8 °C
BME280 Pressure | 638.7 hPa

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in the docs
• Searched the problem in the forum
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): ESP8266, custom circuit
• Tasmota binary firmware version number used: 8.4.0.3
  • Pre-compiled
  • Self-compiled
    • IDE / Compiler used: benzino77/tasmocompiler
• Flashing tools used: Tasmotizer, Web interface
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:
18:10:18 CMD: Backlog Template; Module; GPIO 255
18:10:18 RSL: stat/tasmota_697A50/RESULT = {"NAME":"Tasmota-Bett","GPIO":[0,5,0,6,0,0,0,0,9,0,7,0,0],"FLAG":0,"BASE":18}
18:10:19 RSL: stat/tasmota_697A50/RESULT = {"Module":{"0":"Tasmota-Bett"}}
18:10:19 RSL: stat/tasmota_697A50/RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"5":"I2C SCL"},"GPIO2":{"0":"None"},"GPIO3":{"6":"I2C SDA"},"GPIO4":{"0":"None"},"GPIO5":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"9":"Switch1"},"GPIO13":{"0":"None"},"GPIO14":{"7":"WS2812"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"}}

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:
18:13:21 CMD: Status 0
18:13:21 RSL: stat/tasmota_697A50/STATUS = {"Status":{"Module":0,"DeviceName":"Tasmota","FriendlyName":["Tasmota"],"Topic":"tasmota_697A50","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":0,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
18:13:21 RSL: stat/tasmota_697A50/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://thehackbox.org/tasmota/release/tasmota.bin","RestartReason":"Software/System restart","Uptime":"0T00:00:08","StartupUTC":"2020-09-13T17:13:13","Sleep":50,"CfgHolder":4617,"BootCount":7,"BCResetTime":"2020-09-13T17:57:53","SaveCount":19,"SaveAddress":"FB000"}}
18:13:21 RSL: stat/tasmota_697A50/STATUS2 = {"StatusFWR":{"Version":"8.4.0.3(tasmota)","BuildDateTime":"2020-09-13T17:00:43","Boot":31,"Core":"2_7_4_1","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"391/699"}}
18:13:21 RSL: stat/tasmota_697A50/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["U.S.S. Voyager NCC-74656",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C8000100060000005A00000000000000","00000000","00006000","00000000"]}}
18:13:21 RSL: stat/tasmota_697A50/STATUS4 = {"StatusMEM":{"ProgramSize":504,"Free":496,"Heap":25,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"1640EF","FlashFrequency":40,"FlashMode":3,"Features":["00000809","0880C586","04260001","00B404C1","00000000","C004F981","00000004","00000000"],"Drivers":"1,2,4,6,8,10,18,19,22,24,26,27,29,30,35,37","Sensors":"1,2,4,5,6,9,15,17,18,20,56"}}
18:13:21 RSL: stat/tasmota_697A50/STATUS5 = {"StatusNET":{"Hostname":"tasmota_697A50-6736","IPAddress":"192.168.0.18","Gateway":"192.168.0.1","Subnetmask":"255.255.0.0","DNSServer":"192.168.0.1","Mac":"50:02:91:69:7A:50","Webserver":2,"WifiConfig":4,"WifiPower":17.0}}
18:13:21 RSL: stat/tasmota_697A50/STATUS6 = {"StatusMQT":{"MqttHost":"","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_697A50","MqttUser":"DVES_USER","MqttCount":0,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30}}
18:13:21 RSL: stat/tasmota_697A50/STATUS7 = {"StatusTIM":{"UTC":"2020-09-13T17:13:21","Local":"2020-09-13T18:13:21","StartDST":"2020-03-29T02:00:00","EndDST":"2020-10-25T03:00:00","Timezone":"+01:00"}}
18:13:21 RSL: stat/tasmota_697A50/STATUS10 = {"StatusSNS":{"Time":"2020-09-13T18:13:21","Switch1":"OFF","BME280":{"Temperature":25.7,"Humidity":45.6,"DewPoint":13.0,"Pressure":1013.0},"PressureUnit":"hPa","TempUnit":"C"}}
18:13:21 RSL: stat/tasmota_697A50/STATUS11 = {"StatusSTS":{"Time":"2020-09-13T18:13:21","Uptime":"0T00:00:08","UptimeSec":8,"Heap":25,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":22,"MqttCount":0,"POWER":"OFF","Dimmer":0,"Color":"00000000","HSBColor":"0,0,0","White":0,"Channel":[0,0,0,0],"Scheme":0,"Width":1,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"U.S.S. Voyager NCC-74656","BSSId":"54:A0:50:76:16:B0","Channel":3,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:03"}}}
18:13:22 RSL: tele/tasmota_697A50/STATE = {"Time":"2020-09-13T18:13:22","Uptime":"0T00:00:09","UptimeSec":9,"Heap":25,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POWER":"OFF","Dimmer":0,"Color":"00000000","HSBColor":"0,0,0","White":0,"Channel":[0,0,0,0],"Scheme":0,"Width":1,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"U.S.S. Voyager NCC-74656","BSSId":"54:A0:50:76:16:B0","Channel":3,"RSSI":88,"Signal":-56,"LinkCount":1,"Downtime":"0T00:00:03"}}
18:13:22 RSL: tele/tasmota_697A50/SENSOR = {"Time":"2020-09-13T18:13:22","Switch1":"OFF","BME280":{"Temperature":25.7,"Humidity":45.6,"DewPoint":13.0,"Pressure":1013.0},"PressureUnit":"hPa","TempUnit":"C"}

• 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:
18:14:37 CMD: status 8
18:14:37 SRC: WebConsole from 192.168.0.44
18:14:37 CMD: Group 0, Index 1, Command "STATUS", Data "8"
18:14:37 RSL: stat/tasmota_697A50/STATUS8 = {"StatusSNS":{"Time":"2020-09-13T18:14:37","Switch1":"OFF","BME280":{"Temperature":25.7,"Humidity":45.6,"DewPoint":13.0,"Pressure":1013.0},"PressureUnit":"hPa","TempUnit":"C"}}
18:14:44 CMD: savedata 0
18:14:44 SRC: WebConsole from 192.168.0.44
18:14:44 CMD: Group 0, Index 1, Command "SAVEDATA", Data "0"
18:14:44 CFG: Saved to flash at FA, Count 20, Bytes 4096
18:14:44 RSL: stat/tasmota_697A50/RESULT = {"SaveData":"OFF"}
18:14:50 CMD: status 8
18:14:50 SRC: WebConsole from 192.168.0.44
18:14:50 CMD: Group 0, Index 1, Command "STATUS", Data "8"
18:14:50 RSL: stat/tasmota_697A50/STATUS8 = {"StatusSNS":{"Time":"2020-09-13T18:14:50","Switch1":"OFF","BME280":{"Temperature":23.8,"Humidity":100.0,"DewPoint":23.8,"Pressure":638.7},"PressureUnit":"hPa","TempUnit":"C"}}

TO REPRODUCE

Steps to reproduce the behavior:

1. Flash Tasmota
2. Install the template
3. Check the BME280 sensor for its info
4. Execute SaveData
5. Check the BME280 sensor for its info

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.
Well, the sensor should not crash and lock to that values...

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Add any other context about the problem here.
Chip was multiple times completely erased and flashed from scratch. Noticeably I can't reproduce the behavior on any of my other chips. Also I can not NOT use the SaveData 0 command, due my own written lighting system often modifying the colors or other parameters, as it would damage the chip over time.

(Please, remember to close the issue when the problem has been addressed)

[sfromis]

On 8.5.0.1, I can confirm also getting weird BME280 readings after SaveData, before/after:
"BME280":{"Temperature":25.7,"Humidity":44.0,"DewPoint":12.6,"Pressure":1023.43,"SeaPressure":1025.42}
"BME280":{"Temperature":22.1,"Humidity":85.9,"DewPoint":19.6,"Pressure":697.57,"SeaPressure":692.05}

[sfromis]

I'm assuming that you mean that you can not use the SaveData 1 setting due to flash wear, but instead use SaveData 0. You can circumvent the issue by doing a restart after any SaveData command.

[simonmicro]

I'm assuming that you mean that you can not use the SaveData 1 setting due to flash wear, but instead use SaveData 0. You can circumvent the issue by doing a restart after any SaveData command.

I can't use any SaveData x (x > 0) due flash wear - yes (without x, 0 gets assumed). I also know that I have to restart the chip (using Restart 1) when I use SaveData 0, because otherwise no parameters are saved (which happens only on a weekly basis). In any case, using the command the BME280 data gets corrupted...
So when you assume this from my issue, then you're assuming right. 😁

[sfromis]

To be exact about a side detail, doing a SaveData without argument does not assume "0", but just saves data now, while doing a SaveData 0 will both save data now and also instruct Tasmota to not save data automatically going forward. In both cases, the saved setting is displayed after the command. And thus you do not need restart after SaveData 0, except to circumvent the corruption issue. Running with WebLog 3 makes it clear exactly when the data is saved to flash.

But of course, the bug about doing a SaveData (not doing something else triggering save) corrupting BME280 readings is the real issue here.

[simonmicro]

To be exact about a side detail, doing a SaveData without argument does not assume "0", but just saves data now, while doing a SaveData 0 will both save data now and also instruct Tasmota to not save data automatically going forward. In both cases, the saved setting is displayed after the command. And thus you do not need restart after SaveData 0, except to circumvent the corruption issue. Running with WebLog 3 makes it clear exactly when the data is saved to flash.

Ooops, my bad. I also tested your example. Yes, indeed - SaveData just returns the current setting. I guess I was confused by that?!

Some thoughts about the current issue:

• The memory layout for the stored value of SaveData should not affect this, as the BME280 data is not stored to flash
• Due the different behaviour of the corruption, I guess it is a "segfault" for the loaded SaveData state - therefore hard to reproduce
• The problem must be inside the command handling, because the loading of the data from the flash at the boot does not break the BME280 (maybe the sensors get loaded after the config? In that case this note is pointless)
• Because the sensor locks up and to data get updated never again (just hold it and watch the not rising temps) I also guess SaveData corrupts the sensor handler and its saved data. There is a good chance that also other important data gets overwritten.
• Also there could be a problem with the data buffer of the BM280 as I was able to sometimes (about once per month) crash Tasmota chips running this sensor... But this could also have other reasons!
• Also the usage of the "emtpy" SaveData command (without any timer value) breaks the BME280... Maybe an other indicator for a broken command handler? I guess it has something to do with the RTC memory slots used for the settings and the sensor...

[arendst]

A typical case of one programmer (me) defines a call back for a certain goal and another programmer thinks to use it for his goal without analysing the impact of it.

In this case when command SaveData is executed it wants to save volatile data to flash for all BUT the BMP driver. The BMP driver will execute sleepmode without testing if sleep mode is enabled and puts the sensor in a reset state resulting in what you (and I) observe.

I'll rewrite the BMP driver sleepmode trigger to test if this is a real sleep request.

Expect fix in a few minutes.

[sfromis]

Confirmed working with http://ota.tasmota.com/tasmota/tasmota-sensors.bin.gz

[simonmicro]

I can also confirm that the newest build now works as expected. 🎉

Thank you for your very fast response and fix!