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 -
[[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
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/firmware/emonPi_CM/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/firmware/emonPi_CM/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:
[[emonpi]]
Type = EmonHubOEMInterfacer
[[[init_settings]]]
com_port = /dev/ttyAMA0
com_baud = 115200
[[[runtimesettings]]]
pubchannels = ToEmonCMS,
subchannels = ToRFM12,
It would be great if you can test this @rupert, thanks a lot!
1 Like
@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
`https://github.com/openenergymonitor/emonpi/releases/download/04-04-23/emonPi_CM_LPL_1_1_3.hex
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?
Thanks
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.
I’ve fixed an issue with the firmware update tool, it will now use the remote copy of firmware_available.json which defines the firmware download URL’s without requiring the local copy of the list to be updated. Though this does require an update to EmonScripts for it to work with the new code.
Can update your EmonScripts repository @rupert via Admin > Components > EmonScripts > Update?
and then after that try updating the emonPi firmware again?
@TrystanLea
I did the ’ update your EmonScripts repository via Admin > Components > EmonScripts > Update’
The update log said:
- current branch: master
- local changes: no
- git fetch: Fetching origin
Already on 'master'
- git checkout: Your branch is up to date with 'origin/master'.
- git pull: Already up to date.
- database update: no changes
- component updated
The version on the Admin > Components page has changed from 1.6.12 to 1.6.13.
I did the emonPi firmware update and this time I got
`https://github.com/openenergymonitor/emonpi/releases/download/20-04-23/emonPi_CM_LPL_1_1_4.hex
I updated my emonhub config 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 # Interval to transmit time to emonGLCD (seconds)
The inputs are updating and appearing correctly on the input page.
However the LCD is still incorrect and displays
Data LCD Display feed
Power 1: 0 0
Power 2: 0 0
Vrms: 0 253
Pulse 300p 0
Temp 1: 253.24 22.25
Temp 2: 22.25 300
So progress …
1 Like
Great, thanks @rupert could you keep an eye on packet loss and post the results? should be listed in the inputs for the emonTx4, missed and missed_prc?