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.
4 posts were split to a new topic: emonESP firmware development
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
12 posts were split to a new topic: Could emonESP also support CSV and post to a local emonHub?
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
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.
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.
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.
curious why reinvent the wheel - i hooked my esp8266 differently then you guys as I see no need to have the emontx arduino handle that. and let the esp8366 processor handle all the wifi related stuff including error correction and what have you ( two processors are better then one 
). . and simply as i do unplug the esp8266 from the emnotx to program it , its easy and simple and if you wanted you could just install end user lua module . and on connection of the esp8266 to emontx . simply use that esp8266 interface web interface to setup the wifi via any wireless device… oh well different strokes for different folks I guess - i get that you want to have it all interface with each other but you just reduce already limited resources… where i increase mine by adding an extra processor power and 6 more gpios and 1 analog pin that run independently of the emontx
I am not entirely sure I understand your point. The Huzzah/ESP8266 is just plugged in to the EmonTx and is doing all the WiFi setup, config, MQTT, EmonCMS posting etc. The EmonTx is doing nothing more/less than the they would in the standalone variants. It would be good for you to share some more details of your setup.
Are you using Lua as per-installed on the Huzzah?
I originally tried 115200 with my setup of a Huzzah running ESPEasy with onboard USB to Serial, and an EmonTX V3.4 running the descrete sampling sketch. With that setup I got intermittent dropped packets, and after I downgraded it to 57600 all was well. This could well be down to my different ESP hardware / firmware combination, but figured you might want to know about it.
I’ve also expanded the ESP to output PWM to power my dimmer without any dropped packets.
Emonesp is a great addition to open energy.
I have one problem.
I get a server error = -1 from emoncms.org, and the data is not being posted to emoncms.org.
I am testing using the API.
If I post the same input to .org the data is accepted by .org with status of “ok.”
Any ideas?
Raymop
@Raymop, what do you have set in the EmonESP nodename field? by default, it is emonesp I think? At the moment emoncms.org only supports numeric node names, something I intend to fix soon. If you change the nodename to a number below 31, it should work (if that’s the issue).
Hi Trystan: I thought of that. And switched the node to be = to 1.
But, still get that error.
Here are some logs…
Copy of boot-up results:
EmonESP 1675561
Firmware: BUILD_TAG
Connecting as client to ----- epass:-----
Connected, IP: 192.168.1.141
Server started
Here is what I post as a test:
http://192.168.1.141/input?string=CT1:3935,CT2:325,T1:12.5,T2:16.9,T3:11.2,T4:34.8
Here is response from ESP
CT1:3935,CT2:325,T1:12.5,T2:16.9,T3:11.2,T4:34.8
Got ‘CT1:3935,CT2:325,T1:12.5,T2:16.9,T3:11.2,T4:34.8’
/input/post.json?json={CT1:3935,CT2:325,T1:12.5,T2:16.9,T3:11.2,T4:34.8,psent:0,psuccess:0,freeram:28408}&node=1&apikey=abc123etc
Plain old HTTP
Emoncms error: server error: -1
And nothing gets posted to emoncms.org, due to the error
Here I test sending the same input string vis the API to emoncms.org:
https://emoncms.org/input/post.json?json={power:200}&apikey=abc123etc
The input is correctly noted on emoncms.org
Node 0
Node: Key Name Process list last updated value
0 power 29s ago 200
Do I need to use SSL. maybe?