21

This EmonTX is still transmitting by RFM as well as by serial - that is why you are getting it twice. Note the 15 after the OK.

[edit]

Easily solved.

22

Do not then power the EmonTX directly with DC as well
It says DO NOT POWER for USB, if DC is not connected readings are all off as on as usb does not have the power to run them.

What do you want to comment out?

     ``` # emonhub/rx/10/values format
    # Use with emoncms Nodes module
    node_format_enable = 1
    node_format_basetopic = emonhub/

    # emon/emontx/power1 format - use with Emoncms MQTT input
    # http://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md
    nodevar_format_enable = 1
    nodevar_format_basetopic = emon/```

Easily solved.
How?

23

What Brian is saying here is, despite your belief and assertion to the contrary, Node 15 is transmitting the data both serially and via the radio.

The solution is easy, turn off the transmitter. There are two ways to do that. If you connect the errant emonTx and its programmer directly to your computer, and you have the Arduino IDE on it, when you power the emonTx with the IDEā€™s Serial Monitor active, youā€™ll see an invitation to enter the access code +++, and having done that, a list of configuration commands. Type w0[enter], then s[enter] to save the command in EEPROM. You can then restore the emonTx to its place, and Node 15 should be gone.

The second way is to edit the sketch and hard-code that change, then recompile and reload the sketch.

Thatā€™s puzzling. Normally, the emonTx can get its power via the USB lead and programmer (the programmer from our Shop will do that - a third party one might not). But another user today has reported a USB lead with a failed Pin 1 (the +5 V) connection - did you get yours from our shop too?

The current required by the emonTx is not that great, at 5 V it is about 8 - 10 mA when not transmitting (which is how you have it). Your 2 A supply should not even notice three of those.

The full explanation is:
The emonTx is designed to take its power from the a.c. adapter in normal use with the radio, via the jumper link JP2 on the p.c.b. It can also take a 5 V d.c. feed from the USB socket, the battery holder (when requested), the programmer FTDI connector, the RJ45 connector (though this is normally an output to the pulse sensor) and the screw terminal strip. All these places are wired in parallel. Therefore, itā€™s not a good idea to (a) have the jumper in place and use the 5 V d.c., nor (b) to have multiple 5 V supplies, because one might back-feed the other(s).

I think Brian meant the two lines that follow the comment ā€œUse with emoncms Nodes moduleā€.

24

Thanks, both for help node 15 now removed.
Yes the Serial/USB was purchased at the same time

What is the best way to update the emonpi as web version and if run avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex

also does not work the same error.

avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x1c
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xfc
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x70
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xe0```
25

Iā€™m not sure what you mean there: the version of emonCMS on www.emoncms.org is different to the version you have on your emonPi, so you must expect slightly different features and behaviour from it. In general, your emonPi version has more features, the multi-user version at emoncms.org generally lags behind the emonPi version.

Did you do sudo service emonhub stop before you sent that command?

If you did, I canā€™t offer an explanation as to why it doesnā€™t work. It works for me as-is on two emonPiā€™s, and if I change the baud rate to 38400, it works for an old emonBase with an old RFM2Pi add-on board.

N.B. you must do sudo service emonhub start afterwards.

26

Was say I can not update for in software admin link.

image
image1201Ɨ484 29.1 KB

Yes stopped

pi@emonpi:~ $ sudo service emonhub stop
pi@emonpi:~ $ avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xfc
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x1c
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xfc
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x70
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xe0

avrdude done.  Thank you.
27

@TrystanLea - Any ideas why this is failing?

28

If you just click on this, what is the resulting output? Exactly the same?

image

Please post all of the debug output.

29 
Starting update via service-runner-update.sh (v3.0) ><br />
- emonSD version: emonSD-02Oct19<br />
- supported images: emonSD-24Jul20 emonSD-02Oct19 emonSD-17Oct19<br />
- emonSD base image check passed...continue update<br />
git pull /opt/openenergymonitor/EmonScripts<br />
  master<br />
* stable<br />
On branch stable<br />
Your branch is up to date with 'origin/stable'.<br />
<br />
nothing to commit, working tree clean<br />
Already up to date.<br />
-------------------------------------------------------------<br />
Main Update Script<br />
-------------------------------------------------------------<br />
Date: Wed 28 Oct 2020 11:18:43 AM PDT<br />
EUID: 1000<br />
openenergymonitor_dir: /opt/openenergymonitor<br />
type: firmware<br />
firmware: emonpi<br />
Reading package lists...<br />
Building dependency tree...<br />
Reading state information...<br />
python3-pip is already the newest version (18.1-5+rpt1).<br />
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.<br />
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple<br />
Requirement already satisfied: redis in /usr/local/lib/python3.7/dist-packages (3.5.3)<br />
Hardware detected: EmonPi<br />
Stopping emonPiLCD service<br />
Display update message on LCD<br />
-------------------------------------------------------------<br />
EmonPi Firmware Update (Discrete Sampling)<br />
-------------------------------------------------------------<br />
Start ATmega328 serial upload using avrdude with latest.hex<br />
Attempt: 1<br />
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex<br />
Note: progress written to logfile /var/log/emoncms/firmware.log<br />
<br />
<br />
ERROR: Not in sync<br />
Attempt: 2<br />
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex<br />
Note: progress written to logfile /var/log/emoncms/firmware.log<br />
<br />
<br />
ERROR: Not in sync<br />
Attempt: 3<br />
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex<br />
Note: progress written to logfile /var/log/emoncms/firmware.log<br />
<br />
<br />
ERROR: Not in sync<br />
<br />
waiting for emonpi to stop controlling LCD<br />
<br />
Starting emonPi LCD service..<br />
<br />
<br />
-------------------------------------------------------------<br />
emonPi update done: Wed 28 Oct 2020 11:19:09 AM PDT<br />
-------------------------------------------------------------</details><br />
30

TL;DR The utility avrdude-rpi still uses python which may be the issue @bwduncan @TrystanLea. @Martin_Harizanov - I note OEM fork is from you. Went back to the original repo and is still python as well.

In detailā€¦

Interesting.

Start ATmega328 serial upload using avrdude with latest.hex
chmod: cannot access '/var/log/emoncms/firmware.log': No such file or directory
Attempt: 1
avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex
Note: progress written to logfile /var/log/emoncms/firmware.log

avrdude-original: Using autoreset DTR on GPIO Pin 7
strace: |autoreset: Broken pipe

ERROR: Not in sync

In your fiddling, have you changed the avrdude setup?

You are missing this message in the log.

avrdude-original: Using autoreset DTR on GPIO Pin 7

There is an extra script inserted to make the reset pin work on an RPi.

Check the linksā€¦

pi@emonpi:/opt/emoncms/modules/usefulscripts/octopus $ which avrdude
/usr/bin/avrdude
pi@emonpi:/opt/emoncms/modules/usefulscripts/octopus $ ls -la /usr/bin/avr*
lrwxrwxrwx 1 root root     52 Oct 17  2019 /usr/bin/avrdude -> /opt/openenergymonitor/avrdude-rpi/avrdude-autoreset
-rwxr-xr-x 1 root root 383576 Apr 12  2019 /usr/bin/avrdude-original
pi@emonpi:/opt/emoncms/modules/usefulscripts/octopus $

In simple terms

  • calling avrdude
  • calls dvrdude-autoreset
  • calls /opt/openenergymonitor/avrdude-rpi/autoreset (the script the generates the message above)
  • calls /usr/bin/avrdude-original

At this point I realised that autoreset is using Python and not Python3 which may be the issue.

31

ISTR porting this to Python 3 but maybe I never tested and pushed it. Iā€™ll have a look.

1 Like
32

Yes, I did. Itā€™s a pull request on github. If someone could test it I would really appreciate it.

1 Like
33

Looks to be working now.
remamed avrdude to avrdude-origin and put a sybolic link /usr/bin/avrdude ā†’ /opt/openenergymonitor/avrdude-rpi/avrdude-autoreset


avrdude-original: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude-original: Device signature = 0x1e950f (probably m328p)
avrdude-original: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude-original: erasing chip
avrdude-original: reading input file "/opt/openenergymonitor/emonpi/firmware/compiled/latest.hex"
avrdude-original: input file /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex auto detected as Intel Hex
avrdude-original: writing flash (18526 bytes):

Writing | ################################################## | 100% 2.58s

avrdude-original: 18526 bytes of flash written
avrdude-original: verifying flash memory against /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex:
avrdude-original: load data flash data from input file /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex:
avrdude-original: input file /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex auto detected as Intel Hex
avrdude-original: input file /opt/openenergymonitor/emonpi/firmware/compiled/latest.hex contains 18526 bytes
avrdude-original: reading on-chip flash data:

Reading | ################################################## | 100% 1.94s

avrdude-original: verifying ...
avrdude-original: 18526 bytes of flash verified

avrdude-original done. Thank you.

SUCCESS: flash verifed

waiting for emonpi to stop controlling LCD

Starting emonPi LCD service..


-------------------------------------------------------------
emonPi update done: Thu 29 Oct 2020 11:19:45 AM PDT
-------------------------------------------------------------

Thanks all for you help

1 Like
34

I was sure Iā€™d checked. Looks like Iā€™d clicked through to the original repo before checking the PRs - apologies. Many thanks.