ESP32 for more power?


I see you’re trying to boost the ESP8266 in terms of performance, overclocking and so on.
Since the ESP32 is the big brother and it costs roughly 3-4 usd dollar more, why dont you try to use it? Most of the library you are using are compatible with both the uC.
What do you think?



It’s on my radar. I have a bench prototype IoTaWatt that uses the ESP32. I play with it in my non-existent spare time.There are many considerations in moving to the ESP32 from a hardware, software and business perspective.

Hardware: The major attraction with the ESP32 isn’t the extra processor or FPU, it’s the MMS Sdcard. The simple SPI SD interface of the ESP8266 is a major bottleneck. With the ESP32 MMS SDcard, the whole datalog facility and webserver would be blazingly fast. In fact, this is the only significant advantage I see over the ESP8266. It looks like the ESP8266 tolerates 160Mhz very well, so there’s still plenty of processor power available.

Software: There are some problems with converting a firmware like IoTaWatt to ESP32.

  • I use the asyncTCP libraries for client communications, and the most recent chatter is that the underlying SDK has problems with that. I haven’t investigated this at length, but it could be a major issue. Perhaps with the two processors, I could go back to synchronous TCP, but that’s a major backward step at this point and a lot of change.
  • IoTaWatt samples the ADCs with SPI using the bare metal interface for speed. That is not portable to the ESP32 and would require a lot of investigation to replicate, if it’s even possible at all. Without that, the sampling rates would be less than half what I get from the ESP8266.
  • The IoTaWatt firmware itself is basically an operating system, and the synchronization relies on single threading the services and sampling. I’ve got plenty of experience with multiprocessor operating systems and synchronization, so I know what a job it can be to retrofit and debug that in a uniprocessor firmware.

Business. This is the show stopper. It has taken more than a year to put together the current hardware device, develop a manufacturing program, and to gain the approvals and certifications needed to sell it to make it available to the public. The cost has been tens of thousands of dollars. That all goes out the window with an ESP32 design. The clock starts over and the costs are replicated.

I’m not saying it will never happen, but it’s a big move, and maybe it would make more sense to port to something else that has more capabilities like an ARM processor. We have a saying in New Hampshire - “good enough”.

But it’s all open. Go for it.


Just my two cents:

  1. I use AsyncWebServer which is based on AsyncTCP library i dont know which problem you are talking about but since july i havent had any problem on it.
  2. It is not clear if you are saying that SPI is not developed for ESP32 or not but to me it seems there.
  3. Certifications are indeed a pain in the ass especially the Wifi part. Surely not having the 230V as power supply is a huge help in your case.

Anyway i get what you are saying, it’s just that we could use so many powerful algorithms that current energy meters/line analyzers (under 500 euros) can only dream about.


I published an SD adaptation of that server more than a year ago, and it works fine. I’m not dissing that effort, it’s great. But it’s not a product of or included in the official core. Me-no-dev has done a great job, but is limited. There has been some discussion lately of LwIP2 not being properly synchronized for multi-threaded operation. I haven’t been following it in detail, because my problems with LwIP2 in single-threaded operation took precedence. As I have ironed out those problems, and fixes have gone into the core, it has become OK for me. I think I’ll wait a spell and leave the bleeding edge to others. The symptoms I saw were problems under heavy load.

I’m saying that I do SPI on the ESP8266 using the hardware registers for speed. Stuff like this:

          // hardware send 5 bit start + sgl/diff + port_addr
    SPI1U1 = (SPI1U1 & mask) | dataMask;               // Set number of bits 
    SPI1W0 = (0x18 | Vport) << 3;                      // Data left aligned in low byte 
    SPI1CMD |= SPIBUSY;                                // Start the SPI clock  

          // Do some loop housekeeping asynchronously while SPI runs.

I have made inquiries about how to do that on the ESP32 and it will require that I do an NDA with Espressive and do a lot of reading. It is true that I could use their SPI class, but my point is that is slower and would result in more granular sampling, which compromises accuracy. The processors themselves are the same as the 8266, it’s just that you get two of them, so it’s not inherently faster for something like sampling.

It’s true that certifying a low-voltage device is way less expensive and complicated, plus I don’t believe I have the skills to build a certifiable high voltage device. Nevertheless, most of the certification and regulatory approvals are really just cash cows for the NRTLs. They have it and they know you need it, and then you have to get into a regular inspection and renewal scheme because their business models are based on recurring revenue streams. It really isn’t a technical thing.

Most folks are simply not interested in that.


Wifi Alliance is a ****ing robbery for example!
Anyway i got your point.
I’ll probably buy 2 of your unit in the near future, are you expecting major hw improvement in the near future?
Before opening another thread about this i would like to know if there is a way to also sample the voltage of a load (12V batteries, panel voltage), for example by removing the shunt (if any) or burden, or somehow. One of those will be used on a solar panel system so it might be really useful.


Anyone on the last voltage part? @overeasy


Sorry. Doesn’t do DC.


I am curious if using the 18 input 2 channel ADC built into the ESP32 is not a viable option at some point in the future? Or is there some hardware reason that it is not good enough compared to the external MCP ADCs?

I understand your reasons for not switching to the ESP32 after all the work invested into ESP8266 and the less stable development environment of the ESP32.


IoTaWatt is primarily a software project, and itdifferentiates from the rest in low cost and ease of use. As an energy monitor, the MCP3208s produce excellent results and are really not a factor in overall cost. When you sharpen your pencil and look at the big picture, there is no advantage.

I haven’t tried out the internal ADCs of the 32, but on paper they look like they could do an adequate job.


I agree with your reasoning, the MCP3208 cost is not high… I mainly just had an ESP32 already and it would be neat to be able to install your software on the dev board with only a few passive resistors.

I have just purchased one of your monitors from and look forward to testing it. I can see that you have put allot of work into the software side of things and it looks like a well maintained project!

I am already running influxdb and grafana on my domain with some custom hardware I made two years ago using emon library on ATMEGA328 + ESP8266 to send the data via MQTT.

Is this forum a place to discuss possible mods to the firmware for install on custom hardware or would you rather that be done on other forums?

Here are some pictures of my custom device made in 2016, this type of LCD is $2.5 and I like the real-time data aspect without having to use the web interface. Maybe for version 2.0 of Iotawatt consider adding a screen.


The firmware is open, so folks are free to fork it and do as they please to add features or support. There is a homegrown IoTaWatt category for those projects if you would like to make your efforts visible to the community.

The firmware is modular, so specific portions can be modified without impacting other subsystems. The sampling of ADCs is entirely contained in one module, so a project to use other ADCs, including ESP32 internal ADCs, should be limited in scope. That said, moving to a multiprocessor lokethe ESP32 presents new synchronization challenges that could break many parts of the existing firmware. Restricting to one processor is an obvious solution, but then each of the ESP32 processors are identical to the ESP8266 processor…

As far as the master branch that I maintain, I’m committed to keeping it as simple and low-cost as possible and avoid mission-creep that I believe adversely effect other similar products.