EmonTX to Rpi - Direct Serial Connection

I think that’s still correct on the silk screen. As you say, the pin labelled Tx is looking for the data that is coming out of a pin also labelled Tx, etc.
BUT: possibly to confuse it even further, the emonTx V3.4.1 schematic is like this:
image
Make sense of that, if you can. (Actually, of the two involved, the pin nearest the end and furthest from GND is the one on which the emonTx is transmitting.)

And continues to cause endless confusion because of that.

When you look up the standard (or Wikipedia), how the emonTx is labelled would be correct if the emonTx were a DCE - Data Communications Equipment (a modem), which I would argue it most definitely is not.

1 Like

I’m not sure I’m following you, PB. What specifically is it that can get damaged?

That is installed.

In this case, emonhub? so just stop the daemon?

I’m not confident I am finding the right information - what I have found seems to be geared to the RFM chip rather than the emonTX.

Can I just do the upload from PIO, rather than the avrdude-rpi mechanism? Can I simply do a pio run -t upload and specify the serial port? I suspect I can’t as I need to control the reset line (but that is a guess).

This really is a dark science to me :cry:.

Yes I’m getting serial data from the TX, so I’m thinking that bit is OK.

I think he’s saying that if two outputs are connected together, one sourcing and one sinking, then excess current can flow. (He said, carefully avoiding the use of “Tx”. :innocent:)

Another minor success along my path of discovery - pressing the reset pin; causing a reset (funnily enough).

$ miniterm /dev/ttyAMA0 115200
--- Miniterm on /dev/ttyAMA0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
MSG:15,Vrms:245.22,P1:116,E1:4,pulse:1
emonTx V3 EmonLibCM Continuous Monitoring V1.50
OpenEnergyMonitor.org
No EEPROM setting found...using default values
Calibration:
vCal = 268.97
i1Cal = 90.90
i1Lead = 4.20
i2Cal = 90.90
i2Lead = 4.20
i3Cal = 90.90
i3Lead = 4.20
i4Cal = 16.67
i4Lead = 1.00
RFM69CW Node: 15 Freq: 433MHz Group: 210

RFM int...
'+++' then [Enter] now to enter config mode...5s
CT1 detected, i1Cal:90.90
AC present
MSG:1,Vrms:244.74,P1:116,E1:0,pulse:1
MSG:2,Vrms:244.70,P1:117,E1:0,pulse:1
MSG:3,Vrms:245.14,P1:116,E1:0,pulse:1

Took my life in my hands and Success!! :grinning:.

Having installed the system using the emonScripts, some of the elements were already in place.

First compile the sketch. I know that @Robert.Wall is not keen on PlatformIO, but on the Pi it installed and worked flawlessly as described here GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware). The only oddity is creating the hex file. That instruction says use the upload option but that of course complains (although is does create the hex). A bit of digging and I created a new environment in the platformio.ini and an extra_script.py. This then creates the hex cleanly. The avrdude-rpi repo is created and installed by the emonScripts on the Pi so that was all ready to use (bar editing it to change the pin number for reset). Stopped the emonhub service first then ran the avrdude command as listed in the docs above and hey presto.

It has taken me quite a while, pulling the various bits of documentation together have taken time, but pretty pleased I got there in the end.

PlatformIO environment for the ini file (just adds the extra_scripts line).

[env:emontx_pi]
platform = atmelavr
framework = arduino
board = uno
build_flags = ${common.build_flags}
lib_deps = ${common.lib_deps_external}
monitor_speed = ${common.monitor_speed}
extra_scripts = post:extra_script.py

The extra_script.py file

Import("env", "projenv")
from shutil import copyfile

def save_hex(*args, **kwargs):
    print("Copying hex output to project directory...")
    target = str(kwargs['target'][0])
    copyfile(target, 'output.hex')
    print("Done.")

env.AddPostAction("$BUILD_DIR/${PROGNAME}.hex", save_hex)   #post action for the target hex

to build (first run pulls in the Libraries)

pio run -v -e emontx_pi

You need to edit the file /opt/openenergymonitor/avrdude-rpi/autoreset and change the pin number to 12.

to upload (having stopped emonhub)

avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:firmware.hex

[edit]
The extra script is now available in the repository as is a new platformio.ini file so the compile command should just work. (14/8/20)

Just for posterity and so if anyone find this by search…

To get ‘miniterm’ to accept input from the keyboard (so enter config mode) you need to add the --rtscts option.

$ miniterm --rtscts /dev/ttyAMA0 115200

Secondly, the NodeID is by default 0. If you want to change this you need to add the nodeoffset option such that

[[SerialTx]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           com_port= /dev/ttyAMA0
           com_baud = 115200
      [[[runtimesettings]]]
           pubchannels = ToEmonCMS,

           nodeoffset = 1

Note the comma after the pubchannels line and the blank line.

As the data comes in as name:value pair, there is no need for a node definition to decode the data, so choose an unused number (0-4) or delete the node definition.

[edit]
It is also good practice to remove the JP2 when powering from both AC and DC.

https://community.openenergymonitor.org/t/emontxv3-stops-and-requires-reboot-emonhub/5448/50

https://guide.openenergymonitor.org/technical/emontx/#configuration

The final question (I hope), looking at the inputs;
image

What is the correct processing to log to feed? Is the cumulative Energy more accurate than using the power?

If you’re talking about emonLibCM - possibly, but you’d probably need to carefully contrive the numbers to show it. Power is reported as watts, rounded to an integer; energy is reported as cumulative watt-hours truncated to an integer, but the truncation error is carried forward into the next reporting period.

Having said that, it probably only matters if you’ve calibrated your emonTx, because component tolerance errors (at around 1%) are likely to be larger than these in normal circumstances.

[Edit - 5 days later]

It turns out that I was not far wrong there. Having carefully logged both Energy accumulated by emonLibCM and Wh accumulated by emonCMS from power, for two channels with c.t’s on the same cable, the ratios of Energy/Wh over a count of 4000 approx. are

Ch 1: 1.0015
Ch 2: 0.9992
The emonCMS logging interval is 5 s, emonLibCM’s reporting interval is 4.98 s, a ratio of 1.004
(1 Wh in 4000 is 1.00025)

The calibration against meter pulses is +1.15% for Ch.1 and +0.29% for Ch.2.

1 Like

There is always something else isn’t there…

I discovered that, somehow, I did not have the latest version of the firmware. I was sure I’d cloned the repo recently, so why I was on version 1.3.0 I have no idea.

Updated the repo and rebuilt the hex. Uploaded to the emonTX. By default the serial output is disabled now so I needed to switch the RF off (w0) in config mode.

Other than that all seems good.

As reported elsewhere, the default emonTx sketch was updated only days ago for units despatched from the shop, but I gather that black hole called Github was updated some time earlier.

:rofl: It’s just a tool Paul Robert - one that takes a while to master. In fact, once you do understand it at least a little, it is very useful (trust me).

Yes you can clearly see it was updated several times since the 1.3.0 release (which was done last Nov) - I don’t understand what I must have done or else I mis remember what I did. Releases · openenergymonitor/EmonTxV3CM · GitHub

Do you mean me? I tried, but at my age and state of disillusionment, I don’t have the time - not with all the other stuff I do for OEM.

Ha yes (edited post) :man_facepalming:

I use GitHub for all sorts of stuff to keep track of changes not just OEM, and often it is the only way to contribute.

If it’s the only way to contribute, then whoever it is will have to get by without me. Like any tool, if you find it useful, that’s fine by me. I don’t. Maybe that was the fault of the guide I was reading, but it looked to be an impenetrable jungle with nomenclature that made no sense and seemed to mean that some third party heaven knows where in the world would have control over my machine. I had enough of that with Mickeysoft when it would decide what it wanted to do was more important than what I needed to do.

Yes it took me a while to get used to the lingo, but it is still a program and it simply does what you tell it to do. Working out exactly what to tell it to do, so it does what you want, can be a different issue but in no way does any third party have control of your machine or code. The other thing of course is that you can almost always go back to where you were. but I know you are not a fan :slightly_smiling_face:.

That’s how it appeared from what I was reading - whereupon I quit.

I’ve used other version control software in the past, so maybe you need to write a manual in real English for me. (I can cope with a Welsh or a Scots dialect if needs be :grin: )

1 Like

I think I have a better answer to that question now. The vertical units are kW:

image

So the answer appears to be - they are the same to within 2 parts in 16,800.

1 Like

So the final step on my odyssey (possibly)

3D printed case (link above), a right angle header and a short cable made up with a crimp tool makes for a very clean setup. Pi is then powered off the 5V DC to the emonTX (it works the other way as well).

End cost is slightly more than the emonESP, but far more flexible, can update firmware and no need for emoncms on a second machine/Pi. My aim is to install this at a friend’s house for a month and see if Agile will save him money. If it does the £50 referral will more than cover the cost of the Pi & case!

1 Like