Hi Jeremy,
for esp 01 module( blue or black) flash size is too low to be able to load emonesp firmware and html data. You have to use ESP-12E with 4M flash size for this application, the same chip used in Huzzah module.
Best regards
1 Like
I’m currently thinking about adding an ESP8266 to the EmonTX 3.4 I’ve recently installed instead of the RFM radio. It’s rock solid, but I have a WiFi AP nearby the electricity compartment so it’s just a little more convenient than the RF+base station hardware combo. Though then I’ll need a DC adapter.
But why I posted is that I compiled the EmonESP firmware in PlatformIO and it compiles to about 375kB (spiffs included), so it should fit in the smallest of the ESP boards even with 512kB, in theory. Which is good since the 01 modules are available for a few beans. It’s worth a try, at least.
Hi,
I used arduino ide to load emonesp firmware and data in several ESP-07 and I couldn’t make them work properly. When I loaded firmware and data to ESP-12E everything works as expected. Somewhere in the installation instruction guide is mentioned that should be used ESP-12E and I can confirm and advise that from my own experience.
Best regards
Cracked it last night, now I have the power sorted it the ESP-01 can read the values from the EmonTX. Need to get it setup in place and do some more tests.
As mentioned the current incarnation of the EspEmon firmware is ok to fit in 512MB flash. I am not totally convinced OTA will work but that is one of the things to test.
Will post some pics, wiring and a PR later today.
Jeremy
I don’t think you’ll get OTA working on the 01.
For as much as a beer you could be buying these instead - http://www.banggood.com/D1-Mini-NodeMcu-Lua-WIFI-ESP8266-Development-Board-p-1044858.html?utm_source=google&utm_medium=cpc&utm_campaign=Celc-ad-rm-DM-D1MINI&utm_content=gary&utm_design=27&gclid=CJHvjJ_0-M0CFUa6GwodkMIGag
£4 postage paid. You can’t go wrong. The 01 is false economy.
Simon
For information here is how you wire up the ESP-01;
and a pic of my setup;
I have also raised PR #8 with the changes I needed to make, just really adding the ESP-01 as a board for the project.
I am seeing an issue where it works for a while but then starts reporting key ‘1’ with a value of ‘0’ repeatedly very quickly. Not too sure if that is the EmonESP or EmonTX. I do have a Huzzah board so will give that a go and see if I get the same issue.
Nice! I’ll get the pr merged to allow compiling for 01 using platformio 
There is a big update to emonesp in the mqtt branch that I’ve been working on that is ready to be marged into master branch very soon. As the name suggests mqtt support has been added as well as captive wifi ap portal, multi emoncms server and ui overhaul.
Is there any chance the EMONTX sketch can be modified to provide a current AC voltage output so the AC adapter can be calibrated?
Also I think there is an error around the ct2 calculation area as the next ct3 section references ct2 rather than ct3
Is was going to get on to this after the EmonTx OTA was done, I also wanted the temp stuff as well. In fact, @glyn.hudson, is there any reason we could not merge the EmonESP support in to the other EmonTx firmwares and just protect it with a #define or even better add a run time switch, sent over the serial, to enable the EmonESP output?
+1 for the temp stuff
You mean the present (= at this instant) a.c. voltage? - The default sketch does. If yours doesn’t, it’s easy to extract it as it is already calculated by emonLib in the calcVI method, and then you simply add it to the rest of the data going to the WiFi module.
And I very much support Paul’s plea to aim towards a generic solution for sending the data onwards.
Yes, the present AC voltage appears absent in the ESP serial only sketch. That and the 1-wire missing means I’ve changed one of the standard sketches for now. The ESP serial only sketch seems based around the continuous sampling firmware which I was hoping to upgrade to for better accuracy.
There are some significant errors and shortcomings in the CM library as it stands, it is recommended that you do not use it. (If you’re right, then why it has been used for the ESP is beyond belief.) I am still working on it. The core of the library now appears to be correct and capable of calibration, but I have yet to look at pulse inputs. It does not work with JeeLib, but appears to be OK with the slimmed down RFM code - though this might not bother you, I haven’t looked at the ESP so I don’t know how it works.
When working with the ESP all the Arduino needs to do is output the power readings on the serial port. The ESP takes care of the rest. In my case I only use it for power monitoring and one EMONTX has a single 1-wire temperature sensor. I could run the 1-wire in my setup off the ESP directly but that doesn’t turn it off inbetween readings which may result in a little self heating.
So far the ESP setup doesn’t seem to suffer from missed readings due to radio congestion like my 433MHz setup did
This is proving to be a great improvement over the RFM69 especially in a busy 433MHz radio environment.
I’ve just looked at a couple of graphs of the same feed before and after changing from the RFM69 to the ESP with skip missing and limit interval turned off. The dropouts which were very obvious with the RFM69 have totally disappeared since moving to the ESP. Zooming in to the graph reveals several missed packets per hour with the RFM69 and NONE with the ESP.
As I use the system to turn off loads via Openhab should consumption get too close to the 60A main fuse capacity this is a very welcome improvement.
It’s 3.8 days since I installed both ESP’s to my 2 EMONTX’s with no resets. I’m running ESPEasy V120 on 2 Huzzah’s with built in USB. This works happily with just 0V and TX from the EMONTX connected to RX on the ESP. Each ESP is powered from its own separate power supply.
I use ESPEasy rather than the suggested firmware as I will use the GPIO pins on the ESP to control relays via MQTT and Openhab.
Thanks for putting this idea out there
3 Likes
Sorry for lack of engagement, I have been and still am travelling away. @TrystanLea created the emonESP emonTx example as a proof of concept. The use of continuous sampling code is still in testing. I will let Trystan comment on this.
I have just pushed an updated emonTx V3 discrete sampling firmware (V2.4) to the emontx-ds-emonesp dev branch to provide a version of the standard emonTx V3 discrete firmware that serial outputs serial string pairs to work with emonESP e.g:
ct1:xxx,ct2:xxx etc…
This includes vrms and all temperature readings:
+ if (debug==1) {
+
+ Serial.print("ct1:"); Serial.print(emontx.power1);
+ Serial.print(",ct2:"); Serial.print(emontx.power2);
+ Serial.print(",ct3:"); Serial.print(emontx.power3);
+ Serial.print(",ct4:"); Serial.print(emontx.power4);
+ Serial.print(",vrms:"); Serial.print(emontx.Vrms);
+ Serial.print(",pulse:"); Serial.print(emontx.pulseCount);
+ if (DS18B20_STATUS==1){
+ for(byte j=0;j<numSensors;j++){
+ Serial.print(",t"); Serial.print(j); Serial.print(":");
+ Serial.print(emontx.temp[j]);
+ }
+ }
+ delay(50);
+ }
I propose standardising on this serial output format for all units e.g. emonTH etc.
1 Like
The serial printing sequence (see above) I used to produce the string pairs is quite long winded. I experimented replacing the serial.print with printf e.g.
printf("ct1:%d,ct2:%d,ct3:%d,ct4:%d,vrms:%d,pulse:%u",emontx.power1,emontx.power2,emontx.power3,emontx.power4,emontx.Vrms,emontx.pulseCount);
This looks much tidier but resulted in the compiled size increasing from:
----------------
Program: 15558 bytes (47.5% Full)
(.text + .data + .bootloader)
Data: 1438 bytes (70.2% Full)
(.data + .bss + .noinit)
to
--------------
Program: 16870 bytes (51.5% Full)
(.text + .data + .bootloader)
Data: 1452 bytes (70.9% Full)
(.data + .bss + .noinit)
A significant increase, therefore I will keep using the serial print sequence as posted above. Has anyone been able to test this with the emonESP? Im currently away and don’t have an emonTx V3 to hand. Once tested I will merge this into emonTx V3 master branch firmware.
1 Like
Serial UART baudrate has been increased to 115200 to be compatible with EmonESP. We plan to standardise on this baud rate for all our firmware in the future. If testing goes well.
1 Like