Have been noticing a lot of restarts. Figured it was due to my many config changes while trying to figure out the best way to setup the IotaWatt. I’ve finally come to a IotaWatt/Influx configuration I think works well that is based on Brett’s work (Best practices for influxdb? - #12 by brettbeeson) (thanks @brettbeeson)
Today, the Iotawatt had the “Dull Red Glow” indicating something wrong with the wifi connection. Cycled power to the IotaWatt and it came up normally.
Went to check the log and saw a lot of “Incomplete HTTP request detected, id 7, restarting.” messages. I counted 77 restarts since 12/13. On average every ~45 minutes. (Attached the log) iotamsgs.txt (135.0 KB)
From what I can see. “id 7” means this is related to Influx. I skimmed over this thread (InfluxDb issues) that discusses timeouts, post length & influx config with firmware 02_03_16. I’m running 02_03_18.
My config seems pretty basic. 14 CTs, sending mostly watts to Influx, plus a “Main1+Main2” in watts & kWh. (Also attached my config.txt) config.txt (4.8 KB)
I’m sending to a local Influx server at 192.168.1.1 (not a raspberryPi).
I’m guessing the WiFi issue (red glow) was a fluke (It’s only happened once), but pointed me to all the restarts in the log.
Yes, 7 is the trace ID of the influx service. incompleteHTTP request is a timeout of the resource management semaphores that limit the amount of concurrent TCP activity. The id=7 just says that the timed out resource allocation is held by the influx service. Not necessarily an indication of a problem with influx, because you don’t have any other regular TCP activity so it could just mean a broader TCP problem the always manifests itself in the influx service because that’s the predominant user of the TCP resource. This theory is reinforced by the very poor RSSI reported for your WiFi link.
On the other hand, the logs indicate that after the restart, all of the backlog of influx data is uploaded. A pretty heavy lift given the size of your payload. It’s not until 15 minutes before the timeout that influx posting stops, which is the timeout interval to relinquish an HTTP usage token.
When it comes to WiFi, there is a gray area between IoTaWatt firmware and the underlying core services provided by Espresif, the Arduino teal and others like the lwip folks.
As it stands, your IoTaWatt continues to sample and log local data, and it doesn’t lose any data in spite of the restarts, so not a critical problem. As a lowly IoT device with limited capability, all of the failsafe mechanisms are working properly to protect data integrity in an adverse environment.
I’d suggest improving the WiFi signal, either by trying other channels or by installing an inexpensive wall plug repeater.
Ok, thanks for the details. Glad it’s likely not an Influx/software issue and just more prominent now that it’s sending more data (compared to not using a web service).
I will mess around with my WiFi and try to get a stronger signal. It’s an older router located 30-40ft away (through walls & floors). Will move it closer and see if the frequency of restarts goes down.