Avoiding wireless connections - EmonTX serial RPiZero solution

Not sure if it’s related but I notice the esp8266 compiler in emonESP hasn’t been updated for a while, so unstable devices are potentially still being shipped.

The stability of emonESP has been discussed a lot.

Indeed the Pi Zero is a v’good solution and I would always suggest the Pi ZeroW is used where someone is considering an emonESP, I posted on this wayback (4 CT emonBase using emonTx and Pi Zero W) and I know you are now a big fan too. But in this instance Julian has some old Pi’s kicking around, plus he has specified “wired”, although I doubt very much that the Pi’s would suffer any of the issues he’s experiencing with the emonESP’s.

@haffle, perhaps try one or more of the Pi’s you have spare, Ethernet first? Then Wifi perhaps and if the WiFi side is ok and you wish to streamline a little you could buy a couple of PiZeroW’s and swap over the SDcards, they are so cheap.

1 Like

Yet another method would be to use serial to RS485 adapters. They’re cheap (~5 USD), need only three conductors (two data lines and a ground), can use cheap twisted pair wiring and at 9600 bps, their max range is 1200 metres. Operation in an electrically noisy environment is good as well.


1 Like

But you still need to use one Pi (can’t use the emonPi) to receive the serial bus data.

1 Like

On the emonPi end, an RS485 to USB adapter could be used.

1 Like

I have a couple of Pi Zero WH (wireless & header pins) that I could use; but looking at the amazing work @borpin did in the thread linked to above EmonTX to Rpi - Direct Serial Connection (specifically posts from Mar 24 onwards) I am happy that I could make a reasonable stab at the physical aspects of the project, but the software / coding is daunting…

  1. I can find the emonHub interfaces section within my emonPi, but is there another one within the emonTx web interface, or just this change only need doing on the emonPi?

  2. Is Glyn’s “1. EmonHubTx3eInterfacer” or “2. EmonHubSerialInterfacer” best in this situation?

  3. For the PiZero header pins > emonTx UART; I see that @borpin used
    5.0 vDC > 5V (red)
    GND > GND (black)
    TxD > Tx (blue)
    RxD > Rx (green)

  4. @pb66 wrote “you can simply add a chip reset wire and use avrdude with rpi-avrdude as described in the rfm2pi wikis”. Hmmm, no idea where to start with this one :smile:

  5. Continuing to read the other thread … and I am now officially lost. Too much talk of avrdude, hex, Pio & rfm2pi. Where do you guys all learn how to do all of this? #impressed :sunglasses:

Off to grab a cold beer.

1 Like

I really need to write it up properly!

You don’t need to do any coding. You can just use the emonSD image and edit emonhub to read the data and send it to your main base station. In theory you can just install emonhub, but let’s keep it simple!

If you add the 5th wire (rst), if you need or want to update the firmware on the emonTX it is very easy to do, but you probably don’t have to. Ignore this for now.

Have you any jumper wires?

Paul has a good diagram of the wiring here 4 CT emonBase using emonTx and Pi Zero W - #17 by pb66. Ground on the emonTX is the right most pin.

Remember, you are powering the Pi from the emonTX so do not put power on the Pi as you normally would.

Once wired, fire up an SD image, I would add a wpa_supplicant file - much easier to setup Wi-Fi that way and remember to leave it for a while to update. Then we can look at the serial interface.

miniterm /dev/ttyAMA0 115200

and hit the reset button on the emonTX. (EmonTX to Rpi - Direct Serial Connection - #47 by borpin)

If you get this far you are well on the road.

1 Like

That’s not something I recognise. The emonTx does not interface directly to the “Web”. The normal intended output is by radio to a “Base” (which is either an emonPi or an emonBase), or a serial output (with a different format but conveying the same data) going to “something else” that launches the data onto a network. The “something else” can be an ESP8266 sending WiFi, or a Pi (full-size or a Pi Zero) sending Ethernet or WiFi.

The emonTx needs a software setting changed to switch from sending by radio to sending by wired serial.

It’s a piece of software that does the nitty-gritty of loading the sketch into the processor.

A method of counting to a base of 16 - uses the decimal digits 0 - 9 then letters A - F (or a - f) for the numbers 10 - 15.

An IDE that screwed up my system - best avoided in my experience.

Later a RFM12Pi and RFM69Pi. The piggy-back board that sits on a RPi GPIO connector that receives radio data from emonTx’s and emonTH’s, and converts it to serial data that the Pi can accept. The combination is the hardware for an emonBase.

Many places. I started as a student apprentice in 1967, and was taught valve theory (vacuum tubes to US readers), the 709 op.amp was new, and saw thyratrons and mercury arc rectifiers, resistor-diode logic and thyistors that didn’t have a high enough voltage rating to be used on 3-phase at 440 V.

And I’ve been learning ever since.


I got my start with the USAF in 1974 repairing Avionics Navigation equipment.
Vacuum tubes were in much of the gear in those days.
(still are, in some cases, e.g. high power transmitters)
It’s come full circle, as last month I retired from a USAF civilian job.
I figure the day I stop learning will be the day I stop breathing.

I’ll drink to that! beer_cheer


The “web interface” of the emonTx you refer to is most likely the emonESP configuration page. On each emonBase/emonPi there is one active emonhub.conf and that can be edited via ssh command-line or via the emoncms “emonhub config” page.

The EmonHubTx3eInterfacer (by Owen Duffy not Glyn) will work straight “out of the bag” with a recent emonTx as it reuses the serial output designed for the emonESP. The EmonHubSerialInterfacer is the original basic serial interfacer from which the other serial based interfacers are spawned.

Correct, but even simpler, only the 2 Gnd and Rx lines are needed for basic data reporting via emonhub. To that you can add the 3rd 5v line to power both devices from the one ac/dc 5v adapter (still need the 9v ac/ac for voltage sensing though).

The 4th “tx” and 5th “rst” lines are not essential for normal use. But these will be needed to upload (and configure) other firmwares to the emonTx from the Pi, including simple updates.

Not something you need to think about yet. That was said in response to specific questions about loading FW from the Pi. If you may want to be able to update the emonTx at a later date, fit the wires while you’re there (if you have them) and then you can progress on to that later. I think there is some progress in the works regards updating a serially connected emonTx via the emoncms web pages, so maybe you won’t need to learn any of this and just click a button?

Again, don’t worry too much about any of this right now, in this context “hex” is the pre-compiled firmware file, so called due to it’s .hex extension. One day someone will be asking you where the hell you learnt all this, all it takes is interest and time, the info’s all out there and there are plenty of people happy to talk about it at length. Being aware you do not already know everything and being open to learning is half the battle so you are well on your way :grin:

Thanks Brian, although whether to use that gpio pin for reset is debatable. I deliberately didn’t use the same pin as the RFM2Pi/emonPi’s as I didn’t want accidental over-writing of the FW by the emonPi update routine. As the gpio pin is hardcoded in rpi-avrdude, it may have to be the same pin 7 as Trystan will base the emonTx update on an extension of the current updating process, ie just a different button/option and .hex path/repo.

Actually it could be better the other way round in many instances. Power the Pi with a PSU and the emonTx via the 5v line. The proper Pi PSU’s are far superior to most other PSU of this type including the OEM shop one, plus the Pi has better voltage regulation than the emonTx. This is only a theoretical comparison, I haven’t done side by side tests, but I have always used good Pi PSU’s and powered via the Pi and never had any noise issues or brownouts etc. The Shop PSU powering an emonESP via an emonTx has proven to be somewhat less than perfect for many users and that may not all fall on the fault of the esp. Ether way will work though so the decision can be made on what is to hand to start with, the inter connections are the same regardless.


I used it as it was then easy to create a single header! I couldn’t remember how though. I’ve reminded myself and added it to the original thread. It is just a matter of editing the autoreset script.

Interesting. I must admit I tend to use old Phone chargers! Reduce, Reuse, Recycle!

I use 'em too.
As long as SMPS noise isn’t a concern, and they can source enough current, they get the job done.

(SMPS = Switching Mode Power Supply)

Thanks @borpin & @pb66 - that all sounds doable; I do have a load of jumper wires & breadboards etc from when I started playing around with Raspberry Pi’s - making things like LED traffic light sequencing. I am away for a week from Saturday, but will bookmark this page and have a go upon my return.


I also prefer to do that where I can too, but if anything wobbles or isn’t as expected, the first thing I will do is swap out the PSU for a known good supply. It’s ok to use them if you know they could have weaknesses, just coz’ it’s 5v and spec’d to deliver “enough” current, doesn’t necessarily mean it will deliver trouble free operation.

1 Like

Yep. If it’s rated at less than 2 Amps, I’ll use it for something other than a Pi.

1 Like

I find even some 1 Amp supplies are fine, slightly bulkier, possibly non-switching types.

The emonBase are under-clocked as we know, so the full 2A is not often totally necessary perhaps.

The red LED on the pi is a good indicator of power quality neh? Continuously on red = good enough?

I think I now have all of the bits I need, but a couple of quick questions as the PiZero doesn’t show up within my router’s CP (although the small green LED does come on / flash) …

I added a (blank) ssh.txt file and a wpa_supplicant.conf file to the boot partition - the contents of the latter being

Should I expect the Pi Zero to “work” without being connected to an emonTx or not? Maybe I have tried to run before I can walk, as I have not yet connected the emonTx.


I don’t have update_config in the file I use.

It is just SSH not SSH.txt AFAIK.

Yes get the Pi working first and it should just work IME. If not, connect up to a monitor and see what it is saying. If a new emonSD image, usual caveats re allowing it to finish updating before removing power or rebooting.

1 Like

Many thanks; still not appearing in my router’s list of clients, so probably a wifi thing. I needed to obtain a mini-HDMI adapter (just arrived now), so will try to hook up a monitor tomorrow.

1 Like

Note that it’s specifically ssh (lower-case) rather than SSH.

By default SSH access is disabled in Raspbian. To enable SSH, create a file called ssh and save it to the root directory of the boot mount on the SD card. The file can be blank, and it has no extensions. It should exist at the same location as the other files that were edited.

From Connect to a Raspberry Pi Zero with a USB Cable and SSH which explains how to make a wired connection if the wireless is causing grief.