Those who have stuggled to reconcile that the server generates the whole image and the display is dumb and provides no input with the fact that there's battery information from the display should pat themselves on the back now.

Before the display requests the EPD data it sends a GET request with query parameters and one of them is the battery charge information. I did think about uploading its log but in my experience that's great until the thing that breaks is the log-uploading and then you're still back to reasoning if there's network problems or something else.

Sleep

While we're on power I've not mentioned sleep currents. The EPD claims less than 0.1uA. It must be true as the Fluke meter I used has a noise floor about that level. The WiPy claims 7uA. This is unfortunately not true. WiPy + expansion board + SD card gets me 700uA. The SD card can't be powered off - I was originally going to use that for logging but I can save 150uA by losing that. The resistor network measuring the battery voltage is using 40uA which I could have removed or switched if I was feeling keen. The actual charging IC appears to be using 200uA, still leaving (roughly) 350uA left.

This was pretty disappointing, and I've not seen any satisfactory response from the WiPy manufacturers to the posts I found on their forum about it. Maybe there's a new hardware release that fixes this. Or maybe they copied off the sleep power stats of the TI SoC and didn't consider what their board actually uses. Who knows?

In the end I solved it by using a bigger battery and deciding that charging it more often isn't the end of the world. This did have the advantage that the bigger battery coped better with the startup of the WiPy.