The ESP8266 can be powered with its own supply, or from the Envi output connector. My Envi power supply is only rated at 3V/100mA, which is not enough to supply the ESP8266. I used an old 5V /800mA phone charger, an AMS1117 3.3V module, and the original plug to make a new power supply.

The RJ45 connector uses pins 1 (3.3), 4(Gnd), 7(Tx) to interface to the ESP8266. If the ESP is powered separately, just 4 and 7 are needed. Pin 6 is (probably) Rx, but it seems to have no use during operating mode.

I got 5 bare ESP-13s for under $20 so it was time to man up and try some soldering tricks. They have 1.5mm castellated (partial hole) pins, but I was surprised that they were not that hard to solder. I used a 1/64" tip and pre-soldered the bottom of the pads. I then used 3-4" pieces of AWG30 (wirewrap) wire bent at 90 degrees at the end and soldered to the edge of the pins using the existing solder. Even with lots of playing around with the chip and board I never had a wire come loose. I did hot-glue the chip upside down early on to keep it in place.

I first checked the communication with the Envi with an ESP12e dev board and some simple code to echo serial1 to serial2. It worked immediately so I soldered a perfboard with the ESP13, some resistors for reset/G15, a status LED, some headers for power, program jumper, serial1, and serial2., and hot-glued the cable end down. It powered up (using external power; I hadn't built the new power supply yet), and I was able to program it with the latest code. But then, depresssion set in...

The serial port was showing lots of errors - almost no error-free lines received. So I spent parts of a few days blaming bad soldering, ground problems, EMI, flaky cable, etc., but couldn't explain why the original chip still worked and the new chip didn't, even though I flashed it with serial1 and read serial2 many many times with no problems. I finally had the proper amount of XX brain lube and did two things. I put it up for vote by trying another ESP12e dev board, and it was flaky too. This meant my board was probably OK; then I tried a 1K/10K divider, and all was well. So, apparently the Envi is putting out higher than 3.3V on Tx, even though the power supply is 3V and I originally measured the Tx line with a meter to check the pinout and saw it sitting at 3V, then going to about 2.7V periodically, which would be the active transmits. I assume this is to ensure proper operation of the PL2303 TTL-USB chip in their cable. The good thing is the flaky hardware had given me time to get the code working. I was going to experiment with at least one more resistor value (like 2K) but since I tacked down the 1K/10K and let it go (running off the Envi-supplied power) it's been running almost 7 straight days (98K+ samples right now). Apparently there are no memory leaks or flaky resets. Another good thing is now I can justify a 1054Z.

Software Notes:

• The Envi XML document describes how history is periodically interspersed with realtime data. I knew I wanted to throw out the history transmits and keep the realtime ones. I decided to parse and compress the data on the fly, converting tags to commas and then multiple commas to single commas once the end of line was reached. The result is then split into tokens and some simple checks for number of tokens and expected field formats classifies the packet as good, skipped (history), or bad. The line reader will also mark a line as 'truncated' if it's too long. After 99K good packets, there are about 14.5K more skipped, only 5 bad, and no truncates. At some point I may take a Putty log and see if there's anything unusual (does it ever concatenate a realtime after a history with no newline, etc.). Or I may just update the line parser and do some tag interpretation to detect message boundaries and throw away the history packets.
• The thingspeak POSTer currently tries only once to connect and there is no additional checking for wifi connected in the main loop. The status is showing 16 failed connects, which would be over almost 20K attempts since I'm averaging the last 5 samples before POST'ing. A successful POST results in a check for the server response. No bad responses were received, and 41 timeouts occurred (a new POST was requested before the previous response was received). So it seems pretty reliable. I don't throw away the samples if the connect fails - I add the next one and then try again. The sample count is in the packet sent and it looks like it was never more than 6.
• The rest of the code does the basic ESP server stuff without SPIFFS. Once wifi is connected, the time is retrieved with ntp. A root page is served with cdn links for bootstrap, jq, d3, c3, and with some js to do ajax json requests to api/system and api/last. If I add SPIFFS, it would be mostly to do local data recording and processing (day of full samples, week of minutely, month of hourly, etc.). Then some historical charts could be generated and served. And with a static file server, it's easy to add an admin page and use it for wifi setup instead of hardcoding. And a scheduler can add events for summaries/limits hit/etc.

Hardware Notes:

• Since there's room on the board and I haven't used a DHT22 yet, I'll probably add one for humidity measurements. I thought about also adding an output cable for echoing serial1 to serial2 for passthrough, but I'll probably stop using my current setup (Homeseer plugin) and just use the ESP data.

I added a DHT22 and am using the adafruit library to read temperature and humidity. Added the data to thingspeak and the json object for the web api. Neither of the temperature readings seem too accurate. The DHT22 is definitely closer.