Updating an emonPi to emonPi_CM

My emonPi has been left untouched since it was installed in about September 2021. I thought it would be a good idea (!) to update it to the latest emonPi_CM software. This would give the benefits of the emonPi_CM continuous sampling firmware, and moving to the Low Power Labs (LPL) radio format to get the the packet acknowledgment and retry features. Before I started, I had updated the emonCMS to the latest version.

My experiences:

I used the emonPi_CM update process to do the update from the emonPi user interface, as described at:


This all went smoothly. But when I looked at the inputs, there were no inputs from the emonPi. My first attempt at a fix was to do a full update of the emonPi, but there was no change. However, looking at the emonHub log, I could see that there were regular inputs from the emonPi, but they were being discarded as being in error. So I wondered if it was something to do with the message format.

I had a look at the code for the emonPi_CM on the OEM github, and discovered that the emonPi_CM message format is different to the original emonPi_DS_jeelib_classic - in a good way!

emonPi_DS_jeelib_classic: sends power1,power2,power1_plus_power2,Vrms,T1,T2,T3,T4,T5,T6,pulseCount

emonPi_CM sends

So the emonPi_CM does three extra measurements of pulse2count,E1,E2 as well as continuous monitoring - congratulations to OEM!

This means that a new node configuration is required. I commented out the original emonpi config and used an edited version (see below) from

    nodename = emonpiCM
        names = Msg, power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulse1count,pulse2count,E1,E2
        datacodes = L, h, h, h, h, h, h, h, h, h, h, L, L, l, l
        scales = 1, 1,1,1, 0.01, 0.01,0.01,0.01,0.01,0.01,0.01, 1, 1, 1,1
        units = W,W,W, V, C,C,C,C,C,C, p, p, Wh,Wh

note that the original version mentioned above has an extra comma in front of the first ‘W’ in units, which caused a critical error in my emonHub when installed :
units = ,W,W,W, V, C,C,C,C,C,C, p, p, Wh,Wh

Because the nodename above is emonpiCM the original feed set up will remain with the old emonPi name, but get no inputs. I edited the feeds to change the node from emonpi to emonpiCM, which moved them over to the emonpiCM node. Perhaps this could be avoided by adding the extra entries to the original emonpi config, but I didn’t try this.

In order to keep the JeeLib Classic format messages coming into the emonPi from my emonTx3 (until I get round to updating it), I have added a JeeLink 433MHz (v3c) USB module (note 1) to the emonPi. This module is compatible with the JeeLib Classic format, and acts as a second RX/TX. For anyone interested, the emonHub entry I used for the Jeelink to get it working is:

  Type = EmonHubJeeInterfacer
    com_port = /dev/ttyUSB0
    com_baud = 57600             #57600 for Jeelink
    pubchannels = ToEmonCMS,
    subchannels = ToRFM12,

        group = 210
        frequency = 433
        baseid = 5                              # emonPi / emonBase nodeID
        quiet = true                            # Report incomplete RF packets (not implemented on emonPi)
        calibration = 230V                      # (UK/EU: 230V, US: 110V)
        # interval =  0                         # Interval to transmit time to emonGLCD (seconds)

note 1 A moteino can also be used - see

The only things that don’t seem to work so far are the data on the emonPi LCD display - power 1, power 2, Vrms, Pulse, Temp 1 and Temp 2 are all incorrect. This is due perhaps to the new emonPi_CM message format, and emonPiLCD.py needs updating? @TrystanLea

I hope this is useful for other users …


Maybe you should have read the release notes and documentation here first. I have no control over what appears on Github.

@Robert.Wall Sorry - I was just using the OEM Docs section and Github. Where are the release notes and documentation you are referring to?

In the forum - it’s the only place now I have access to.

A search of the forum for emonPi_CM found your topic

on using your emonLibCM on the emonPi with the JeeLib Native format.

Personally, I would like to thank you very much for the large amount of work that you have done on emonLibCM and the RFM12/RFM69, and the support you provide. I’m sure this has been of great benefit to OEM.

I have not found any obvious release notes or documentation for the emonPi_CM upgrade (to emonPiCM and LPL format) on the forum. I would be very grateful if you could provide a link. Thanks very much for your help.

I thought you were referring to the RFM69 Native library, which is almost the same as LPL (and with minor changes, a compatible version could be made). I won’t be doing anything on the LPL library for the emonPi any time soon, I’m totally engaged with the 12-input 3-phase emonTx4 and the supporting documentation.

I am running a cut-down (by @Trystan) version of LPL in an emonPi at present, I expect he’ll make this available with the CM library for the emonPi front end in due course.

I thought I was right - it’s only LPL that’s missing. All the documentation for emonLibCM and the sketch for the emonPi was linked in that topic. You could carry on with the RFM69nTxLib if you want a proven system now (or indeed, a year or two ago).

The emonPi_CM update (to emonPiCM and LPL format) that I used is available directly from the emonPi user interface (left-hand sidebar) at Admin/Update/Update firmware. It is documented in the OEM Docs section and described as ‘New 16th Feb 2023’, so I presume it is officially released.

As mentioned, it gives the extra measurements of pulse2count,E1,E2 and needs an updated node configuration entry in emonHub. Neither of these are described in the OEM Docs, so I thought my post might be helpful to others.

So far it seems to be working fine, apart from the emonPi LCD display, which perhaps needs an update to the emonPi LCD software (emonPiLCD.py), not the ATMega328 front end.

Looking more deeply in the forums, it seems that the need for a new emonHub node configuration for the emonPi_CM software has been found before by others, who have gone down the same path as I have -

and has been solved with the help of @Robert.Wall .

It seems that the node configuration that I used is not correct, and should be -

    nodename = emonpi
       names = Msg, power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulse1count,pulse2count,E1,E2
       datacodes = L, h, h, h, h, h, h, h, h, h, h, L, L, l, l
       scales = 1, 1,1,1, 0.01, 0.01,0.01,0.01,0.01,0.01,0.01, 1, 1, 1,1
       units = n,W,W,W,V,C,C,C,C,C,C,p,p,Wh,Wh

which has a ‘n’ unit for the Msg data. It also has a nodename of emonpi, so the the original emonpi feeds do not have to be renamed. I have corrected my node configuration to suit.
It would be good if this information could be put into the documentation.

The measurement feeds from the emonPi are updating correctly in emonCMS, while data on the emonPi LCD display is still incorrect, and a comparison shows -

Data        LCD Display                feed
Power 1:      ---  (three dashes)        0
Power 2:      ---  (three dashes)        0
Vrms:          0                         253.5
Pulse         300                        0
Temp 1:       253.5                      19.75
Temp 2:       19.75                      300

So some of the data is there in the LCD display, but in the wrong places. Does emonPiLCD.py need updating or am I doing something wrong?

Thank you @rupert that’s great, glad you got this running and thank you for sharing your process there.

The latest version of the emonPi CM firmware v1.1.3, released on the 4th of April (@rupert this suggests that you are running this version) uses the cut down version of the LowPowerLabs library. I made that change immediately and updated the pre-compiled hex file when we discovered the issue. Change log included in the firmware header: emonpi/emonPi_CM.ino at master · openenergymonitor/emonpi · GitHub

Mostly identical, but I take your point that using the original node name of emonpi is probably better given that it will reuse existing inputs. I have updated the suggested node decoder here: emonpi/emonPi_CM.ino at master · openenergymonitor/emonpi · GitHub

Will take a look at the LCD issue

@TrystanLea Thanks for the quick reply.

I think I’m using the 1.1.3 version - I think I upgraded on the 15th of April. I’m not sure if the version number is on the Admin/System Information page.

I originally used the emonPiCM node name for the emonPiCM install, and had to edit my original emonPi feeds to move them to the emonPiCM node. Then I had to edit the emonPiCM inputs to add the feeds back in.

Then I tried using the emonPi node name instead for the emonPiCM install, and the feeds didn’t need to be edited. However, now under the emonPi input tab, I have the following inputs -

power1                                active
power2                                active
power1pluspower2                      active
vrms                                  active
t1                                    active
t2                                    active
t3                                    active
t4                                    active
t5                                    active
t6                                    active
pulsecount                            inactive
12, 13, 14, 15, 16, 17, 18, 19, 20    all inactive
Msg                                   active
pulse1count                           active
pulse2count                           active
E1                                    active
E2                                    active
missed                                active 
missedprc                             active 

So I’m not sure which is better! I haven’t tried deleting the 10 inactive inputs yet!

Thanks for offering to look at the LCD issue.

Those 12 - 20 “inactive” inputs were from an otherwise valid message with no names to attach to the values. They can go, especially if you haven’t added any processing. They’ll reappear if they’re not really “inactive”.

Thanks for the tip. I’ve deleted them and they haven’t come back yet - fingers crossed!

I’ve updated the emonPi_CM firmware available via the emoncms upload mechanism. The version is now 1.1.4 and includes improvements to the timing in the main loop. Mostly the removal of fixed delays. The result is lower packet loss and a lower number of retries required when acknowledgments are requested by the emonTx4.

I have also changed the serial baud rate from 38400 to 115200 - in order to reduce the amount of time spent printing to serial so that the emonPi can get back to radio related activity faster.

Which requires an update in emonhub.conf to read at the new baud rate, e.g:

    Type = EmonHubOEMInterfacer
        com_port = /dev/ttyAMA0
        com_baud = 115200
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,

It would be great if you can test this @rupert, thanks a lot!

1 Like

@TrystanLea Thanks very much for the update - I’ll try it out and let you know …

@TrystanLea I updated my emonhub to 115200 as above, and updated my firmware on the update page to

port etc: ttyAMA0/emnoPi/RFM69 Low Power Labs

firmware: emonPi continuous sampling firmware, lowpowerlabs, 1.1.4

However, the update log said I was downloading
and said the size was 31902 bytes.

I powered off the emonpi and restarted it.

There are now no emonPi or LPL radio inputs …

Putting emonhub back to 38400 restores the emonPi and LPL radio inputs, so I would think that I haven’t got the real 1.1.4 emonPi_CM firmware …

Ah you may need to run the emonPi update first or more specifically the admin > components> Emonscripts repository.

I may be missing something, if it listed 1.1.4 but still downloaded 1.1.3, I’m out at the moment, will check here later

I just tried updating the scripts, and then tried the firmware update listed as 1.1.4, but still got 1.1.3

I am on the master branch - not sure if that is the correct one?


Hi @TrystanLea - have you updated the Docs? Perhaps a specific section on moving to the CM Lib might work?

Need to detail the changes to emonhub required to make this work, I’d suggest.