Influx DB 2.0 - Uploads re-start from beginning

My IoTaWatt either reboots due to degraded heap, or has some kind of wifi re-connection issue (the AP rebooting with an automatic firmware update as an example). Normally this would not be an issue, but it re-uploads data to InfluxDB2.0 from the beginning each time, which takes about 36 hours.

Is this behavior expected, and if not is there anything I can do to correct it?

1 Like

Can you post the message log and your influx setup?

Another unit experienced similar behavior once that I noticed. I just got my energy integrals working in Influx, so I hadn’t been watching the Influx status closely before.

    6/11/21 15:25:45 WiFi connected. SSID=SMRT, IP=10.59.55.154, channel=11, RSSI -75db
    6/11/21 15:33:29 WiFi disconnected.
    6/11/21 15:33:39 WiFi connected. SSID=SMRT, IP=10.59.55.154, channel=11, RSSI -76db
    7/09/21 00:24:31 WiFi disconnected.
    7/09/21 00:25:39 WiFi connected. SSID=SMRT, IP=10.59.55.154, channel=11, RSSI -74db
    7/14/21 05:08:01 WiFi disconnected.
    7/14/21 05:10:50 WiFi connected. SSID=SMRT, IP=10.59.55.154, channel=11, RSSI -73db
    7/15/21 22:21:04 timeSync: Six week routine restart.

    ** Restart **

    SD initialized.
    7/16/21 08:21:05z Real Time Clock is running. Unix time 1626423665 
    7/16/21 08:21:05z Reset reason: Software/System restart
    7/16/21 08:21:05z Trace:  1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:3, 1:1[7], 1:2[8], 9:0[8], 9:0, 9:1, 8:4, 8:6, 8:8, 8:9, 9:3, 9:5, 9:9, 1:2, 1:3, 1:3, 1:6[1], 1:6[2], 1:6[2], 1:6[2], 1:6[2], 1:6[3], 1:5[20], 1:6[4], 20:0, 20:1
    7/16/21 08:21:05z ESP8266 ChipID: 12704094
    7/16/21 08:21:05z IoTaWatt 5.0, Firmware version 02_06_02
    7/16/21 08:21:05z SPIFFS mounted.
    7/15/21 22:21:05 Local time zone: -10:00
    7/15/21 22:21:05 device name: IotaWatt
    7/15/21 22:21:05 HTTP server started
    7/15/21 22:21:05 influxDB_v1: Starting, interval:5, url:http://influx.my.com:8086
    7/15/21 22:21:05 influxDB_v2: Starting, interval:10, url:http://influx.my.com:8086/api/v2
    7/15/21 22:21:05 timeSync: service started.
    7/15/21 22:21:05 statService: started.
    7/15/21 22:21:05 dataLog: service started.
    7/15/21 22:21:06 dataLog: Last log entry 07/15/21 22:21:00
    7/15/21 22:21:09 WiFi connected. SSID=SMRT, IP=10.59.55.154, channel=11, RSSI -73db
    7/15/21 22:21:09 MDNS responder started for hostname IotaWatt
    7/15/21 22:21:09 LLMNR responder started for hostname IotaWatt
    7/15/21 22:21:09 Updater: service started. Auto-update class is MINOR
    7/15/21 22:21:09 influxDB_v1: Authentication failed. Stopping influx service.
    7/15/21 22:21:09 influxDB_v1: stopped, Last post 02/05/06 20:28:16
    7/15/21 22:21:09 influxDB_v2: Start posting 03/01/21 00:00:10
    7/15/21 22:21:10 historyLog: service started.
    7/15/21 22:21:10 historyLog: Last log entry 07/15/21 22:21:00
    7/15/21 22:21:11 Updater: Auto-update is current for class MINOR.

xx

Don’t see that in the message log. On July 15 it shows doing a normal six-week routine restart to reset the millisecond clock.

Don’t see anything like that. I see three disconnect/reconnect on 6/11 (10 seconds to reconnect), July 9 (68 seconds to reconnect, and July 14 (169 seconds to reconnect.) not unusual with RSSI of -73.

That’s a problem. I suspect the flux query to discover the last posted measurement is not working. I’ll have to dig deeper into that as it took awhile to figure out how to do that with flux and didn’t anticipate all of the measurements being the same name. It may be necessary to change the way that works.

1 Like

I believe I’ve located the issue here. It has top do with the flux query that looks for the time of the last post. In this case I believe the problem is the “device” tag value specification is not being handled properly. In this case however, $device is actually a the constant “IotaWatt”, so you would achieve the same result by specifying that as the device tag-value, and I think it will work as intended.

I’ve taken another look at the flux query, and recoded it to be more straightforward in dealing with the $ variables. I’ll work that change into the next release, anticipated in a month or so. In the meantime, let me know if the suggested workaround works fo you.

Thanks! What would the intended behavior of modifying the configuration be — re-downloading everything or starting from the end? I would expect the latter; if you want to re-download data you should delete the target bucket.

Starting from where it last left off.

Something seems to keep going wrong on one of my units:

 7/31/21 22:49:50 influxDB_v2: Starting, interval:10, url:http://influx.my.com:8086/api/v2
 7/31/21 22:49:50 timeSync: service started.
 7/31/21 22:49:50 statService: started.
 7/31/21 22:49:51 dataLog: service started.
 7/31/21 22:49:51 dataLog: Last log entry 07/31/21 22:49:45
 7/31/21 22:49:55 historyLog: service started.
 7/31/21 22:49:55 historyLog: Last log entry 07/31/21 22:49:00
 7/31/21 22:50:01 WiFi connected. SSID=SMRT, IP=10.59.55.139, channel=11, RSSI -87db
 7/31/21 22:50:01 MDNS responder started for hostname IotaKit
 7/31/21 22:50:01 LLMNR responder started for hostname IotaKit
 7/31/21 22:50:01 Updater: service started. Auto-update class is MINOR
 7/31/21 22:50:01 influxDB_v1: Authentication failed. Stopping influx service.
 7/31/21 22:50:01 influxDB_v1: stopped, Last post 02/05/06 20:28:16
 7/31/21 22:50:07 Updater: Auto-update is current for class MINOR.
 7/31/21 22:51:08 influxDB_v2: Start posting 03/01/21 00:00:10
 7/31/21 22:51:55 Heap memory has degraded below safe minimum, restarting.


** Restart **

 SD initialized.
 8/01/21 08:51:56z Real Time Clock is running. Unix time 1627807916 
 8/01/21 08:51:56z Reset reason: Software/System restart
 8/01/21 08:51:56z Trace:  1:6[2], 1:6[2], 1:6[3], 1:5[19], 1:6[4], 1:6[6], 1:1[1], 1:2[2], 9:0[2], 9:0, 9:1, 8:4, 8:6, 8:8, 8:9, 9:3, 9:5, 9:9, 1:2, 1:3, 1:3, 1:6[1], 1:6[2], 1:6[2], 1:6[2], 1:6[3], 1:5[21], 1:6[4], 21:0, 21:1, 21:10, 21:10
 8/01/21 08:51:56z ESP8266 ChipID: 12694594
 8/01/21 08:51:56z IoTaWatt 5.0, Firmware version 02_06_02
 8/01/21 08:51:56z SPIFFS mounted.
 7/31/21 22:51:56 Local time zone: -10:00
 7/31/21 22:51:56 device name: IotaKit
 7/31/21 22:51:56 HTTP server started
 7/31/21 22:51:56 influxDB_v1: Starting, interval:5, url:http://influx.my.com:8086
 7/31/21 22:51:56 influxDB_v2: Starting, interval:10, url:http://influx.my.com:8086/api/v2
 7/31/21 22:51:56 timeSync: service started.
 7/31/21 22:51:56 statService: started.
 7/31/21 22:51:57 dataLog: service started.
 7/31/21 22:51:57 dataLog: Last log entry 07/31/21 22:51:55
 7/31/21 22:52:01 historyLog: service started.
 7/31/21 22:52:01 historyLog: Last log entry 07/31/21 22:51:00
 7/31/21 22:52:06 WiFi connected. SSID=SMRT, IP=10.59.55.139, channel=11,      RSSI -89db
 7/31/21 22:52:06 MDNS responder started for hostname IotaKit
 7/31/21 22:52:06 LLMNR responder started for hostname IotaKit
 7/31/21 22:52:06 Updater: service started. Auto-update class is MINOR
 7/31/21 22:52:06 influxDB_v1: Authentication failed. Stopping influx service.
 7/31/21 22:52:06 influxDB_v1: stopped, Last post 02/05/06 20:28:16
 7/31/21 22:52:06 Updater: Auto-update is current for class MINOR.
 7/31/21 22:53:12 influxDB_v2: Start posting 03/01/21 00:00:10
 7/31/21 22:53:44 Heap memory has degraded below safe minimum, restarting.

** Restart **

 SD initialized.
 8/01/21 08:53:45z Real Time Clock is running. Unix time 1627808025 
 8/01/21 08:53:45z Reset reason: Software/System restart
 8/01/21 08:53:45z Trace:  31:0, 31:1, 31:2[6], 31:90, 31:93, 31:1, 1:6[6], 1:3, 1:3,      1:6[1], 1:6[2], 1:6[2], 1:6[3], 1:5[31], 1:6[4], 31:0, 31:1, 31:2[8], 31:5, 31:1, 1:6[6], 1:3, 1:3, 1:6[1], 1:6[2], 1:6[3], 1:5[21], 1:6[4], 21:0, 21:1, 21:10, 21:10
 8/01/21 08:53:45z ESP8266 ChipID: 12694594
 8/01/21 08:53:45z IoTaWatt 5.0, Firmware version 02_06_02
 8/01/21 08:53:45z SPIFFS mounted.
 7/31/21 22:53:45 Local time zone: -10:00
 7/31/21 22:53:45 device name: IotaKit

There are several other duplicate entries in the logs as well. Not sure if it keeps rebooting, but based on where it is on the upload process it looks unlikely. (It has uploaded from the beginning of the date range.)