Hi, just got an emonPi2 - am I missing something fundamental or should I be able to see the voltage from the emonVs in the inputs? If Im interpreting this right, there’s some kind of cached value there from a long time ago (part of the image?) and its just not reading…
Unless you have the 3-phase version, you should see a value for V1 only, you will never see values for V2 & V3.
I can’t think of a possible reason for the voltage not updating when everything else is.
Did you allow enough time for your emonPi2 to complete its update when you first powered it up?
Have you done a controlled shutdown (either via the ‘Admin’ page or the front panel and pushbutton) and then restarted? (And if in any doubt, give it a while to update if it feels the need to do so - I’m not sure if, once interrupted, it can ever recover.)
@TrystanLea @glyn.hudson Why is the ONLY hint to the software version in the Pi2 front end in Docs
Open emon_DB_6CT.ino in an editor and change #define EMONTX5 to #define EMONPI2.
and not listed in Github???
Hiya, it is a three phase version, currently only L1 in use however.
I didn’t get an update initially, but I did manually update afterwards however (See 11.6.8 in screencap - was 11.4 on delivery IIRC)
Looking at the schematics (ugh, png not pdf?!) I can see that the VSENSx from the RJ11 (not RJ45 on schematic?) goes to an AVR first - which I assume is your front end. I cant see a way to read what type / version of firmware its running currently to check - I was going to do a manual update to see if that helps, but Im not clear on whether I should be choosing the DB or CM variants?
I just had a crack at updating the avr firmware from the web interface - I selected the file etc and hit [update firmware] but nothing ‘changes’ in the interface and no visible succes or failure, is it expected to be silent and if not is there a way to check what’s programmed?
And now I’m more confused - I just noticed in the inputs that there’s a ‘Vrms’ input so I wondered if that was the L1 representation instead, but on pulling the RJ11 it still reads as 240…?!
I assume all UK users are single phase - unless you say.
EmonLibCM was written for the emonTx V3, which has only a single voltage channel. So ‘DB’ is your answer. If you aren’t using ‘old’ emonTx’s or emonTH’s with RFM12B radios and have none or only newer ones with the RFM69CW radios, then you can update those and use the LPL radio library, otherwise you must fall back to the less capable JeeLib.
I’d advise getting KiCad to look at the schematics. It’s a bit of a learning curve, but it will read the Eagle schematic, though getting the board file right on first importing it can be a problem.
I think PDF is only a wrapper for PNG anyway? This diagram is for what I term the “emon front end” to distinguish it from the Pi itself, the two plugged together with the other bits and case being the emonPi.
I think it should tell you if you use the serial monitor (via Admin) Use ‘?’ show the options - the command is ‘l’ for ‘list the settings’.
Ok. I’ve pulled everything apart and looked at schematics and worked out what’s going on…
Metering across the emonVs R9 I can see 300mV as expected. However, when I connected it to the emonPi2 ti gets pulled down to 136mV… Hmm…
So it seems that recently there’s been a change from RJ11 to RJ45 with the connectors. I have an emonVs with RJ11 and a emonPi2 with RJ45. Even though pyhsically they’re compatible, rather than keep pin compatibility the pins have been re-assigned…
This is what happens when you connect the two :
n/c -> emonPi2 v2.0.1 Pin 1 (VS1)
emonVs 1.1 RJ11 pin 1 (GND) -> emonPi2 v2.0.1 Pin 2 (VS2)
emonVs 1.1 RJ11 pin 2 (5v) -> emonPi2 v2.0.1 Pin 3 (VS3)
emonVs 1.1 RJ11 pin 3 (n/c) -> emonPi2 v2.0.1 Pin 4 (+5v)
emonVs 1.1 RJ11 pin 4 (VS3) -> emonPi2 v2.0.1 Pin 5 (+5v)
emonVs 1.1 RJ11 pin 5 (VS2) -> emonPi2 v2.0.1 Pin 6 (GND - LINK)
emonVs 1.1 RJ11 pin 6 (VS1) -> emonPi2 v2.0.1 Pin 7 (GND)
n/c -> emonPi2 v2.0.1 Pin 8 (GND)
Hence, my VS1 is getting pulled down to ground. This seems like a fundamental oversight and Im kinda surprised that this hasn’t been spotted before! I’m glad nothing went pop…
Unless Im missing something really obvikous, the emonPi2 RJ45 pinnings would be the following to allow backwards compatibility with emonTx :
n/c -> emonPi2 v2.0.1 Pin 1 (GND)
emonVs 1.1 RJ11 pin 1 (GND) -> emonPi2 v2.0.1 Pin 2 (GND)
emonVs 1.1 RJ11 pin 2 (5v) -> emonPi2 v2.0.1 Pin 3 (+5v)
emonVs 1.1 RJ11 pin 3 (n/c) -> emonPi2 v2.0.1 Pin 4 (GND - LINK)
emonVs 1.1 RJ11 pin 4 (VS3) -> emonPi2 v2.0.1 Pin 5 (VS3)
emonVs 1.1 RJ11 pin 5 (VS2) -> emonPi2 v2.0.1 Pin 6 (VS2)
emonVs 1.1 RJ11 pin 6 (VS1) -> emonPi2 v2.0.1 Pin 7 (VS1)
n/c -> emonPi2 v2.0.1 Pin 8 (+5v)
This would give identical functionality and pin compatibility.
Where’s the best place to fire this into the projects workflow, a github issue I guess?
1 Like
No. Fire an email straight at The Shop.
Congratulations for spotting the problem. I doubt very much anything will change, but on the plus side Glyn & Trystan are usually quite good at sorting out mix-ups like this. I agree it’s something that should have been anticipated, but has clearly been missed.
Quite simple really - the 300 mV is derived from a c.t, so it’s actually passing less power when short-circuited.
I can make up an RJ11 / RJ45 bodge cable so it’s not the end of the world, just a shame!
Back on to the original question though - even with the mis-wiring, shouldn’t the AVR have still been reporting values for L1-3 even if the values themselves are junk? What i screen-shotted was the values not even being read as far as I could ascertain…
I have looked quickly at the sketch, whilst emonPi1 versions checked for the a.c. voltage at startup, the sketch I think you are running doesn’t appear to. And again, I’m not sure how the signal path inside the emonPi2 is now handled, but find it hard to believe that the powers etc are getting sent and not the voltages.
I agree. I would fully expect all three would be zero values or noise (low value random numbers). So I think I discount (but worth checking nevertheless) a fault in the front end DB processor and its physical connection to the Pi.
So the next stage is emonHub. Are you seeing anything there? (Admin →emonhub). You should see values going past. Grab a screenshot showing some lines starting “OK 5 …” and what follows to the next one and post it.
If that looks OK, all I can think is it’s a corrupt emonCMS.
With luck, this thread will get spotted in a day or so, though the email would probably be quicker, and Trystan will come up with a suggestion.
see the ‘emonVs questions’ topic (Dec 2023)
EDIT:
Perhaps there should be some compatibility notes about the emonVs RJ11 (emonTx4) version and the emonVs RJ45 (emonTx5, emonPi2) version in the Docs and on the relevant Shop pages.
It gets a bit complicated as I think there were three? versions of the emonVs RJ11 (emonTx4):
- single phase including a +5V PSU, with RJ11 (VS1,+5V) and USB-C (+5V) outputs
- three phase including a +5V PSU, with RJ11 (VS1/2/3,+5V) and USB-C (+5V) outputs
- single phase not including a +5V PSU, the emonVs RJ11 mini with an RJ11 (VS1) output
Also perhaps some details of converter cable wiring; although I’m not sure how well the RJ11 output on 1) and 2) would run an emonPi2 with just one wire pair for the +5V/GND. The USB-C output could be used for power though.
Not knowing which version of emonVs it was (I have a V0.2 with the 6P6C connector, and the label it is nothing like the one on my V1.1 (with the 8P8C connector), which looks the same as David’s label, which isn’t quite sharp enough to read), it was a bit difficult to know, especially as putting a 6-pin plug into a wider 8-pin socket wasn’t exactly obvious from David’s photo. I suspect, indeed hope, it was this that prompted David to look at the schematics.
To be honest I hadn’t even clocked it was an RJ45 socket instead of an RJ11 and I’ve been working with the things for over 30 years…! I only noticed when it wasn’t working and I popped the PCB out of the emonPi and noticed the additional outer pair of leaf springs / conductors not at the same angle as the inner ones…
Thanks that’s handy - I hadn’t clocked that post when digging around…
From the schematics, unless I’ve missed something the 3/1 phase versions are identical except the L2/L3 components don’t get populated so no issue there. The only counter intuitive thing in my eyes is the fact its a compatible connector chosen but with an incompatible pin assignment changed…
Curiously, this emonVs PCB here says v1.1 also but is defo 6p6c…
So, back to the original topic… 
Having identified all that, I’ve made up an RJ11 → RJ45 patch cable with the pinnings matched so that the right things go the right way and frustratingly the inputs still don’t seem to be reading… I guess the next step is to try and see if I can find out what the micro thinks is going on on it’s ADC inputs…
Having said that, Im still not clear if it’s running the right firmware, or even if my attempts to write new firmware succeed or fail or what’s programmed currently… 
Ive just spotted the EmonHub log and it shows the following :
2024-11-06 14:44:01,409 DEBUG EmonPi2 54 NEW FRAME : MSG:30,Vrms:213.81,P1:-1,P2:1,P3:0,P4:0,P5:0,P6:0,E1:200,E2:107,E3:98,E4:51,E5:41,E6:52,pulse:0
2024-11-06 14:44:01,410 DEBUG EmonPi2 54 Timestamp : 1730904241.409485
2024-11-06 14:44:01,411 DEBUG EmonPi2 54 From Node : EmonPi2
2024-11-06 14:44:01,411 DEBUG EmonPi2 54 Values : [30, 213.81, -1, 1, 0, 0, 0, 0, 200, 107, 98, 51, 41, 52, 0, 0, 0.0]
2024-11-06 14:44:01,412 DEBUG EmonPi2 54 Sent to channel(start)' : ToEmonCMS
2024-11-06 14:44:01,412 DEBUG EmonPi2 54 Sent to channel(end)' : ToEmonCMS
2024-11-06 14:44:01,561 DEBUG MQTT Publishing: emon/EmonPi2/MSG 30
2024-11-06 14:44:01,562 DEBUG MQTT Publishing: emon/EmonPi2/Vrms 213.81
2024-11-06 14:44:01,563 DEBUG MQTT Publishing: emon/EmonPi2/P1 -1
2024-11-06 14:44:01,565 DEBUG MQTT Publishing: emon/EmonPi2/P2 1
2024-11-06 14:44:01,566 DEBUG MQTT Publishing: emon/EmonPi2/P3 0
2024-11-06 14:44:01,567 DEBUG MQTT Publishing: emon/EmonPi2/P4 0
2024-11-06 14:44:01,568 DEBUG MQTT Publishing: emon/EmonPi2/P5 0
2024-11-06 14:44:01,569 DEBUG MQTT Publishing: emon/EmonPi2/P6 0
2024-11-06 14:44:01,571 DEBUG MQTT Publishing: emon/EmonPi2/E1 200
2024-11-06 14:44:01,572 DEBUG MQTT Publishing: emon/EmonPi2/E2 107
2024-11-06 14:44:01,573 DEBUG MQTT Publishing: emon/EmonPi2/E3 98
2024-11-06 14:44:01,574 DEBUG MQTT Publishing: emon/EmonPi2/E4 51
2024-11-06 14:44:01,575 DEBUG MQTT Publishing: emon/EmonPi2/E5 41
2024-11-06 14:44:01,576 DEBUG MQTT Publishing: emon/EmonPi2/E6 52
2024-11-06 14:44:01,577 DEBUG MQTT Publishing: emon/EmonPi2/pulse 0
2024-11-06 14:44:01,579 DEBUG MQTT Publishing: emon/EmonPi2/missed 0
2024-11-06 14:44:01,580 DEBUG MQTT Publishing: emon/EmonPi2/missedprc 0.0
2024-11-06 14:44:06,178 DEBUG emoncmsorg Buffer size: 3
So looks like L1-L3 don’t get read / published but dont know enough about the internals to know what to imply from that…
Hello @pev as I’ve mentioned via email, more than happy to send a replacement emonVs with an RJ45 output if this makes things easier/neater for you?
Did you try uploading the following firmware from Admin > Update > Firmware? any response in the log window?
Me too, I’ve been around here for far too long and never found the time to dig deep enough to find out, and I can’t find it documented in any intelligible way anywhere. At the same time, I’ve never seen the same fault reported for any emonPi version, this is why I can’t comprehend why the powers were being updated but the voltages weren’t, when they got sent consecutively in the same packet of data.
You’ll never see all 3 voltages with this first line (above) of data, so it looks as if you’ve got your front end sketch set up for single phase, 6 channels, no temperatures (i.e, using emonLibDB and not the older emonLibCM).
This is the sketch you appear to have: avrdb_firmware/emon_DB_6CT/emon_DB_6CT.ino at master · openenergymonitor/avrdb_firmware · GitHub and look at line 61. The compiled version you want should already be in your Pi under Admin → Update as something like (I can’t copy the drop-down box 
) “emonTx4 3-phase 12 channel LPL” or “emonTx4 3-phase 6 channel with pulse LPL”
2024-11-06 14:44:01,409 DEBUG EmonPi2 54 NEW FRAME : MSG:30,Vrms:213.81,P1:-1,P2:1,P3:0,P4:0,P5:0,P6:0,E1:200,E2:107,E3:98,E4:51,E5:41,E6:52,pulse:0
But it should be updating the only voltage at the same time as all the rest.
If you look at the Inputs page of emonCMS and click the Input API Help link top right, you’ll see the acceptable formats. You can send an input from the web browser by copying/editing/typing the appropriate string into the address line to send it to emonCMS. If that updates the voltage, I think it will narrow down the area to between emonHub and emonCMS - but I could easily be wrong.
Thanks - hadn’t got round to replying yet… A kind offer but I think all good as Ive just made up an RJ11 → RJ45 patch with the right pinnings ; it meters OK on the pi end so I imagine should be fine (eventually!)
Im not quite sure what I should be expecting to observe, but the process I’ve been folloiwing is :
- Go to Admin > Update
- In “UPDATE FIRMWARE ONLY” change :
i. Hardware: emonPi2
ii. Firmware: emonPi2 DB single phase, 6 channel firmware, pulso on analog, lpl v2.1.0 - Press Update Firmware
What happens is that the border of the update firmware button goes dark… ad that’s it. If I then click “Auto refresh” the viewer states that /var/log/emoncms/update.log does not exist…
If I ssh into the emonpi I’ve just spotted the following on pressing the update firmware button :
/var/log/emoncms/apache2-error.log
[Wed Nov 06 15:41:25.150483 2024] [php:error] [pid 835] [client 192.168.0.125:47350] PHP Fatal error: Uncaught Error: Call to private method Admin::runService() from global scope in /var/www/emoncms/Modules/admin/admin_controller.php:238\nStack trace:\n#0 /var/www/emoncms/core.php(80): admin_controller()\n#1 /var/www/emoncms/index.php(257): controller()\n#2 {main}\n thrown in /var/www/emoncms/Modules/admin/admin_controller.php on line 238, referer: http://192.168.0.124/admin/update
You can parallel all three phase inputs if you want to check the voltages on your new cable.
Hmm that’s a strange one, I haven’t seen that error before, might be worth trying a full update from the Admin page…
Or to upload firmware directly via ssh:
/opt/openenergymonitor/EmonScripts/update/atmega_firmware_upload.sh ttyAMA0 emonPi2_DB_6CT_1phase
or 3 phase:
/opt/openenergymonitor/EmonScripts/update/atmega_firmware_upload.sh ttyAMA0 emonPi2_DB_6CT_3phase