ESP8266 async web server

For anyone messing around with ESP8266 (or ESP32), I’ve just got a version of IoTaWatt running with ESPAsyncWebServer. This a completely event driven version of the web server that pretty much eliminates blocking for most of the activity. It’s blazing fast and makes interacting with a web app nearly instantaneous, including moving small files back and forth.

If you are interested in using this technology, I have a version of the ESP8266 example SD web server adapted to use the Async server on GitHub. ESPAsyncSDWebServer

2 Likes

Looks perfect for making progress on my project Bob, given that I’ve not had the time to sit down to build and merge libraries myself I think we should have a chat sometime over the phone!
Where are you based?

Just trying to upload your IoTaWatt v2.1 sketch to an ESP, missing library IotaList.h is the problem. Where can I find it?

I have to say, great work! I’ve seen the hardware and case you’re developing too, very tidy!

ESPAsyncSDWebServer works great, thanks.

Sorry about that. I’m a complete GitHub slob. I need to reconfigure so that I am working directly out of the Gits instead of coding on the side then moving the results into GitHub. I’ll put that on the list if I can find the end. You should be able to compile IoTaWatt now.

Async SD web server is an adaptation of the standard SDWebServer that is in the ESP8266/Arduino example collection. You have to be careful about not YIELDing or DELAYing in the handlers and you have to be aware of context. The non-async version is more forgiving in that respect and is not completely event driven (although upload works pretty much the same way), so you may want to consider the pros and cons before committing to one or the other.

Yield or Delay would be useful to pause one part of a program while running another?
I need to adapt your IoTaWatt v2.1 to make progress with mine I think, although the web server is useful… The IoTaWatt has an SD card for storing data?

The version of IoTaWatt that you have incorporates the non-async version of the web-server. I have a version with the async server but there are problems that will be better dealt with when I port this to the ESP32, so the 8266 version will continue to use the non-async version.

IoTaWatt is basically a datalogger so it does have an SDcard and a real time clock. One version uses the AdaFruit feather components. The latest uses a traditional nodeMCU with the SD and RTC integrated with two ADCs on a single board.

Sampling of DC voltage and current is much simpler than AC, so you shouldn’t have much trouble adapting and should be able to up the sample rates considerably without the need to sample whole cycles.

True, simple maths and regular intervals.
I’m considering putting an rtc on my main now too… Should be very useful.

The RTC is the difference between a meter and a datalogger.

At first glance, and depending on the accuracy expected, it looks like you could condition the data to come directly in on a couple of IoTaWatt channels. The voltage is easy, as you are currently doing in your circuit, just dividing the voltage with resistors. Removing the inboard burden resistors and bias voltage divider on a couple of channels you would have a 3.3V 12bit ADC that could be used full range. That’s 15mv per count on voltage at 0-60V. Current ditto with about 24ma per count at say a 0-100Amp range. I might be inclined to add some diode protection and maybe a filter to keep out any AC but that’s trivial as well.

The code accommodates different types of channels. Currently there are voltage (VT) and current (CT), but I have always had in mind being able to do 10K temp and 4-20ma inputs. You can add a new enumeration to the type list and code sample routines and outputs to match. I don’t see why everything else wouldn’t work - logging to SD, uploading to eMonCMS, status display.

That’s it. 12bit is an easy and worthwhile step up from the Arduino’s 10bit I have currently. I’ve continued to use the Arduino because it’s sending TX RX to the RFM69 chip, and happens to have ADCs, and it was already implemented so was convenient.
For the next version I could have the ESP sending to the RFM? I’m unsure if the sending TX RX to the RF is particularly intensive for a microprocessor, but I doubt it. Then space is freed up for a 4 channel 12bit ADC, the minimum required.
I like the decision to go for an 8 channel ADC, adding flexibility for other inputs as you describe, and in that vein of thought I’ve tried to make accessible the various pins remaining on the Arduino. So far I’ve been trying to fit everything onto one board for cost reasons and to have a board geared at battery/generator applications and not much else. Other inputs and outputs would be useful, for example, in over-voltage detection and cutoff to protect the board from open-circuit solar or wind voltages at max output.

I’m coming around to the multi-shield design, as all these components take up space. Perhaps in future versions I’ll look at this again.

Ha, and just have an IoTaWattDC. If I was to use your IoTaWatt perhaps I’d have to design a feather for the ESP, power supply and shunt monitors, if that’d even work. I mustn’t entertain too many options at this point I don’t think. Too close to actually having a finished board hehe.

FYI changes to use ESPAsyncWebServer are imminent: OpenEVSE merge by jeremypoulter · Pull Request #24 · openenergymonitor/EmonESP · GitHub