I run an emonPi which connects to my network via wifi; in the 12 months or so that I have had it I can’t recall a single connectivity issue. But the four emonTx c/w ESP8266 wifi modules have been “less robust” connection-wise, despite much help from these forums & strong wifi AP coverage in each location. Sadly they are all far too far away from the emonPi for direct comms.
Question: is there any way of connecting the emonTx’s via ethernet? This would make life so much easier. FWIW, some of the locations do require more than 2 CT inputs.
I’ve looked within the OEM Shop, but can’t see anything suitable.
A similar question was asked recently about connecting an emonTx to an emonPi - the suggestion was a serial to USB converter. So it is probably worth looking at serial to Ethernet converters. I can’t remember seeing this question asked before, so I’ve no idea whether it is practical.
I’d be quite prepared to believe you’d need to modify the sketch to send the data in a subtly different format.
Thanks, @Robert.Wall . I had a quick look at Serial to Ethernet converters, and they are not cheap, and fiddling with sketches is still, sadly, above my comfort zone.
Coming in from a different direction, I wonder whether it might be possible / easier to use the emonPi Shield Kits emonPi Shield KIT (no enclosure) - Shop | OpenEnergyMonitor and mount them on a couple of old Raspberry Pi’s I have lying around? Would it be possible to set them up as slaves to the main emonPi. I understand that I would only have 2 CTs per device, but maybe I could live with that.
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.
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.
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…
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?
Is Glyn’s “1. EmonHubTx3eInterfacer” or “2. EmonHubSerialInterfacer” best in this situation?
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)
@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
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
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.
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.
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.
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.
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
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!
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.
