Using the EmonTx v3 with the ESP8266 Huzzah WIFI module

kevin · 2016-09-03T09:09:55.601Z

+1 for the temp stuff

pb66 · 2016-09-06T17:31:46.713Z

12 posts were split to a new topic: Could emonESP also support CSV and post to a local emonHub?

Robert.Wall · 2016-09-03T12:58:41.010Z

kevin:

Is there any chance the EMONTX sketch can be modified to provide a current AC voltage output so the AC adapter can be calibrated?

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.

kevin · 2016-09-03T20:49:03.600Z

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.

Robert.Wall · 2016-09-03T22:33:39.173Z

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.

kevin · 2016-09-03T22:58:44.723Z

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

kevin · 2016-09-05T21:54:06.299Z

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

glyn.hudson · 2016-09-11T12:40:38.490Z

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…

github.com

openenergymonitor/emonTxFirmware/blob/emontx-ds-emonesp/emonTxV3/RFM/emonTxV3.4/emonTxV3_4_DiscreteSampling/src/src.ino

/*

  emonTxV3.4 Discrete Sampling

  If AC-AC adapter is detected assume emonTx is also powered from adapter (jumper shorted) and take Real Power Readings and disable sleep mode to keep load on power supply constant
  If AC-AC addapter is not detected assume powering from battereis / USB 5V AC sample is not present so take Apparent Power Readings and enable sleep mode

  Transmitt values via RFM69CW radio

   -----------------------------------------
  Part of the openenergymonitor.org project

  Authors: Glyn Hudson & Trystan Lea
  Builds upon JCW JeeLabs RF12 library and Arduino

  Licence: GNU GPL V3

*/

/*Recommended node ID allocation

This file has been truncated. show original

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.

glyn.hudson · 2016-09-14T12:16:27.507Z

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.

glyn.hudson · 2016-09-19T11:20:35.994Z

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.

github.com/openenergymonitor/emonTxFirmware

v2.5 19/09/16 Increase baud 9600 > 115200 to emonesp compatiability

committed 11:18AM - 19 Sep 16 UTC

glynhudson

+3 -2

stephen · 2016-09-21T00:03:44.157Z

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

jeremypoulter · 2016-09-21T10:05:36.550Z

stephen:

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?

kevin · 2016-09-23T22:37:10.729Z

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.

raymop · 2017-03-01T19:53:44.689Z

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

TrystanLea · 2017-03-01T20:15:33.819Z

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

raymop · 2017-03-02T01:05:03.887Z

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?

@raymop

raymop · 2017-03-06T03:30:11.047Z

SOLVED.
I was using the read only key, when I should have been using the read/write key for the API.

Maurizio · 2017-06-17T16:54:29.203Z

Hi guys,
I’m trying to implement the EmonTX v3 + ESP8266 solution using a nodemcu (like this Get Started With NodeMCU - Hackster.io ) but something is not working as excepted. The serial output of the emontx is correct via serial output (if I use a PC). The nodemcu MQTT is posting as expected. The problem is putting them together. When I connect the emontx to the nodemcu nothing happens, I mean no data comes from emontx to the nodemcu. if I open the EmonESP web page, the section 4. Latest data is empty and consequently no data is posted via MQTT.
Do you have any suggestion? Is the nodemcu not appropriate for some reason that I don’t know?

Thank you in advance.

pb66 · 2017-06-17T17:44:29.520Z

Maurizio:

The problem is putting them together. When I connect the emontx to the nodemcu nothing happens, I mean no data comes from emontx to the nodemcu.

Taking what you have said at face value and the fact you suspect the interaction between the 2, I would recommend rechecking the Rx and Tx lines as the emonTx isn’t labelled as you might expect.

ATmega328P-AU-pinout.png1200×1200 48.2 KB

board.png1350×1350 152 KB

Maurizio · 2017-06-18T08:50:14.500Z

Hi Paul,
thank you for the suggestion! Now works properly. So, if someone will have the same issue, the solution is to connect the RX pin of the emontx with the RX pin of the nodemcu (or whatever). Le me say that this is not so intuitive!