boblemaire / IoTaWatt

IoTaWatt Open WiFi Electric Energy Monitor
https://iotawatt.com
GNU General Public License v3.0
640 stars 177 forks source link

Retention policy not properly queried on reset #266

Closed brendanpward closed 4 years ago

brendanpward commented 4 years ago

Found this bug as my IoTaWatt resets on occasion and begins re-uploading all of the data to influxDB beginning at the "upload history from" date. Wireshark collected the following after a reboot:

POST /query HTTP/1.1
host: **myInfluxDBserver**:8086
Authorization:Basic **myInfluxDBpassword**
Content-Type:application/x-www-form-urlencoded
Content-Length:63

db=iotawatt&epoch=s&q=SELECT LAST(value) FROM Clothes_Dryer_kwh
HTTP/1.1 200 OK
Content-Type: application/json
Request-Id: 19383a69-7c73-11ea-bca8-0242ac1e2101
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.7.10
X-Request-Id: 19383a69-7c73-11ea-bca8-0242ac1e2101
Date: Sun, 12 Apr 2020 04:07:17 GMT
Transfer-Encoding: chunked

{"results":[{"statement_id":0}]}

I found that the reason for this is because IoTaWatt was not selecting my retention policy as it's a non-default policy in influxDB, and the code currently does not specify the policy on query.

Queried with the retention policy:

POST /query HTTP/1.1
Host: **myInfluxDBserver**:8086
Authorization: Basic **myInfluxDBpassword**
User-Agent: curl/7.66.0
Accept: */*
Content-Length: 76
Content-Type: application/x-www-form-urlencoded

db=iotawatt&rp=One_Month&epoch=s&q=SELECT LAST(value) FROM Clothes_Dryer_kwh
HTTP/1.1 200 OK
Content-Type: application/json
Request-Id: 2cb2499d-7c7f-11ea-8429-0242ac1e2101
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.7.10
X-Request-Id: 2cb2499d-7c7f-11ea-8429-0242ac1e2101
Date: Sun, 12 Apr 2020 05:33:44 GMT
Transfer-Encoding: chunked

{"results":[{"statement_id":0,"series":[{"name":"Clothes_Dryer_kwh","columns":["time","last"],"values":[[1586669620,3e-7]]}]}]}

This modification should now insert the retention policy into the query.

boblemaire commented 4 years ago

Hello Brendan, good pickup, thanks for debugging and doing a PR. Just wondering if you tested this without a retention policy specification when the String pointer will be null. Unless I'm overlooking something, I think it will blow up the printf. I think yopu will need to break up the existing printf into two and add a conditional printf between to insert the retention policy conditionally if one exists. See how it's done in the sendPost state.

brendanpward commented 4 years ago

Right . . . I think I'll be breaking more than I'd be fixing with this current code. Thanks for pointing this out. I'd missed that the retention policy was optional and could be null. I'll get that case tested and if necessary, break it up and set the conditional printf as you suggested.

boblemaire commented 4 years ago

Putting together next release I took care of this. Closing.