Should I update Emon Pi firmware to CM, and how?

steve-oemon · 2023-05-13T21:06:36.964Z

I have just an emonpi, no other kit, so I don’t use radio to transfer info.

I regularly update the software on the pi via the admin page on its website. I do a “full update”. I recently noticed that this doesn’t update the firmware, so after a bit of reading, I decided to update to the Continuous monitoring version, chosing
port ttyAMA0, hardware emonpi, radio format RFM69 Low power labs, Firmware …continuous monitoring… V1.1.4.

The update process shows on screen, then it appears to load and run. However, once installed, the main display I use, “MySolar” does not update at all; graphs do not update and the current power levels freeze.

Reverting the firmware to Jeelib Classic, V2.9.3, the display starts updating again.

Looking on the forums, I found this:
Updating an emonPi to emonPi_CM

This suggests that it’s not as simple as just updating the firmware, but also that some configuration needs to be chnaged, but I’m not sure what.

I think I’ve read that the discrete sampling branch isn’t going be updated any more, so I guess it makes sense to update to the continuous monitoring version.

Is that the case?

If that’s so, what do I need to do after updating the firmware, to get displays working again?

Robert.Wall · 2023-05-13T23:17:51.365Z

I have no knowledge of the LPL software, it sounds as if the values sent by the front end haven’t retained compatibility in number or position with the version that works for you.

The place to start looking will be the emonhub.conf file, I suggest you compare the file that works with the outputs generated by the software that doesn’t.

rupert · 2023-05-13T23:21:43.091Z

Briefly, The emonPi has two main parts -

The emonPi Board. This has an ATMega328 microcontroller chip on it, which makes the measurements using the CT1, CT2, 9V AC Sample, and the RJ45 I/O inputs. It also manages the RFM69 radio. The ATMega328 is where the firmware update is applied.
the Raspberry Pi, which runs the software. The emonPi Board is plugged into the Pi. The Pi receives the measurements from the ATMega328, stores and processes them and generates the Apps, such as “MySolar”.

The V1.1.4 firmware update to the ATMega328 gives the Continuous Monitoring (CM) version, and updates the radio format to LPL. It also changes the communication speed and content between the emonPi Board and the Pi. This is necessary to include the extra data from the CM version (Msg, pulse2count, E1, E2). The serial rate between the emonPi Board and the Pi has also increased from 38400 to 115200 baud.

The result is that the Pi cannot understand the V1.1.4 data, and the apps etc get no data.

To fix this, the settings in emonHub on the Pi must be edited - for more information see
https://docs.openenergymonitor.org/emonhub/index.html

and in particular
https://docs.openenergymonitor.org/emonhub/configuration.html#editing-the-emonhub-configuration-file

To correct the serial baud rate change, the emonPi [Interfacers] Configuration entry needs to be updated to:

[[emonpi]]
    Type = EmonHubOEMInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 115200
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,   

        group = 210
        frequency = 433
        baseid = 5                              # emonPi / emonBase nodeID
        calibration = 230V                      # (UK/EU: 230V, US: 110V)
        quiet = true                            # Disable quite mode (default enabled) to enable RF packet debugging, show packets which fail crc
        # interval =  300

To correct the different message content, the emonPi [Nodes] Configuration entry needs to be updated to:

[[5]]
    nodename = emonpi
    [[[rx]]]
       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

if you are new to editing the settings in emonHub, you can copy the original settings and then paste the copy underneath the original settings . The original settings can then be commented out by adding a hash symbol # at the start of each line. Then the copy can be edited to update it (or you could use the entries above instead of an edited copy of the original - I think they are correct!). If something goes wrong you still have a copy of the original that you can un-comment.

For example, the commented out original for the emonPi [Nodes] Configuration entry would look something like (note the firmware and hardware lines are optional, so may not be present):

#[[5]]
#    nodename = emonPi
#    firmware = emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino
#    hardware = emonpi
#    [[[rx]]]
#        names = power1,power2,power1_plus_power2,Vrms,T1,T2,T3,T4,T5,T6,pulseCount
#        datacodes = h, h, h, h, h, h, h, h, h, h, L
#        scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
#        units = W,W,W,V,C,C,C,C,C,C,p

After doing the firmware update and the emonHub changes, it should all start workiing again - fingers crossed!

I don’t know anything about the future of the discrete sampling branch.

Hope this helps …

P.S. You may find that the emonPi LCD display puts the measurements in the wrong place after the upgrade, as I did …

steve-oemon · 2023-05-13T23:23:55.787Z

Thanks, I’ll have a look and see if I can get that going.

TrystanLea · 2023-05-15T20:22:45.461Z

Hello @steve-oemon Yes I think it’s worthwhile updating

As you have no other kit, that makes it much more straightforward. @rupert’s reply covers the changes required.

Interested to hear if you can notice any improvements in the measurements.

AberDino · 2024-01-12T17:14:53.467Z

rupert:

P.S. You may find that the emonPi LCD display puts the measurements in the wrong place after the upgrade, as I did …

I upgraded and activated continuous monitoring on my emonPi today. It’s working but, like you, I also experience the issue where the measurements are in the wrong place. For example, it appears that the vrms reading appears as the “temp 1” reading. Not too big a deal, but I was wondering if there is a fix for this?

Robert.Wall · 2024-01-13T01:19:59.496Z

Welcome, Pieter, to the OEM forum.

AberDino:

the measurements are in the wrong place… the vrms reading appears as the “temp 1” reading

Can you explain this - where are you looking, and where is the right place? You should find all the information you require, if you want to use my ‘Native’ JeeLib format for the radio, here: The emonPiCM
Unfortunately, I haven’t actively worked on LPL nor am I up to date on the latest changes to use the LPL library to be able to help you with that.

If you are looking on the “Inputs” page of emonCMS, then as rupert attempted to explain above, it would seem that you have an incorrect entry for Node 5 in your emonhub.conf file. By way of explanation, data from the “emon” front end is sent as a stream of bytes, it’s emonhub.conf which matches those to what it expects from the front end. If the total number is correct but their order or the data types are wrong, your data gets scrambled.

If you mean the LCD display, then emonhub has no influence there once the data is inside emonCMS and the display is driven by emonCMS. The front end has access to the display data bus, its only direct contribution to the display is the currents when you’re calibrating (because currents are not normally sent out of the front end or from the emonTx) or the more familiar “Booting, please wait…” message.

rupert · 2024-01-13T01:33:04.239Z

After the LPL/CM firmware update, the incorrect results are displayed on the emonPi LCD display.

see

Updating an emonPi to emonPi_CM

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?

Robert.Wall · 2024-01-13T10:20:22.449Z

That’s @TrystanLea’s department. It looks as if emonPiLCD.py drives this data for the display, then probably yes, unless the problem is earlier in the chain between emonHub and the LCD. As far as I’m aware, the mechanism for that isn’t documented, and I’ve never found the time to research it.

AberDino · 2024-01-13T11:30:50.759Z

Thanks Robert, and apologies, I should have been clearer, I did mean the LCD display.

FYI, initially after I upgraded the firmware I wasn’t getting any readings, and that was because I hadn’t modified the emonhub.conf file. Once I corrected that, everything seems to work fine, apart from the misplaced readings on the LCD display. At least Power1 and Power2 are displayed properly though, so hence not too big a deal, but it would be nice to get it sorted at some point, hence my post.

Thanks,

Pieter

Robert.Wall · 2024-01-13T15:16:52.993Z

You could try updating emonCMS (only) if you didn’t as part of changing to CM (which only needs the front end changed), otherwise it’s two instances of the same problem for @TrystanLea to look at.

I haven’t got an emonPiCM running with sensors at present, so I can’t check.

TrystanLea · 2024-01-18T18:29:09.230Z

Hello @AberDino , checking this here with the emonSD-20Nov23 and a fresh copy of emonhub.conf which has emonHub autoconf enabled.

emonPi v1 discreet sampling

On an otherwise unconfigured emonPi v1 - using a new emonhub.conf - inputs appear like this in the inputs list with discreet sampling firmware, after also changing the /dev/ttyAMA0 baudrate to 38400:

image860×476 20.6 KB

It’s possible to update emonPiLCD.cfg to use these input names like this:

nano /opt/openenergymonitor/emonpi/lcd/emonPiLCD.cfg

[mqtt]
mqtt_user = emonpi
mqtt_passwd = emonpimqtt2016
mqtt_host = 127.0.0.1
mqtt_port = 1883
mqtt_emonpi_topic = emonhub/rx/5/values
mqtt_temp1_topic = emon/emonpi_5/t1
mqtt_temp2_topic = emon/emonpi_5/t2
mqtt_vrms_topic = emon/emonpi_5/vrms
mqtt_pulse_topic = emon/emonpi_5/pulsecount
mqtt_feed1_topic = emon/emonpi_5/power1
mqtt_feed2_topic = emon/emonpi_5/power2

or if it’s just a system that’s being updated and the old emonhub.conf is copied over then the old names should still be in place and emonPiLCD should pick them up as before.

emonPi v1 continuous sampling

1. An existing node 5 emonPi v1 discreet sampling node decoder needs removing

2. With autoconf enabled and /dev/ttyAMA0 baudrate set to 115200, the new decoder will get configured automatically and inputs will appear like this:

image849×779 33.6 KB

3. Perhaps the easiest option to fix the input names so that they match the emonPiLCD standard config is to change the node name from:

[nodes]
    [[5]]
        nodename = emonpiCM_5

to:

[nodes]
    [[5]]
        nodename = emonpi

this would fix power1, power2, vrms, t1, t2 but not pulsecount - and so an edit to emonPiLCD.cfg is still required if we want to see pulsecount.

Alternatively perhaps keeping the original emonpiCM_5 nodename as it is and changing the emonPiLCD.cfg config to the following would be better?

[mqtt]
mqtt_user = emonpi
mqtt_passwd = emonpimqtt2016
mqtt_host = 127.0.0.1
mqtt_port = 1883
mqtt_emonpi_topic = emonhub/rx/5/values
mqtt_temp1_topic = emon/emonpiCM_5/t1
mqtt_temp2_topic = emon/emonpiCM_5/t2
mqtt_vrms_topic = emon/emonpiCM_5/vrms
mqtt_pulse_topic = emon/emonpiCM_5/pulse1count
mqtt_feed1_topic = emon/emonpiCM_5/power1
mqtt_feed2_topic = emon/emonpiCM_5/power2

TrystanLea · 2024-01-18T18:47:34.159Z

There’s another somewhat confusing thing to make sure that’s configured correctly.

In EmonHubMqttInterfacer, node_format_enable needs to be disabled, set = 0

[[MQTT]]
    Type = EmonHubMqttInterfacer
    ...
    [[[runtimesettings]]]
        node_format_enable = 0

Then the emonPi v1 needs to be either rebooted or redis flushed which can be done from the Admin UI or by running:

$ redis-cli flushall

This is because the emonPiLCD script will use values from:

mqtt_emonpi_topic = emonhub/rx/5/values

first and we really want it to use the full node/input topic names directly…

I appreciate this is a bit convoluted to say the least!

I haven’t yet added the option to show input values on the emonPi2 LCD. @glyn.hudson is quite keen that we get this added in again and so when I revisit that it might be a good opportunity to find a more automated way of supporting variations in firmware like this.

rupert · 2024-01-22T10:42:55.219Z

@TrystanLea Thanks for the information about the emonPi v1 LCD configuration.

I came across a previous topic by chance …

Help to configure lcd display on emonpi emonPi

i need help to configure emonpi onboard lcd on image emonsd 17oct19 where is the default configuration file of lcd e.g emonPiLCD.cfg i go crazy to find it but none thank you

where it says about emonPiLCD.cfg:

Help to configure lcd display on emonpi

Note if you change it, it will block updates to the emonpi repository as Git will see it as a modified file.

Is the blocking of updates still true, or is there an easy workaround?

TrystanLea · 2024-01-22T17:12:59.269Z

Good point, yes it will block updates. I need to make that an ignored file once installed…

AberDino · 2024-01-23T18:35:42.077Z

Many thanks @TrystanLea, I am on emonSD-20Nov23, but as I restored the data from my previous setup as part of the process, I still had my old emonHub configuration file (so no autoconf). I had also already edited the node name to match the previous name (emonpi), so I modified the pulsecount entry in the emonPiLCD.cfg file, then modified the node_format_enable option in emonHub configuration file from 1 to 0, and rebooted the emonPi. I’m pleased to confirm this has resolved my issue .