I understand your point, but it’s not something of my making. All of a sudden, there was an announcement that LPL library would be used. There was no prior discussion with me, no warning that the powers that be would not proceed with RFM69nTxLib, which I thought was not exactly, shall we say, “considerate”. That’s why there won’t be any further work on it, because apart from yourself and maybe one or two others (I have no means of getting numbers), several weeks of work in proving sketches for all the ‘legacy’ devices and writing it up was completely wasted. This doesn’t mean it won’t work again in your emonPi.
In case you missed this too, here’s the write-up that accompanied the release of the emonPiCM sketch.
The link for installing the sketch still “works”, but it’s a new version, not the original document, so I can’t vouch for it’s usefulness or its accuracy.
You can possibly still find the sketch at the address in this write-up, or here: emonPiFrontEndCM.zip (55.6 KB)
Incidentally, it would be almost trivial to convert RFM69nTxLib to have an option to use the LPL format in its transmitted messages, but it would not receive acknowledgements and therefore not re-transmit the message on failure to receive an acknowledgement.
This could be an option for you if you decide to go with LPL but not risk the penalty of reduced battery life when the RFM needs to go into receive mode and wait for the ACK message.
Ideally, the CM JeeLib Native update choice would be available in the setup/admin/upgrade section of emonCMS, but it isn’t.
And the Docs are missing a section on how to do it manually for the emonPi
An alternative might be to:
Install the Arduino Development System on a computer (I would go for the 1.x legacy version rather than the new 2.x version.
Install Roberts’s source code from the zip file plus any library files that are needed.
Compile the source to make the hex file. Then
Although there are no detailed instructions how to do this for the emonPi in the Docs, there are some instructions that might be useful on github for the RFM2Pi (the old emonBase module).
The RFM2Pi is just an atmega328 processor plus a RFM69 RF module. This is similar to the atmega328 measurement board in an emonPi, but without the power measurement circuitry. The github section “Upgrading RFM69Pi Firmware Direct from the Pi” gives a set of commands which you might be able to adapt for the emonPi:
# Install avrdude, and GPIO auto reset
sudo apt-get update
git clone https://github.com/openenergymonitor/avrdude-rpi.git ~/avrdude-rpi && ~/avrdude-rpi/install
# Grab latest firmware for RFM69Pi and perform the upload via serial
git clone https://github.com/openenergymonitor/RFM2Pi.git
cd RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/
sudo service emonhub stop
avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:RFM69CW_RF12_Demo_ATmega328.cpp.hex
sudo service emonhub start
The avrdude stuff may already be installed. You’d have to ignore the git clone part, put your hex file in a directory on the emonPi, and point the avrdude command to it instead of RFM69CW_RF12_Demo_ATmega328.cpp.hex
Ignore the parts about flashing the bootloader, as the atmega328 in your emonPi will already have one installed.
I’ve never tried this and I don’t know if it would work - no warranty!
I’m happy to say that all has been working reliably for a few days now. In case it helps anyone else in my situation, ultimately I did a manual update of the emonPi firmware to V2.9.3 (dated Jan 5 2021 and obtained from Releases · openenergymonitor/emonpi · GitHub) and got a working combination of emonhub settings:
RFM2Pi interfacer ‘EmonHubOEMInterfacer’
com_baud = 38400
Incidentally V2.9.3 is supposedly what you get if you use the normal Admin/Update/Update Firmware Only route, and select Hardware ‘emonPi’ and Radio format ‘RFM69 Jeelib Classic’. I cannot say why I didn’t try that route in the first place, except that perhaps I did, but didn’t get the correct emonhub settings to go with it.
So I don’t have contiunuous monitoring on my emonPi, which would be very nice to have, but I do have a working system, and that is more important to me. Given the problems you’ve also had @rupert, I’ll think twice before exploring the emonPi CM route again.
This means you must have converted your emonTx V3 & emonTH back to the JeeLib ‘Classic’ radio format?
You could have had CM on your emonPi, and I think you still can, if you swap the whole of your system to either JeeLib Native or LPL radio formats. I believe there are LPL sketches now on Github for the emonTx V3 and emonTH2. I think there has to be a vendetta against JeeLib Native, evidenced by removing it from the emonPi’s Admin → Update menu (it was offered in V10.7.4). You can understand me not wanting to put any more effort into something that’s discouraged by deliberately making it hard to install.
If you have the older emonTx and emonTH with RFM12B radios, you CANNOT use LPL, but you can use my JeeLib ‘Native’ library.
I can understand that you probably don’t want any more upheaval.
No. I was keen not to go down that path. I have not updated the emonTx’s or emonTH’s. This is why I’m so confused…
Correct right now. But given how much more I understand now (though far from 100%) I might pluck up the courage to try again. I think I could recover alot quicker next time if it goes wrong!
Do you mean they are working with your emonPi and “Classic” formatted radio packets? Or did you never update them to work with your emonPiCM?
The short explanation is:
You must consistently use either JeeLib ‘Classic’ (the original) OR JeeLib ‘Native’ OR LPL with each radio module in your installation. There is no interoperability between any of the three.
JeeLib ‘Classic’ and JeeLib ‘Native’ can be used with both the RFM12B and the RFM69CW radios.
LPL can only be used with RFM69 radios.
The emonPi can only do CM when using either JeeLib ‘Native’ or LPL.
Exactly that. Once I understood that getting CM on the emonPi was not going to be straightforward, what I most wanted was to get back to a stable state albeit with DS, which is happily where I am now.
Your short explanation above makes it very clear, thanks!