IotaWatt Alternatives

With the sad-for-us, exciting-for-Bob news of the end of production, I’m looking for alternatives. I’ll post my research below, but would be grateful for feedback on what others are using as an alternative to IotaWatt.

My requirements are:

  • 14+ CTs of varying sizes
  • Three phase capable
  • Open-source software, or at least editable to post to results to an influx database
  • Reliable and fail-recovery like IotaWatt!
  • DIN rail mount an option

Some options are:

  • CircuitSetup - looks good, expandable, add an ESP32 on top and post to influx. Some software for the Esp32 to post to MQTT and configure via webpage, but likely fair bit of development to replace IotaWatt functionality (influx, reliable, 3 phase derived). :expressionless: :slight_smile:
  • Shelly - professional and DIN rail: great! Only a few CTs of fixed size :frowning:
  • Emporia - domestic, apparently polished product. Many but fixed CT sizes. Proprietry. :frowning:
  • IotaWatt Esp32 - long term option, in development and unclear future atm. :expressionless:
  • Your-great-find - let me know!

What did I miss? Has anyone tried these options? @overeasy, your technical thoughts on the options would be greatly appreciated.


Brett from Australia

You could use Modbus meters like the SMD120 and pull the data out of it with a Raspberry Pi running Emonpi software and data logging with MQTT, I have been doing that awhile, you need to set each Modbus meter it’s own ID.

I’ve been thinking about this for a while - Not because I think there’s anything wrong with the IotaWatt of course, mine has been working great for years except for a recent SD card issue and of course the persistent issue with user error. :slight_smile:

But I’m not an embedded engineer and I have different set of priorities when I architect things. What Bob has achieved is an extremely efficient and robust product which squeezes just about all of the available capability out of what is a very limited microcontroller, the venerable ESP8266.

The ESP8266 is cheap and easy to get, but since the inception of the IotaWatt there are now other options including the ludicrously cheap RP2040 which has much more memory, two cores and includes the fantastic PIO blocks.

Now in my own use I absolutely adore the built-in graph functionality - The fact that the IotaWatt can be used completely stand-alone is an incredibly important feature to me. It isn’t just usable as a stand-alone device, but it’s very capable when used in the way. The limitation with this is that you’re limited to 13 inputs (Or 11 inputs with three phase) and even more limiting, every CT must connect back to the same physical location.

In most cases this is probably fine, but if like me your property is split over multiple buildings there are practical limitations which get in the way - Both the practicality of running cables everywhere and also the distance limits for CTs. (The SolaX X1 G4 Hybrid inverters for example suggest a maximum CT cable length of just 25 meters.)

SolaX get around this problem by using Modbus via the supported Chint DDSU666-CT meter. But there lies another problem, so many devices these days (EV chargers, solar diverters, hybrid inverters) require CTs on the mains supply. Wouldn’t it be nice if we could support Modbus inputs for long distances, and possibly even use Modbus in a read-only fashion where another device such as a hybrid inverter is already polling the meter so that a single meter may be shared?

The other side of this is wouldn’t it be nice if we could have multiple IotaWatts all feeding data into a central IotaWatt, where the graphing was still a stand-alone hardware device with automatic updates and all of that good stuff. Something which is low power, reliable and easy to deploy.

… Which leads me back to the extremely low cost RP2040 and it’s lack of networking. What if we had a port of Bob’s fantastic measurement engine, capable of running on the RP2040. This would be a dedicated measurement and collection device, which could use the built-in four channel 12-bit ADC for three phase voltage measurement and an external MCP3208 for CT inputs. It could also have Modbus and pulse inputs, along with some configurable outputs. (Turn this output on when the mains reading is below 200mA for solar diversion, etc) Finally the main interface could be SPI. No data logging, no UI.

Then you can have a separate processor who’s sole job is to log data to an SD card - Or maybe a pair of SD cards for redundancy. Maybe this could have two SPI busses - One which it can use to ask the collection engines for the latest (buffered) data and one to which it can respond to read requests or commands.

The finally you might have a networking processor, (ESP32, or an RP2040 with a W5500 ethernet controller) which handles the UI, uploaders and any inter-device communication. (This could have the outputs instead of the collection engines.)

Some might call this architecture wasteful, and indeed compared with the current IotaWatt implementation it is extremely wasteful if that’s the metric you prioritise. But I’d counter by saying that it provides defined responsibilities. You can have multiple collection engines running, the UI or uploaders cannot impact data collection or sample rates. You can have collection engines running in multiple locations while communicating across a slow data link as long as they utilise a time server.

I’d be interested in what people think of the idea. Like I say I adore the IotaWatt, but my non-embedded-engineer brain sees the possible architecture from a slightly different viewpoint and now that the IotaWatt is to be discontinued, maybe it’s time to consider what it can become in the future based upon the foundation which Bob has built and graciously released as open-source for us all.

1 Like

I’m working on an open source energy meter. I was greatly inspired by the IotaWatt. My ideas are similar to what @yngndrw describes.

HCT21 Features:

  • 3 CTs per unit at present, up to 12 voltage or current sensors per device will be possible with a future design
  • LoraWAN for site-wide wireless coverage and low power.
  • Self powered with battery backup. Energy harvested from CTs
  • Non-contact voltage phase sensing OR connect to a 24VAC transformer
  • Open source, and modular for repair and reduction of future ewaste
  • 3 MCUs - one for sampling, one for network that runs Micropython, and one for LoraWAN
  • Integrates well with The Things Network, node-red, InfluxDB, and Grafana

For more details, see the HCT21 development update.

At present it is about $127 to buy the parts to make the 3 CT version. You also need to have one LoraWAN gateway per site, about $79-$250.

If anyone wants to purchase one for testing for $150, I’d be happy to send you one and help you get it running, as it would help my development efforts to have a few people trialing the hardware and understanding what features are useful.

Thanks everyone!

Has anybody looked into the OpenEnergyMonitor project, and their boxes?

I’m still trying to figure out what bits you need, but apparently their current/newest models are either the EmonTX V4, or the emonPi2.

It’s open-source, and you can buy ready-made units from their shop:

The base emonTX V4 supports 6 CTs, but there’s an expansion board that adds another 6 CTs for a total of 12.

There’s a discussion thread about the development of the emonTX V4 as well (started back in April 2022):

Funny thing is I bought my first Iotawatt from the OEM shop. A long time ago these two projects were closer. Let’s just say there were some differences of opinion about what is the correct way to measure power/energy. (Or perhaps shorter still, irreconcilable differences). has the GEM. I have their older product ECM-1240. A decade+ ago their stuff was great. Looking at it today, it doesn’t seem to have advanced much.

OEM doesn’t seem to have made much progress in the last 5+ years, but their stuff is available and if you want accurate information about your mains it is great.

I use Sonoff Pow2 devices on small loads to get information about them. But, again it depends on what you are trying to see/understand/learn.

I was looking at picking up a second iotaWatt but now I just ordered the Emporia Vue Gen 2 and will be flashing ESPHome to it, and pulling data into Home Assistant and push to influxDBv2 for long term reporting. My iotaWatt data for the last 2.5 years exists in influxDB already. So this is probably the cleanest and gets rid of all the cloud requirements.

@frogmore I didn’t know much of the history here - do you know what some of the differences of opinion, or approaches were, between OEM and IotaWatt?

What do you feel are some of the limitations with the current OEM gear?

I am not really familiar with the current gear OEM has. The big reason I went with Iotawatt is the number of channels and the cost of it.

There are likely still threads on the OEM forums if you are really interested. I believe the comment I made at the time was, “it sounds like you are arguing about how many angels can dance in the head of a pin”. The basic concern of some was that Iotawatt doesn’t sample continuously across all channels. For very unusual loads, this could give an inaccurate picture of the load. For normal loads it isn’t an issue. Most loads are normal enough, so I have no concern. It all comes back to how accurate does the data need to be for you to derive valuable information that will lead to a change, or more simply what are you trying to find out and how much are you willing to pay. There are tradeoffs and costs for any system. Be clear about what you want and what it costs to get it.

1 Like

@frogmore @victorhooi

I’m going to ask that you take this discussion to a PM.

1 Like