This is great, any release date or plans to make the schematics public? I’m looking at buying an Iotawatt but would like to get the esp32 version now!
I would love to replace one of mine with the ESP32 versions when available— all inputs are currently used, and it seems to reboot frequently due to a diminished heap.
But, for 90% of users it is unlikely to make a significant difference.
Just to ask the question, if you could get a grant to cover maybe half the cost would your outlook change on it at all? I know of at least one private foundation that supports sustainability projects and the IoTaWatt might be eligible.
Would a Kickstarter type approach help with the regulatory testing once the design is finalised?
You have the track record of delivering reliable product (and supporting it) iso it would be a highly credible project.
Kickstarter or equivalent would eliminate the risk of not recouping your investment - if enough people aren’t interested in pre-paying for a unit the project doesn’t proceed.
Hi Bob :
Great Stuff. Just ordered an IotaWatt system. Several items
We are early stage folks in this and would like to get some advice.
We will likely be sending the data to our cloud in AWS - and are using MySQL. We can do GETs from the IoTaWatt - but since we do need to have a webserver, are we restricted to Influx / OpenMonCMS / SolarPV ? Is there a way to have a generic webserver where we just insert the URL for teh data to be sent to ?
How can we get near “real time” data - say every 1 or 5 minutes - will the Query API be able to do that for us ?
I see that possibly the ESP32 development will help the HTTP issue - but will we able to install our own webserver in there or a generic webserver with a post URL ?
When do you think that you will have the ESP32 development complete ? At least dev versions - not certified by UL and also the final certified versions ?
Thanks so much
There is a REST query API.
Those are the supported uploaders.
Yes, you can query with 5 second resolution.
The firmware is open source. You can modify it as you please.
I have not committed to releasing that project. There are a lot of factors to consider.
Thank You Bob… We are looking forward to the ESP32 release.
is it available esp32 source code?
i’m trying to implement with esp32 olimex (ethernet) and it will be more easy start with esp32 code and not esp8266 source code.
Wired ethernet is a non-starter with IoTaWatt ESP32. The PHY requires practically all of the pins used for the SPI and I2C. While the I2C can be remapped, the SPI cannot. There are simply not enough pins to support both SPI and PHY.
If you want IoTaWatt with wired ethernet, I’d say port the code to an ARM chip.
first of all thank you for your time and for the project.
But, why not to change to this type of ADC ADS7138-Q1 that uses I2C protocol and solve the problem with SPI ports?
Looks nice on paper, The devil is in the details.
thak you so much.
I will try to test ADS7138-Q1.
is it available on repo ESP32 code for Iota?
It is not currently available.
That ESP32 is certainly a solid upgrade. Would the use of it give improved resolution of data verses the ESP8266 currently? What I mean is if there is a brief power blip would it be able to capture that and record it?
i have studied the new pictures of the ESP32 version. It seems like the new version use mora than one cs pin for the SD and you use 2 pin more for the expansion board for using 28 channels, and maybe this is the reason because there is no enough pins for use RJ45 version. Is it true?
maybe if we don’t use the new expansion board and use the SD card as the old version, can we use RJ45? best regards and sorry for to be so intense. But we need 150 iotawatt with RJ45 and we are currently working on this(if you would have this version we will buy it, but there is no version and we are trying to implement it)
It’s not that I don’t want to add ethernet, I just can’t see how it can be done.
You are correct. The SD is now MMC, which uses 6 pins. It could be run with standard SPI, which uses 4 pins, so assuming the second SPI can be utilized, and that the pins can be relocated, That frees two pins.
The are two additional pins being used for ADC CS on the expansion board. That’s another two pins for a total or 4.
The LED is currently using two pins. An I2C expansion board could cover that. Two more pins, now we have 6.
GPIO34, 35, 36 and 39 are available but are input only., so can’t be used to reroute existing functions.
The LAN8720 PHY requires 9.
If the SD were moved to the same SPI as the ADCs, you would pickup three more, but the way the ESP32 firmware works is that one of the processors samples continuously, monopolizing the SPI. To do SD I/O would seriously degrade both sampling and SD access to the point that except for having ethernet, there would be little advantage in going to the ESP32.
SPI based ethernet might be possible. That would require degrading the SDcard from MMC to SPI and sharing it with the ethernet. That might be the only viable option if it’s possible. I haven’t really looked at it very closely.
In terms of the project and what folks seem top want, the expanded inputs is easily the top priority.
I just wrote a table, with possible pin mappings if you wanted to have ethernet without having to reinvent the wheel. You’ll notice I have not used GPIOs 1 or 3 because they could be used for serial debugging, but they could be reassigned for MMC access to the SD card. Also, in case you want LEDs, I would use an I2C IO extender (much slower changes needed) to drive them along with other possible buttons.
I know your design is well underway, but the problem we have in Europe is our electrical boxes are much smaller and are pretty crowded, meaning WiFi is a bit more compromised.
As a bonus, if we could somehow add isolated PoE, that would greatly help with certification, as the iota’s power supply could be outside of the electrical box. With the added benefit that if your PoE supply is on an UPS (as mine is) you could be notified by the iota when you have a power cut
Thank you for being so supportive!
OK, that’s interesting. Couple of things:
I use the ESP32 WROVER with 4Mb PSRAM. It’s not obvious in the docs, but uses GPIO17 internally as CS for the PSRAM on the flash SPI. That’s shown on your diagram as ETH_CLKIN. What is that? My limited research on the LAN8720 PHY describes it as “NC - Osc. Enable - 4k7 Pulldown” If it’s an input, maybe it can go to 36 or 39?
I also show GPIO0 fixed as “EMAC_TX_CLK”. Can you clarify that?
Finally, if GPIO0 is needed for EMAC_TX_CLK, where can the SD_SPI_CS go?
One thing that comes to mind is that using 4 GPIO as CS for the ADCs can be done with three using a decoder. Two GPIO specify the ADC (0-3) and the third is the actual CS. It would require more pin setting in the sample routines and would have a small impact on sample rates, but that’s not a big problem as the ESP32 is a little faster than the ESP8266 anyway. But it does involve adding yet another chip.
So far we’re talking adding an I2C GPIO expander (most are pretty large 16 output affairs) and a decoder chip for ADC CS, as well as the PHY, RJ45 connector and probably a handful of caps and resistors. I don’t even want to talk about PoE.
This is basically back to the breadboard. It’s probably a couple of month project at best to get to a working PCB, and the enclosure would need significant mods, if not a completely new mold ($15,000).
Just to put some of this into perspective.
I’m not pressing hard for either Ethernet or POE but you could just provide a set of headers from the magnetic jack and a set of headers for the 5v and ground, where a “hat” could be added for POE. (See Raspberry Pi 3/4).
If you wanted to include a POE circuit, this works well and provides a decent isolated supply.