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 .
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ā. )
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!! .
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;
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.
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.
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)
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 .
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 )
I think I have a better answer to that question now. The vertical units are kW:
So the answer appears to be - they are the same to within 2 parts in 16,800.
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!
Nice work. Very clean, indeed!