For the record: I build 3 IotaWatt from the schematic. Slightly altered so i could use through-hole components and i introduced 3 dedicated VT Channels.
1 of them is logging to a emonpi through serial (usb) and 2 of them are logging via Wifi.
Sometimes the upload via wifi fails, this happens (mostly) when the wifi is failing in the esp (i cannot reach it anymore), but the esp is still running since the serial output still works.
A hard reset (unplug the usb and replug after 10seconds) makes it work again. (i can reach it through the interface).
However, sometimes the emoncms upload keeps failing (EmonService: GET failed. HTTP code: read Timeout)
It seems that setting the server to none, saving, and setting it back to emoncms (and putting the emonpi url/api key back in it) solves it instantly.
This method however has a major drawback: the data from the āfailedā time is not transmitted anymore.
To know when it happens i made a little script on the emonpi to check every 10min if a feed is inactive for more than 20min. The last 2 times were today (jan 30th) and jan 22nd.
The curious thing is also; they all seem to fail within a timeframe of a couple of hours of each other.
So my question: any ideaās why a start/stop of the emon service works better than a complete reboot (unplug power)?
That is no longer an issue in the latest release of the firmware. Previously, The IoTaWatt would start from the present time when a new server is defined. Now the server is queried to find out the latest update time of all the inputs on the node, and the upload starts uploading data from that time or the earliest available after that. Itās been working pretty well. In fact, if you have a complete current log on your system, you can delete the inputs and feeds and restart the IoTaWatt to upload all the history again. You need to prime the inputs with a manual update from the time you want to start)
The only mechanism that I can suspect of causing your symptoms was replaced by this new functionality.
The stalled communications may also be something that is remediated by more recent firmware. I keep increasing the timeout period and itās quite long now. Iām reluctant to try to fix it any further within the constraints of using synchronous HTTP. Iāve got a version using asynchronous TCP. It works very fast and has hardly any effect on sampling, even while allowing an upload several seconds to complete. Thatās the future.
Donāt know what you are using for an IDE, but the Github site has the necessary platformio files and Iād strongly advise using that environment. In the transition fro 02_02_26 to the current release, a newer ESP/Arduino core was used, among other things to pick up the fixes for the Krack vulnerability.
The new core has about 9 months worth of updates and fixes in it, and it triggered a few incompatibilities in IoTaWatt. A couple of the fixes were not backward compatible to the old core, so if you have to change the core that you use at the same time as you assimilate the updated modules. PIO takes care of that, like magic. It gathers all the stuff up from Github and makes it all work. Amazing.
I tried the Platformio once when the IDE wouldnāt work (because of the incompabilities), but for some reason it wouldnāt workā¦ i downloaded the latest esp core files from the git manually and the IDE worked again.
Havenāt tried the Platformio since, but iāll give it another try
and see if this small glitch is fixed!