I do have (of course) every version of emonLibCM that I released, I don’t (of course) necessarily have all the other versions because it’s rare that anyone is notified of something changed or appearing on Github.
The first digging step revealed there is no V2.4 of emonLibCM. The present and last one on Github is my V2.2.2.
So, I’m at a loss to explain that step you illustrate.
I apologise Robert. I have checked the library contents and can see that the version information of the eminLibCM I downloaded form github is V2.2.2. I think I got mixed up with the emonTx3cm firmware version number.
No harm done, only a few handfuls of electrons have been mildly inconvenienced..
These libraries, at least the copies I have of them, appear to be far from identical.
As the emonTx3 LPL radio signal was recieved by the RFM69Pi, when loaded with the emonTh2 firmware, I had a good look at the parts of both the emonTh2 and emonTx3 sketches that send the data.
The emonTh2 uses the RFM69_LPL library and the function ‘send_csma’. The standard emonTx3 sketch uses the RFM69 library and the function ‘sendWithRetry’. The majority of other emonTx3 sketch calls to the RFM69 library looked the same with the exception of the ‘setPowerLevel’ call in the initialisation. So I tried pointing the emonTx3 schetch to the RFM69_LPL library with the ‘setPowerLevel’ function commented out and Lo and Behold - Success. The data packets were recieved and sucessfully decoded.
2026-07-05 18:58:38,308 INFO MainThread EmonHub v2.7.6
2026-07-05 18:58:38,308 INFO MainThread Opening hub...
2026-07-05 18:58:38,308 INFO MainThread Running as user: pi
2026-07-05 18:58:38,308 INFO MainThread Logging level set to DEBUG
2026-07-05 18:58:38,308 INFO MainThread Creating EmonHubJeeInterfacer 'RFM69Pi'
2026-07-05 18:58:38,309 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2026-07-05 18:58:40,310 WARNING MainThread Device communication error - check settings
2026-07-05 18:58:40,310 INFO MainThread Setting RFM69Pi baseid: 5 (5i)
2026-07-05 18:58:41,310 INFO MainThread Setting RFM69Pi frequency: 433 (4b)
2026-07-05 18:58:42,310 INFO MainThread Setting RFM69Pi group: 210 (210g)
2026-07-05 18:58:43,311 INFO MainThread Setting RFM69Pi quiet: 0 (0q)
2026-07-05 18:58:44,311 INFO MainThread Setting RFM69Pi calibration: 230V (1p)
2026-07-05 18:58:45,311 DEBUG MainThread Setting RFM69Pi pubchannels: ['ToEmonCMS']
2026-07-05 18:58:45,311 DEBUG MainThread Setting RFM69Pi subchannels: ['ToRFM12']
2026-07-05 18:58:45,312 INFO MainThread Creating EmonHubMqttInterfacer 'MQTT'
2026-07-05 18:58:45,312 DEBUG MainThread Setting MQTT pubchannels: ['ToRFM12']
2026-07-05 18:58:45,312 DEBUG MainThread Setting MQTT subchannels: ['ToEmonCMS']
2026-07-05 18:58:45,312 INFO MainThread Setting MQTT node_format_enable: 1
2026-07-05 18:58:45,312 INFO MainThread Setting MQTT nodevar_format_enable: 1
2026-07-05 18:58:45,312 INFO MainThread Setting MQTT nodevar_format_basetopic: emon/
2026-07-05 18:58:45,312 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2026-07-05 18:58:45,313 DEBUG MainThread Setting emoncmsorg pubchannels: ['ToRFM12']
2026-07-05 18:58:45,313 DEBUG MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2026-07-05 18:58:45,313 INFO MainThread Setting emoncmsorg apikey: set
2026-07-05 18:58:45,313 INFO MainThread Setting emoncmsorg url: https://emoncms.org
2026-07-05 18:58:45,313 INFO MainThread Setting emoncmsorg senddata: 1
2026-07-05 18:58:45,313 INFO MainThread Setting emoncmsorg sendstatus: 1
2026-07-05 18:58:45,313 INFO MainThread Setting emoncmsorg sendnames: 0
2026-07-05 18:58:45,313 INFO MainThread Setting emoncmsorg compress: 0
2026-07-05 18:58:45,313 DEBUG MainThread Automatic configuration of nodes disabled
2026-07-05 18:58:48,515 DEBUG RFM69Pi 1 NEW FRAME : OK 18 8 0 0 0 192 93 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 48 117 48 117 48 117 48 117 0 0 0 0 0 (-74)
2026-07-05 18:58:48,515 DEBUG RFM69Pi 1 Timestamp : 1783241928.515303
2026-07-05 18:58:48,516 DEBUG RFM69Pi 1 From Node : 18
2026-07-05 18:58:48,516 DEBUG RFM69Pi 1 Values : [1431655773, 21.97, 218.45000000000002, 21845, 21845, 21845, 21845, 1431655765, 1431655765, 1431655765, 1431655765, 218.45000000000002, 218.45000000000002, 218.45000000000002, 218.45000000000002, 82.93, 82.93, 82.93, 82.93, 1431655765, 85, 0, 0]
2026-07-05 18:58:48,516 DEBUG RFM69Pi 1 RSSI : -74
2026-07-05 18:58:48,516 DEBUG RFM69Pi 1 Sent to channel(start)' : ToEmonCMS
2026-07-05 18:58:48,516 DEBUG RFM69Pi 1 Sent to channel(end)' : ToEmonCMS
2026-07-05 18:58:48,615 INFO MQTT Connecting to MQTT Server
2026-07-05 18:58:48,715 DEBUG emoncmsorg Buffer size: 1
2026-07-05 18:58:48,716 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?sentat=1783241928 (243 bytes of data, 1 frames, uncompressed)
2026-07-05 18:58:48,716 INFO MQTT connection status: Connection successful
2026-07-05 18:58:48,717 DEBUG MQTT CONACK => Return code: 0
2026-07-05 18:58:48,817 INFO MQTT on_subscribe
2026-07-05 18:58:49,735 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org (1019 ms)
2026-07-05 18:58:58,425 DEBUG RFM69Pi 2 NEW FRAME : OK 18 9 0 0 0 192 93 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 48 117 48 117 48 117 48 117 0 0 0 0 0 (-72)
2026-07-05 18:58:58,426 DEBUG RFM69Pi 2 Timestamp : 1783241938.425685
2026-07-05 18:58:58,426 DEBUG RFM69Pi 2 From Node : 18
2026-07-05 18:58:58,426 DEBUG RFM69Pi 2 Values : [1431655772, 21.97, 218.45000000000002, 21845, 21845, 21845, 21845, 1431655765, 1431655765, 1431655765, 1431655765, 218.45000000000002, 218.45000000000002, 218.45000000000002, 218.45000000000002, 82.93, 82.93, 82.93, 82.93, 1431655765, 85, 0, 0]
2026-07-05 18:58:58,426 DEBUG RFM69Pi 2 RSSI : -72
2026-07-05 18:58:58,426 DEBUG RFM69Pi 2 Sent to channel(start)' : ToEmonCMS
2026-07-05 18:58:58,426 DEBUG RFM69Pi 2 Sent to channel(end)' : ToEmonCMS
2026-07-05 18:58:58,526 DEBUG MQTT Publishing: emon/emontx3cm18/MSG 1431655772
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/Vrms 21.97
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/F 218.45000000000002
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/P1 21845
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/P2 21845
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/P3 21845
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/P4 21845
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/E1 1431655765
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/E2 1431655765
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/E3 1431655765
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/E4 1431655765
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/pf1 218.45000000000002
2026-07-05 18:58:58,527 DEBUG MQTT Publishing: emon/emontx3cm18/pf2 218.45000000000002
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/pf3 218.45000000000002
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/pf4 218.45000000000002
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/T1 82.93
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/T2 82.93
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/T3 82.93
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/T4 82.93
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/pulse 1431655765
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/error 85
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/missed 0
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/missedprc 0
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emon/emontx3cm18/rssi -72
2026-07-05 18:58:58,528 INFO MQTT Publishing 'node' formatted msg
2026-07-05 18:58:58,528 DEBUG MQTT Publishing: emonhub/rx/18/values 1431655772,21.97,218.45000000000002,21845,21845,21845,21845,1431655765,1431655765,1431655765,1431655765,218.45000000000002,218.45000000000002,218.45000000000002,218.45000000000002,82.93,82.93,82.93,82.93,1431655765,85,0,0,-72
I’d say this definately confirmes it is the LPL library. Where to from here?
Unfortunately I am very much past the point where I can decipher the differences between the two libraries and I am unsure of the issues with just swapping libraries and ignoring the power level setting. I remember reading somewhere that it was dangerous to set the power output to maximum as operating the radio without a suitable antenna connected could result in ‘letting the smoke out’ so I did not operate it like this for long.
This appears to indicate that the currently published firmware for the emonTx3 for LPL operation has an error somewhere in its interaction with the RFM69 library. My sketch is based on V2.4.0 of the emonTx34_CM firmware.
That’s because retries will significantly shorten battery life.
LPL can operate in a mode where it adjusts the transmit power level based on feedback from the receiver - as I understand it, if if fails to get an acknowledgment, it winds the power up, and when it does, it winds it down again. I think we don’t use that.
We default to setting the output power at +7 dBm, which equates to setPowerLevel(25);. The power level settings range is from 0 – 31 representing -18 dBm to +13 dBm in steps of 1 dBm. It’s quite safe to run at +7dBm without an antenna or at the wrong frequency (which as far as the RFM is concerned, is the same thing - it can’t radiate the power so it cooks itself 
6 dB below max, ¼ power, is OK ).
I agree. I’d spent a bit of time looking into it and gave up, figuring it would be easier to rewrite your sketch from scratch – or at least the RF bits – than waste time fiddling.
So, I think if you set the power level as part of setup() after all the eeprom etc settings have been done and the RFM initialised, using the native LPL API call radio.setPowerLevel(25); you should be OK.
N.B. radio comes from here:
#if RadioFormat == RFM69_LOW_POWER_LABS
RFM69 radio;
#endif
Not so successfully decoded unfortunately. 
The emonTx3 was only powered by the programmer at the time so all the values should be zero with the exception of the assumed voltage. The frame info in the emonhub log above looks like it has a lot of zeros, but the published values are not consistent. More digging unfortunately.
If you’re receiving data but emonHub is either rejecting it or not decoding it sensibly, that points towards the node definition in emonhub.conf being different to the data structure that the emonTx is sending. If the byte count does not match, it rejects it. If the lengths of the individual elements are wrong (e.g, two integers instead of one long, or say a long and then an integer instead of an integer and then a long), then the numbers won’t make sense – as will signed vs unsigned if they’re large enough or negative.
I’m getting a bit confused as to where you’re at now. I’ll be losing my Internet for a few hours tomorrow, if I’m able I’ll try to get your sketch working with a version of LPL, test as much of it as I can, and zip up your sketch (maybe modified) and the libraries I used to send to you once I’ve got comms back.
Do you know if the LPL you’ve used uses 433.00 MHz or 433.92 MHz – and which one do you want to use going forwards? I think we agreed it will be 433.92 as that is in the centre of the band – not that I think it matters, given the minimal likelihood of you causing interference with a neighbour.
Unfortunately, we’re in the middle of an unaccustomed heatwave, and I can’t think straight in those conditions. If that happens, I might not be able to do it for several days.
So am I, possibly related to trying to solve multiple problems at once.
The transmitting devices appear to be all configured for 433.00 MHz. The emonhub log indicates that the RFM69Pi is configured for 433 MHz.
Yes - 433.92 MHz, which looks like it will require the RFM69Pi frequency to be set. I assume this is achieved via the serial interface provided within emoncms.
My next thing to dig into…
That is relatively simple. It should be as a comment in the sketch, which you copy into your emonhub.conf
Failing that, look at the struct which defines the message the RFM transmits, and allocate each element in the three strings according to that. Here’s a link to how to do it emonHub Configuration File — OpenEnergyMonitor 0.0.1 documentation
I haven’t forgotten, I’m afraid everything went belly-up here. My fibre broadband installation managed to drill into a gas pipe, so quite a bit of excitement. That’s all fixed now, but it has screwed me up for two days. Now it’s got extremely hot here, and my brain is starting to malfunction. I think it’s safer to wait for the weather to cool down before I make a serious attempt at getting a system working for you.
Thank you Robert.
I had a emonTx3 running last night with the LPL radio format looking into the emonhub decoding and reproduced the results in the emonhub log entry above. The NEW FRAME entries in the log are consistent with the data being sent, so I appear to have the radio format sorted out. The decoding according to the data codes line in the node configuration is incorrect and I don’t understand why. Operating with just the programmer connected and supplying power, the transmitted data was almost all zeros and yet the decoded values are all non zero. I can correctly manually decode the frame. I have tried multiple interfaces and multiple data code specifications. I am now looking through interfacer code…
The information at this link appears to be incorrect. For int values in the transmitted data structure, it recommends using the data code i, however emonhub threw an error when the data codes were identified that way associated with inconsistent lengths. No data length error when the int values were identified as h as you indicated above, but the values identified for posting are unrecognisable.
Are you still using the sketch you sent me - or at least, the same data struct ?
typedef struct {
unsigned long Msg;
int Vrms,F,P1,P2,P3,P4; // V2.4.0.J F added for line frequency
long E1,E2,E3,E4;
int pf1,pf2,pf3,pf4; // V2.4.0.J added power factors
int T1,T2,T3,T4; // V2.4.0.J added T4
unsigned long pulse;
boolean error; // V2.4.0.J added error signal
} PayloadTX;
PayloadTX emontx;
If you are, you should have
datacodes = L, h,h,h,h,h,h, l,l,l,l, h,h,h,h, h,h,h,h, L, c
(For readability, I’ve split it into groups to correspond to the lines of code.)
That’s 53 bytes, which appears to fit. The 18 is the Node ID and isn’t decoded by this.
NEW FRAME : OK 18 8 0 0 0 192 93 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 48 117 48 117 48 117 48 117 0 0 0 0 0 (-74)
But that’s a 4-byte integer, theint in Arduino land is 2 bytes, so h, or H if it’s unsigned.
Yes - but with the RFM69_LPL.h library referenced instead of the RFM69.h as per the original V2.4.0 sketch and the radio.setPowerLevel(EEProm.rfPower) line commented out. The radio power is set to 25 internally in the RFM69_LPL.hlibrary, which is what the sketch was doing. The data struct is the same.
Quite a lot actually. I checked my node [[18]] configuration and it was still there. Took it out and the decoded values now appear reasonable. I now have it set as:
[[18]]
nodename = emontx3cm18
[[[rx]]]
names = MSG, Vrms, F, P1, P2, P3, P4, E1, E2, E3, E4, pf1, pf2, pf3, pf4, T1, T2, T3, T4, pulse, error
datacodes = L,h,h,h,h,h,h,l,l,l,l,h,h,h,h,h,h,h,h,L,b
scales = 1,0.01,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1,1
units = n,V,Hz,W,W,W,W,Wh,Wh,Wh,Wh,n,n,n,n,C,C,C,C,p,b
with the result
2026-07-10 17:02:38,787 DEBUG RFM69Pi 42 NEW FRAME : OK 18 44 0 0 0 192 93 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 48 117 48 117 48 117 48 117 0 0 0 0 0 (-77)
2026-07-10 17:02:38,787 DEBUG RFM69Pi 42 Timestamp : 1783666958.787196
2026-07-10 17:02:38,787 DEBUG RFM69Pi 42 From Node : 18
2026-07-10 17:02:38,787 DEBUG RFM69Pi 42 Values : [44, 240, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 300, 300, 300, 300, 0, 0, 0, 0.0]
2026-07-10 17:02:38,787 DEBUG RFM69Pi 42 RSSI : -77
2026-07-10 17:02:38,787 DEBUG RFM69Pi 42 Sent to channel(start)' : ToEmonCMS
2026-07-10 17:02:38,788 DEBUG RFM69Pi 42 Sent to channel(end)' : ToEmonCMS
2026-07-10 17:02:38,978 DEBUG MQTT Publishing: emon/emontx3cm18/MSG 44
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/Vrms 240
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/F 0
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/P1 0
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/P2 0
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/P3 0
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/P4 0
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/E1 0
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/E2 0
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/E3 0
2026-07-10 17:02:38,979 DEBUG MQTT Publishing: emon/emontx3cm18/E4 0
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/pf1 0
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/pf2 0
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/pf3 0
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/pf4 0
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/T1 300
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/T2 300
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/T3 300
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/T4 300
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/pulse 0
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/error 0
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/missed 0
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/missedprc 0.0
2026-07-10 17:02:38,980 DEBUG MQTT Publishing: emon/emontx3cm18/rssi -77
2026-07-10 17:02:38,981 INFO MQTT Publishing 'node' formatted msg
2026-07-10 17:02:38,981 DEBUG MQTT Publishing: emonhub/rx/18/values 44,240,0,0,0,0,0,0,0,0,0,0,0,0,0,300,300,300,300,0,0,0,0.0,-77
So I find that I have to apologise again for not addressing your questions as you ask them.
To move to the question of radio frequency, I can see how to set it in the sketch and the RFM69_LPL.h library has #define RF69_433_92MHZ 49. I note at this point that this value is not defined in the RFM69.h library.
There is a setting for the RFM69Pi frequency in the interfacer settings:
[[RFM69Pi]]
Type = EmonHubOEMInterfacer
[[[init_settings]]]
com_port = /dev/ttyAMA0
com_baud = 38400 # 9600 for old RFM12Pi
[[[runtimesettings]]]
pubchannels = ToEmonCMS,
subchannels = ToRFM12,
group = 210
frequency = 433
baseid = 5 # emonPi / emonBase nodeID
calibration = 230V # (UK/EU: 230V, US: 110V)
quiet = false # Disable quite mode (default enabled) to enable RF packet debugging, show packets which fail crc
# interval = 300 # Interval to transmit time to emonGLCD (seconds)
What value needs to be set here?
That is correct. It was introduced to kill a long string of zero values when the emonTx is first used, with possibly no sensors connected. When that happened, the receiver would lose sync and fail on a checksum error. It is not needed with LPL because the encryption achieves the same goal.
That’s a good question, and it looks as if nobody has thought about it.
The “new” SPI Interfacer has this:
freqBand = 49 # 49 = 433.92 MHz (new frequency) change to 43 = 433 MHz for legacy
Am I right in thinking you have the “old” RFM69Pi with the radio module and processor and not the newer SPI version which has only the radio module?
Sniffing around, it looks as if you might need to recompile and upload the processor code compiled with a version of LPL that’s got the registers set for 433.92 MHz.
I know very little in depth about Interfacers. You could try frequency = 433.92 in your interfacer with the emonTx or emonTH still running at 433.00 – and if you see a drop in signal strength or better still, it fails, then it’s likely it has recognised the value; alternatively, if your emonTx is running on 433.92, does it receive when it didn’t, and with a better signal strength if it did? But knowing OEM, I think it’s unlikely and 433 is simply a token that is recognised deep in the code somewhere and used to set the three frequency registers in the RFM69CW itself.
I think you need custom software in your RFM69Pi. The ‘standard’ code is here: RFM2Pi/firmware/emonBase_rfm69pi/emonBase_rfm69pi.ino at master · openenergymonitor/RFM2Pi · GitHub and it looks as if it uses the original LPL RFM69 library.
Yes. It is from a emon base I bought in 2019. It is now fitted to a RPi5.
I think so. The register values themselves appear to be defined in the RFM69 library, which is called from the RFM69Pi sketch you identified above. Further, with respect to using 433.92 MHz, it only appears to be defined in the RFM69_LPL.h and not the RFM69.h library…
I agree. Without having the emonBase RFM69Pi firmware, lowpowerlabs file available in the emonCMS update page updated to have 433.92Mz included as a frequency option, I do not think I will be able to move my system to a ‘legal’ frequency. I would try using one of the newer RFM69SPI modules, but the shop does not appear to have any stock.
I think you’ve missed a trick. You can feed it your own file - but the UI to do it is anything but clear.
When you click and select rfm69pi, firmware emonBase RFM69Pi.... V1.1.1 pops up and appears to be the only choice - and indeed that’s what gets uploaded when you click
“Update firmware”. DON’T CLICK IT.
Instead, navigate using the “Browse” button on the next line to a .hex file you’ve created on, or uploaded, to the RPi5 and (here’s the awful bit of UI) it will upload immediately as soon as it is selected, probably unseen off the bottom of your screen. No confirmation is needed or allowed.
So that’s how to put a new sketch into your RFM6Pi.
It got me fooled totally and completely, Angus delved into emonCMS and found what was happening, because I was uploading the emonPi3 .bin file and promptly overwriting it with the default file when I clicked “Update firmware”.
I think you’ll need to ask @TrystanLea about compiling the sketch for the RFM69Pi - I have a hazy memory from years ago that something different in the bootloader area is required - but I can’t remember.
I’ve looked at the emonBase_rfm69pi sketch and the bootloader question is answered in a comment at the top of the file.
I have converted it to use the OEM RFM69_LPL library and to accept 433.92 MHz as a frequency option and the default, and it compiles. I have the emonTx V2 with an RFM69CW, which I used to develop emonLibCM, so I can write a transmitter sketch for this (effectively a copy using all the same settings except it will transmit rather than receive) and check the frequency can be selected, then I can run the sketch ‘as is’ as a receiver using the emonTx V3.4 and your sketch to send the data, and find out what does or doesn’t work.
That’s the plan, how far I get and when I can’t promise.
It sounds like a significant amount of work, and I am very grateful for your support with this. I described what you are proposing to do to my wife this morning, and she agreed and suggested that you might enjoy these types of problems. 
I think I have a viable LPL based firmware configuration for the three items now (RFM69Pi, emonT2, and emonTx3.4) working on 433MHz. Even if you get examples of all the components working in your test setup, I anticipate the need to go through another round of testing at my end before changing over.
If I remember correctly, it was the testing phase with the emonTh2, which identified that the current published firmware would not compile in the JeeLib Classic configuration. This was related to the use of the 433_92MHZ defined values in the sketch and those values not being defined in the JeeLib library. So, any work to update libraries to work with 433.92 MHz should also consider the use of the JeeLib library as well.
I am away for the next couple of days and will not be able to send an update to the emonTx3.4 sketch until i retrun, but the one you have should show any problems in the mean time.