Current Sensing Transformers & EmonESP

Current Sensing Transformers & EmonESP

I’ve been upgrading my home power monitoring software a bit, as it looks like there are some new options out there for the ESP8266.

Previously, I was using an ESP8266 with the Espressif AT firmware, available at their website: https://www.espressif.com/en/support/download/at

Espressif also publishes an API reference for said firmware on their website as well. It looks like it’s even still being maintained – the AT Firmware API reference was last updated in August of 2020.

You can see the code I used to interface with this AT firmware at my Github repository. Currently, that code runs on a Teensy 3.2 and pushes data using the AT firmware on the ESP8266 to an Emoncms server hosted on a Raspberry Pi. This method requires the generation of all sorts of AT commands and gibberish to get the ESP8266 to make a HTTP GET request to publish data to the Emoncms server. The main issue with this method was the fact that I was never able to get the ESP8266 to reliably reconnect to Wifi if the power went out. Essentially the ESP8266 would come up first, look for the Wifi network, get confused and just not play nice.

I’ve been watching the development of EmonESP for a while – essentially the folks over at OpenEnergyMonitor wrote some great stuff that runs directly on the ESP8266 and provides a web UI that works great. What I’ve really been loving is the fact that there is a passthrough serial connection – so I can talk directly to my Teensy 3.2. This means I can remotely calibrate channels on the unit without re-flashing the unit, like I did before (great code writing by me… not).

So after firing up Visual Studio Code with PlatformIO, I compiled the EmonESP for my device… and found a couple of issues. First, the path to the Emoncms server functionality was broken, so I made a fix and a pull request to get that fixed. Another issue was the fact that ArduinoJson (a great way to easily work with JSON on your Arduino or other microprocessor, FYI), declares sizing for objects up front – so the EmonESP implementation wasn’t cut out for my 20+ channels of data. Before, in src.ino in the EmonESP codebase:

  StaticJsonDocument<512> data;

  boolean gotInput = input_get(data);

512 bytes got me about 16 channels of data + EmonESP diagnostic data. I’d like to keep the EmonESP diagnostic data it adds, plus some extra data for channels of temperature or other data. I sized it at 1024.

This worked great! I’ve rewrote my code that runs on the Teensy 3.2 to hand off data in key:value pairs to the ESP8266 running the modified EmonESP software. That new sketch is located here.