Short Periods of Missing Data

[cdikland]

On a few occasions I get periods in time where there is no data recorded despite the fact the power is on. Last night was one such occasions. Below is part the *.csv I got from the Graph option which shows missing data between 22:40 and 23:55. Oddly enough it kick back in right at midnight.

2023-09-02 22:35:00, 1572.8, 1279.2
2023-09-02 22:40:00, null, null
2023-09-02 22:45:00, null, null
2023-09-02 22:50:00, null, null
2023-09-02 22:55:00, null, null
2023-09-02 23:00:00, null, null
2023-09-02 23:05:00, null, null
2023-09-02 23:10:00, null, null
2023-09-02 23:15:00, null, null
2023-09-02 23:20:00, null, null
2023-09-02 23:25:00, null, null
2023-09-02 23:30:00, null, null
2023-09-02 23:35:00, null, null
2023-09-02 23:40:00, null, null
2023-09-02 23:45:00, null, null
2023-09-02 23:50:00, null, null
2023-09-02 23:55:00, null, null
2023-09-03 00:00:00, 1477.3, 1408.1

[overeasy]

Can I see your message log covering that period? What other periods appear to be missing?

[cdikland]

The log for the period in question is below. The last entry/line in this log shows the same date/time (09/02/23 22:37:00) the problem occurred. I also checked the other period where I was receiving null entries and the log clearly shows “Power failure” so I’ll leave it at that,

** Restart **

SD initialized.
9/03/23 02:37:43z Real Time Clock is running. Unix time 1693708663 
9/03/23 02:37:43z Reset reason: Software Watchdog
9/03/23 02:37:43z Trace:  34:10[3], 34:0, 34:5, 34:5, 34:5, 34:6[1], 34:10[2], 34:0, 34:5, 34:5, 34:5, 34:6[1], 34:10[1], 34:0, 34:5, 34:5, 34:5, 34:6[1], 34:10, 25:18, 25:19, 25:20, 10:52, 10:54, 10:56, 25:20, 25:40, 25:41, 25:42, 25:41, 25:50, 25:51
9/03/23 02:37:43z ESP8266 ID: 499544, RTC M41T81 (68)
9/03/23 02:37:43z IoTaWatt 5.0, Firmware version 02_08_02
9/03/23 02:37:43z SPIFFS mounted.
9/02/23 22:37:43 Local time zone: -5:00, using DST/BST when in effect.
9/02/23 22:37:43 device name: IotaWatt
9/02/23 22:37:43 HTTP server started
9/02/23 22:37:43 timeSync: service started.
9/02/23 22:37:43 statService: started.
9/02/23 22:37:43 dataLog: service started.
9/02/23 22:37:46 IotaLog: file damaged /iotawatt/iotalog.log

9/02/23 22:37:46 IotaLog: Creating diagnostic file.

** Restart **

SD initialized.
9/03/23 03:08:05z Real Time Clock is running. Unix time 1693710485 
9/03/23 03:08:05z Reset reason: Exception
9/03/23 03:08:05z Trace:  1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:1[14], 1:2, 9:0, 9:0, 8:4, 8:6, 8:8, 1:3, 1:3, 1:6[1], 1:6[3], 1:5[19], 1:6[4]
9/03/23 03:08:05z ESP8266 ID: 499544, RTC M41T81 (68)
9/03/23 03:08:05z IoTaWatt 5.0, Firmware version 02_08_02
9/03/23 03:08:05z SPIFFS mounted.
9/02/23 23:08:05 Local time zone: -5:00, using DST/BST when in effect.
9/02/23 23:08:05 device name: IotaWatt
9/02/23 23:08:05 HTTP server started
9/02/23 23:08:05 timeSync: service started.
9/02/23 23:08:05 statService: started.
9/02/23 23:08:05 dataLog: service started.
9/02/23 23:08:07 IotaLog: file damaged /iotawatt/iotalog.log

9/02/23 23:08:07 IotaLog: Creating diagnostic file.
9/03/23 00:00:34 IotaLog: Deleting /iotawatt/iotalog.log and restarting.


** Restart **

SD initialized.
9/03/23 04:00:39z Real Time Clock is running. Unix time 1693713639 
9/03/23 04:00:39z Reset reason: Software/System restart
9/03/23 04:00:39z Trace:  1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:1, 1:2[1], 9:0[1], 9:0, 9:1, 8:4, 8:6, 8:8, 9:3, 9:5, 9:9, 1:3, 1:3, 1:6[1], 1:6[3], 1:5[19], 1:6[4]
9/03/23 04:00:39z ESP8266 ID: 499544, RTC M41T81 (68)
9/03/23 04:00:39z IoTaWatt 5.0, Firmware version 02_08_02
9/03/23 04:00:39z SPIFFS mounted.
9/03/23 00:00:39 Local time zone: -5:00, using DST/BST when in effect.
9/03/23 00:00:39 device name: IotaWatt
9/03/23 00:00:39 HTTP server started
9/03/23 00:00:39 timeSync: service started.
9/03/23 00:00:39 statService: started.
9/03/23 00:00:39 dataLog: service started.
9/03/23 00:00:39 dataLog: New current log created.
9/03/23 00:00:40 dataLog: Last history entry: 09/02/23 22:37:00
9/03/23 00:00:43 WiFi connected. SSID=CKZ_2HA, IP=192.168.1.139, channel=3, RSSI -47db
9/03/23 00:00:43 Updater: service started. Auto-update class is MINOR
9/03/23 00:00:44 Updater: Auto-update is current for class MINOR.
9/03/23 00:01:47 historyLog: service started.
9/03/23 00:01:47 historyLog: Last log entry 09/02/23 22:37:00

[overeasy]

Breaking this down…

@cdikland

I also checked the other period where I was receiving null entries and the log clearly shows “Power failure” so I’ll leave it at that,

So we are talking about just this one short gap.

@cdikland

The last entry/line in this log shows the same date/time (09/02/23 22:37:00) the problem occurred.

Approximately. The gap is 5 minute intervals, so the start and end are +/- 5 minutes. It started between 22:35 and 22:40 and picked up again between 00:00 and 00:05.

This appears to be a problem with the current log. That’s the 5 second resolution log. The message log that you posted doesn’t go back enough to see the start of the problem, but the story picks up with a restart after a software watchdog restart. This is very rare and is probably caused by an SDcard problem. Moving down, after the restart, the unit detects damage to the current log (The 5 second resolution log). It begins reading the file and creating a diagnostic file.

A few minutes into the process, there is an exception and the unit again restarts. Again it detects the log damage and this time appears to successfully create the diagnostic file, then it deletes the current log and restarts at 00:00:39. It creates a new current log and apparently runs fine thereafter.

This completely explains the gap, bdut doesn’t get to the root cause of the watchdog timeout, exception or datalog damage. I would not be very confident that there is no as yet undetected history log damage. My recommendation would be to replace the SDcard.

Remove/replace SDcard

Sometimes it becomes necessary to remove the microSD card. You may need to replace it or look at the message log if the device isn’t working, or maybe you want to back up the datalogs. For whatever reason, it’s best to be careful as the type of holder and position makes it easy to damage during removal. Power down the IoTaWatt by removing the USB power plug and AC reference plug. If mounted to a wall, remove the mounting screws. Remove the four Philips head screws in the back. Remo…

Building a new SDcard

These instructions were great! After a power fail, my Iotawatt didn’t come back up. Tried cycling power a copule times but it mostly blinked Red-Green-Green-Red. Took an old 32GB SD card, formatted it, dropped in the files you mentioned from Github, copied over my config.txt and /iotawatt directory, and I’m back in business. No lost data (other than the samples missed while it was offline). The cranky SD card is a blue 8GB Stromboli, FWIW.

I recommend when building the new card that you don’t copy the /iotawatt directory. You will restart with a new message log and new current and history logs as with a new unit. Unfortunately, you will also lose your history.

[cdikland]

Will try this later this week and post how I make out. Thanks for your help.