I’ve taken a look at the log and config. There’s no smoking gun with respect to cause, but there are a few issues that, if addressed, could resolve or at least reduce the frequency of this problem.
Looking back at your log, you have had pretty serious communications issues for months, with frequent restarts because of high error counts attempting to post to Emoncms. With the latest release 02_03_13 we get a look at he WiFi quality and it’s not great. The RSSI on connect is typically -80 to -85. The new low level LwIP in this release also seems to be doing a better job, but at each restart, Emoncms updata is still typically 1-2 hours behind.
I’m pretty sure the high error retry rates are eroding the heap memory. There are a few things you can do:
improve the WiFi signal strength. Usually that means moving the router closer to the IoTaWatt or connecting a bridge appliance to relay the signal. I do that for a system that is in an outbuilding and it makes a huge difference.
Change your bulk send parameter to something like 6 to reduce the number of transactions to Emoncms.
Get a local instance of Emoncms by using a Raspberry Pi or other local platform. Since you have the IoTaWatt to measure power, you don’t need to buy an Emonpi, you can just get a Pi 3 and download the SDcard image from the OEM site.
The memory problems may go away in time as the new core with LwIP-2 matures, but aside from the entries in the log, restarting is a pretty low impact way to avoid more serious problems if the heap runs out. It literally takes a few seconds and you get a fresh start. For the record though, test systems here have run for from a week to ten days without incident and without losing any head at all. So I’m curious to see how this works out.