Community
OpenEnergyMonitor

OpenEnergyMonitor Community

EMonTX Bad data after upgrade

Please enable debug in the emonhub.conf. It will help you see what is being received from the emonTX NEW FRAME and what is happening with it.

You are getting live inputs, on Node 15 with all of the EmonTXs shut down? There must be another device in RFM range.

Again, enabling debug and tailing the log will help you.

Indeed, OR the r.f. has not been turned off on the emonTx that still believes it is Node 15 - if indeed one still does.

@NA7KR
When you wrote

which one, and what did you actually do? Which sketch did you use, and did you change and defaults, and did you change and configuration or calibration settings on-line afterwards?

Turning on whitening for Node 15 in emonhub.conf will give valid numbers. If those correlate consistently with the numbers that come in on one of the serial inputs, that will identify the problem. If different, that would suggest that it’s another transmitter on the same channel and within radio range. If that’s the case and you don’t intend to use the radio link that the emonPi provides by default, then you just remove Node 15 from emonhub.conf and it will ignore it.

Except I asked if that node was appearing with all the EmonTXs turned off.

Yes Node 15 is there with all emonTX off.
Remove node 15 form config does not help.

2020-10-27 09:51:19,686 INFO     MQTT       Publishing: emonhub/rx/5/values 0,3,3,111.24000000000001,13,0,0,0,0,0,0
2020-10-27 09:51:20,376 DEBUG    SerialTx1  34730 NEW FRAME : MSG:5904,Vrms:112.93,P1:-1796,P2:2650,P3:-1,P4:7,E1:14881,E2:2600,E3:143,E4:2905,pulse:0
2020-10-27 09:51:20,377 DEBUG    SerialTx1  34730 Timestamp : 1603817480.375853
2020-10-27 09:51:20,377 DEBUG    SerialTx1  34730 From Node : 9
2020-10-27 09:51:20,378 DEBUG    SerialTx1  34730    Values : [0, 112.93, -1796, 2650, -1, 7, 14881, 2600, 143, 2905, 0]
2020-10-27 09:51:20,378 DEBUG    SerialTx1  34730 Sent to channel(start)' : ToEmonCMS
2020-10-27 09:51:20,379 DEBUG    SerialTx1  34730 Sent to channel(end)' : ToEmonCMS
2020-10-27 09:51:20,402 DEBUG    RFM2Pi     34731 NEW FRAME : OK 15 69 66 85 85 142 126 85 85 85 85 95 85 85 85 85 85 85 85 173 170 170 170 241 85 85 85 182 170 170 170 101 32 101 32 101 32 85 85 85 85 (-68)
2020-10-27 09:51:20,403 DEBUG    RFM2Pi     34731 Timestamp : 1603817480.401846
2020-10-27 09:51:20,404 DEBUG    RFM2Pi     34731 From Node : 15
2020-10-27 09:51:20,404 DEBUG    RFM2Pi     34731    Values : [1431650885, 323.98, 21845, 21845, 21855, 21845, 1431655765, 2863311533, 1431655921, 2863311542, 82.93, 82.93, 82.93, 1431655765]
2020-10-27 09:51:20,404 DEBUG    RFM2Pi     34731      RSSI : -68
2020-10-27 09:51:20,405 DEBUG    RFM2Pi     34731 Sent to channel(start)' : ToEmonCMS
2020-10-27 09:51:20,405 DEBUG    RFM2Pi     34731 Sent to channel(end)' : ToEmonCMS
2020-10-27 09:51:20,445 DEBUG    SerialTx0  34732 NEW FRAME : MSG:5904,Vrms:112.27,P1:0,P2:0,P3:10,P4:0,E1:0,E2:-8,E3:164,E4:-29,pulse:0
2020-10-27 09:51:20,446 DEBUG    SerialTx0  34732 Timestamp : 1603817480.445419
2020-10-27 09:51:20,447 DEBUG    SerialTx0  34732 From Node : 10
2020-10-27 09:51:20,447 DEBUG    SerialTx0  34732    Values : [0, 112.27, 0, 0, 10, 0, 0, -8, 164, -29, 0]
2020-10-27 09:51:20,447 DEBUG    SerialTx0  34732 Sent to channel(start)' : ToEmonCMS
2020-10-27 09:51:20,448 DEBUG    SerialTx0  34732 Sent to channel(end)' : ToEmonCMS
2020-10-27 09:51:20,476 DEBUG    SerialTx2  34733 NEW FRAME : MSG:5904,Vrms:113.17,P1:-2150,P2:2656,P3:0,P4:34,E1:14184,E2:2602,E3:185,E4:1750,pulse:0
2020-10-27 09:51:20,477 DEBUG    SerialTx2  34733 Timestamp : 1603817480.476009
2020-10-27 09:51:20,477 DEBUG    SerialTx2  34733 From Node : 8
2020-10-27 09:51:20,477 DEBUG    SerialTx2  34733    Values : [0, 113.17, -2150, 2656, 0, 34, 14184, 2602, 185, 1750, 0]
2020-10-27 09:51:20,478 DEBUG    SerialTx2  34733 Sent to channel(start)' : ToEmonCMS
2020-10-27 09:51:20,478 DEBUG    SerialTx2  34733 Sent to channel(end)' : ToEmonCMS
2020-10-27 09:51:20,498 DEBUG    MQTT       Publishing: emon/emontx3cm16/MSG 0
2020-10-27 09:51:20,498 DEBUG    MQTT       Publishing: emon/emontx3cm16/Vrms 112.93
2020-10-27 09:51:20,500 DEBUG    MQTT       Publishing: emon/emontx3cm16/Grid2 -1796
2020-10-27 09:51:20,500 DEBUG    MQTT       Publishing: emon/emontx3cm16/Solar2 2650
2020-10-27 09:51:20,501 DEBUG    MQTT       Publishing: emon/emontx3cm16/Air2 -1
2020-10-27 09:51:20,502 DEBUG    MQTT       Publishing: emon/emontx3cm16/Furnace 7
2020-10-27 09:51:20,503 DEBUG    MQTT       Publishing: emon/emontx3cm16/7 14881
2020-10-27 09:51:20,503 DEBUG    MQTT       Publishing: emon/emontx3cm16/8 2600
2020-10-27 09:51:20,504 DEBUG    MQTT       Publishing: emon/emontx3cm16/9 143
2020-10-27 09:51:20,505 DEBUG    MQTT       Publishing: emon/emontx3cm16/10 2905
2020-10-27 09:51:20,506 DEBUG    MQTT       Publishing: emon/emontx3cm16/11 0
2020-10-27 09:51:20,507 INFO     MQTT       Publishing: emonhub/rx/9/values 0,112.93,-1796,2650,-1,7,14881,2600,143,2905,0
2020-10-27 09:51:20,611 DEBUG    MQTT       Publishing: emon/emontx3cm17/MSG 0
2020-10-27 09:51:20,612 DEBUG    MQTT       Publishing: emon/emontx3cm17/Vrms 112.27
2020-10-27 09:51:20,612 DEBUG    MQTT       Publishing: emon/emontx3cm17/Dryer1 0
2020-10-27 09:51:20,613 DEBUG    MQTT       Publishing: emon/emontx3cm17/Dryer2 0
2020-10-27 09:51:20,614 DEBUG    MQTT       Publishing: emon/emontx3cm17/Washer 10
2020-10-27 09:51:20,614 DEBUG    MQTT       Publishing: emon/emontx3cm17/Microwave 0
2020-10-27 09:51:20,615 DEBUG    MQTT       Publishing: emon/emontx3cm17/7 0
2020-10-27 09:51:20,615 DEBUG    MQTT       Publishing: emon/emontx3cm17/8 -8
2020-10-27 09:51:20,616 DEBUG    MQTT       Publishing: emon/emontx3cm17/9 164
2020-10-27 09:51:20,617 DEBUG    MQTT       Publishing: emon/emontx3cm17/10 -29
2020-10-27 09:51:20,617 DEBUG    MQTT       Publishing: emon/emontx3cm17/11 0
2020-10-27 09:51:20,617 INFO     MQTT       Publishing: emonhub/rx/10/values 0,112.27,0,0,10,0,0,-8,164,-29,0
2020-10-27 09:51:20,618 DEBUG    MQTT       Publishing: emon/emontx3cm15/MSG 0
2020-10-27 09:51:20,618 DEBUG    MQTT       Publishing: emon/emontx3cm15/Vrms 113.17
2020-10-27 09:51:20,619 DEBUG    MQTT       Publishing: emon/emontx3cm15/Grid1 -2150
2020-10-27 09:51:20,619 DEBUG    MQTT       Publishing: emon/emontx3cm15/Solar1 2656
2020-10-27 09:51:20,620 DEBUG    MQTT       Publishing: emon/emontx3cm15/Air1 0
2020-10-27 09:51:20,620 DEBUG    MQTT       Publishing: emon/emontx3cm15/Garage 34
2020-10-27 09:51:20,620 DEBUG    MQTT       Publishing: emon/emontx3cm15/7 14184
2020-10-27 09:51:20,621 DEBUG    MQTT       Publishing: emon/emontx3cm15/8 2602
2020-10-27 09:51:20,621 DEBUG    MQTT       Publishing: emon/emontx3cm15/9 185
2020-10-27 09:51:20,621 DEBUG    MQTT       Publishing: emon/emontx3cm15/10 1750
2020-10-27 09:51:20,622 DEBUG    MQTT       Publishing: emon/emontx3cm15/11 0
2020-10-27 09:51:20,622 INFO     MQTT       Publishing: emonhub/rx/8/values 0,113.17,-2150,2656,0,34,14184,2602,185,1750,0
2020-10-27 09:51:20,623 DEBUG    MQTT       Publishing: emon/junk/MSG 1431650885
2020-10-27 09:51:20,623 DEBUG    MQTT       Publishing: emon/junk/Vrms 323.98
2020-10-27 09:51:20,623 DEBUG    MQTT       Publishing: emon/junk/P1 21845
2020-10-27 09:51:20,624 DEBUG    MQTT       Publishing: emon/junk/P2 21845
2020-10-27 09:51:20,624 DEBUG    MQTT       Publishing: emon/junk/P3 21855
2020-10-27 09:51:20,624 DEBUG    MQTT       Publishing: emon/junk/P4 21845
2020-10-27 09:51:20,625 DEBUG    MQTT       Publishing: emon/junk/E1 1431655765
2020-10-27 09:51:20,625 DEBUG    MQTT       Publishing: emon/junk/E2 2863311533
2020-10-27 09:51:20,625 DEBUG    MQTT       Publishing: emon/junk/E3 1431655921
2020-10-27 09:51:20,626 DEBUG    MQTT       Publishing: emon/junk/E4 2863311542
2020-10-27 09:51:20,626 DEBUG    MQTT       Publishing: emon/junk/T1 82.93
2020-10-27 09:51:20,626 DEBUG    MQTT       Publishing: emon/junk/T2 82.93
2020-10-27 09:51:20,627 DEBUG    MQTT       Publishing: emon/junk/T3 82.93
2020-10-27 09:51:20,627 DEBUG    MQTT       Publishing: emon/junk/pulse 1431655765
2020-10-27 09:51:20,627 DEBUG    MQTT       Publishing: emon/junk/rssi -68
2020-10-27 09:51:20,628 INFO     MQTT       Publishing: emonhub/rx/15/values 1431650885,323.98,21845,21845,21855,21845,1431655765,2863311533,1431655921,2863311542,82.93,82.93,82.93,1431655765,-68
2020-10-27 09:51:24,426 DEBUG    RFM2Pi     34734 NEW FRAME : OK 5 0 0 3 0 3 0 117 43 130 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
2020-10-27 09:51:24,428 DEBUG    RFM2Pi     34734 Timestamp : 1603817484.426661
2020-10-27 09:51:24,428 DEBUG    RFM2Pi     34734 From Node : 5
2020-10-27 09:51:24,429 DEBUG    RFM2Pi     34734    Values : [0, 3, 3, 111.25, 13, 0, 0, 0, 0, 0, 0]
2020-10-27 09:51:24,429 DEBUG    RFM2Pi     34734 Sent to channel(start)' : ToEmonCMS
2020-10-27 09:51:24,429 DEBUG    RFM2Pi     34734 Sent to channel(end)' : ToEmonCMS
2020-10-27 09:51:24,460 DEBUG    MQTT       Publishing: emon/emonpi/HotTub1 0
2020-10-27 09:51:24,462 DEBUG    MQTT       Publishing: emon/emonpi/HotTub2 3
2020-10-27 09:51:24,463 DEBUG    MQTT       Publishing: emon/emonpi/power1pluspower2 3
2020-10-27 09:51:24,463 DEBUG    MQTT       Publishing: emon/emonpi/vrms 111.25
2020-10-27 09:51:24,464 DEBUG    MQTT       Publishing: emon/emonpi/t1 13
2020-10-27 09:51:24,465 DEBUG    MQTT       Publishing: emon/emonpi/t2 0
2020-10-27 09:51:24,466 DEBUG    MQTT       Publishing: emon/emonpi/t3 0

Does that help any?

If you are referring to this, it is node 5 (first number after the OK) - this is from the EmonPi.

This line must have a corresponding “NEW FRAME” line in the log.

In your configuration, you are publishing the same data twice to MQTT

Note it says Use with Nodes module which you are not using - just comment it out it is legacy.

These 2 MQTT publishes are the same data and that EmonTX must still be on and connected else you have a 4th one somewhere.

however, the publish with the topic emonhub will disappear into the ether.

Are they still connected by USB? Have you connected the power pins to the UART? That is powering them I suspect as all 3 are reporting data. Do not then power the EmonTX directly with DC as well.

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.

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?

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”.

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```

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.

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

Yes stopped

[email protected]:~ $ sudo service emonhub stop
[email protected]:~ $ 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.

@TrystanLea - Any ideas why this is failing?

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

image

Please post all of the debug output.

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 />

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…

[email protected]:/opt/emoncms/modules/usefulscripts/octopus $ which avrdude
/usr/bin/avrdude
[email protected]:/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
[email protected]:/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.

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

1 Like

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

1 Like

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

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