InfluxDB send dates wrong | no data - resolved


#1

Hey there,

IotaWatt has been running fine for the last little while however when I accidentally took down my Influx instance, the iotawatt seemed to hang needing a reboot. After rebooting, it says that the Influx connector is running however nothing is being sent to the DB. Looking at the logs, it looks like it’s waiting for a previous date to start sending?

** Restart **

SD initialized.
5/01/19 01:31:08z Real Time Clock is running. Unix time 1556674268 
5/01/19 01:31:08z Reset reason: Software/System restart
5/01/19 01:31:08z Trace:  9:0, 9:1, 8:4, 8:6, 8:8, 8:9, 9:3, 9:5, 9:9, 1:2, 1:3, 1:4, 1:5[7], 7:0, 7:9, 1:6, 1:1[12], 1:2[13], 9:0[13], 9:0, 9:1, 8:4, 8:6, 8:8, 8:9, 9:3, 9:5, 9:9, 1:2, 1:3, 10:2, 10:3
5/01/19 01:31:08z ESP8266 ChipID: 3331370
5/01/19 01:31:08z IoTaWatt 4.x, Firmware version 02_04_00
5/01/19 01:31:08z SPIFFS format failed
5/01/19 01:31:08z Local time zone: +0:00
5/01/19 01:31:08z device name: IotaWatt
5/01/19 01:31:08z MDNS responder started for hostname IotaWatt
5/01/19 01:31:08z LLMNR responder started for hostname IotaWatt
5/01/19 01:31:08z HTTP server started
5/01/19 01:31:08z timeSync: service started.
5/01/19 01:31:08z statService: started.
5/01/19 01:31:08z dataLog: service started.
5/01/19 01:31:09z dataLog: Last log entry 05/01/19 01:40:40
5/01/19 01:31:09z historyLog: service started.
5/01/19 01:31:09z historyLog: Last log entry 05/01/19 01:40:00
5/01/19 01:31:13z influxDB: started, url=alexturner.co:8086, db=power, interval=5
5/01/19 01:31:14z WiFi connected. SSID=Turners WiFi, IP=10.0.1.10, channel=13, RSSI -76db
5/01/19 01:31:14z Updater: service started. Auto-update class is MINOR
5/01/19 01:31:25z Updater: Auto-update is current for class MINOR.
5/01/19 01:31:27z influxDB: Start posting at 04/20/19 01:22:05
5/01/19 01:42:04z timeSync: adjusting RTC by 655

Thoughts?iotamsgs.txt (116.8 KB)


#2

Hi Alex,
The “Start posting” is the time of the last measurement posted to the database. It should be uploading from that time onward. Can I see a screenshot of the status display with the influx and datalog tabs?


#3

Just looking over the entire message log. Changed the category to Homebrew. “running fine” wouldn’t be my first take. Your RTC is not working properly. The datalog must be recorded sequentially. I don’t know what is going on with your clock, but it looks like it just doesn’t run. Do you have a crystal? Is it 32.7680KHZ 12.5pF? I don’t know the failure mode that causes the clock to allow itself to be set but not actually run. You really need to fix that before going after operational problems.

My recommendation is to fix the RTC issue so that it works properly, especially after power failure. The datasheet is pretty straightforward and you should be able to test it with some simple I2C code. Without the benefit of a reliable timepiece, it will be very hard to narrow down what might be happening here.


#4

Thanks for the quick reply. Crystal is a 32.0000KHz at 12.5pf, I wonder if the decimal accuracy would cause it to have such a hard time here. https://www.digikey.com.au/product-detail/en/abracon-llc/ABS25-32.000KHZ-T/535-10242-1-ND/2218055

Status:


#5

Open the influx and datalogs dropdowns


#6

Looks like influx has made progress since the original post. It’s reporting 21/04/2019 6:49:55

Also, the sample rate is pretty low, so I take that to mean that it’s shoveling data out as fast as it can to influx and it’s dimming the lights a little. You have a 5 second interval, and depending on the number of measurements you are sending each post, this might be a good time to go to a movie or something.


#7

Yeah, I’m seeing that, It’s changing almost randomly whilst I watch the display screen. What makes you think it’s the RTC? There’s still nothing in the DB


#8

What do you mean “randomly”? Is it progressing or does it regress at times?


#9

It appears to be progressing in 30 second intervals every second. No regression


#10

The influx line protocol is very verbose. It can take awhile. Someday I’ll get around to writing a compression algorithm to speed this part up.

How do you know there’s nothing in the DB? It’s a synchronous protocol, and it should be receiving acknowledgements from the DB.


#11

Interesting… I didn’t realise the Iotawatt would push old data when it’s disconnected. It looks like it’s uploading all the data it captured when it wasn’t able to contact the DB. Looks like it is progressing in that case. Still intrigued by this RTC issue though, I’ll whip up another board and have a look on the bench.

On a totally unrelated note; working on another project, I just realised the cost and availability of the ESP32 modules (without the dev kit and UART chip), plus they’ve got a load of ADC inputs. Might be interesting for your next version.


#12

Yea, no holes with IoTaWatt. By your account it’s 30:1, you are 9 days behind. If the IoTaWatt was running all that time, then it will take roughly 7 hours to catch up. Like I said - watch a movie or something, leave the driving to us.

ESP32 - It’s not about the cost of the ESP32. That’s trivial. It’s about the cost to get safety, FCC and EC tested and certified and modifying the enclosure mold. I’ve got an ESP32 IoTaWatt sitting right here. It will probably never see the light of day.

Fix that clock.


#13

Ha will do!

I didn’t realise the current IotaWatt was certified, or is it the ESP32 that’s not? Moulding sounds like an expensive process to get started with

Alex