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
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.
If you just click on this, what is the resulting output? Exactly the same?
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…
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.
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.