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. 
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.
