Integrating EmonTx V4 with EmonBase

Robert.Wall · 2024-02-01T20:19:16.944Z

Welcome, Alan, to the OEM forum.

If your emonPi dates from the time you got your emonTx V3, then it’s going to be using JeeLib ‘Classic’ radio protocol.

Your emonTx 4 uses the LoPowerLabs protocol - and naturally, they’re not compatible. If you’ve got no other OEM devices. you need to change the emonPi to use RFM69 LowPowerLabs.

I can’t immediately see another reason for it not working.

A_H · 2024-02-01T20:50:30.270Z

Hi Robert. Thanks! Is there a quick way to check the version that the EmonPi and EmonTx are currently running? (So I can ensure they’re both aligned with the classic version)

A_H · 2024-02-01T21:10:06.919Z

This is what I see when I connect USB from Pi to EmonTx:

OpenEnergyMonitor.org
2024-02-01 21:07:48,985 DEBUG USB0 No EEPROM config
2024-02-01 21:07:49,088 DEBUG USB0 Settings:
2024-02-01 21:07:49,192 DEBUG USB0 Band 433 MHz, Group 210, Node 17, 7 dBm
2024-02-01 21:07:49,294 DEBUG USB0 Calibration:
2024-02-01 21:07:49,397 DEBUG USB0 vCal = 807.86
2024-02-01 21:07:49,499 DEBUG USB0 assumedV = 240.00
2024-02-01 21:07:49,602 DEBUG USB0 i1Cal = 300.30
2024-02-01 21:07:49,704 DEBUG USB0 i1Lead = 3.20
2024-02-01 21:07:49,806 DEBUG USB0 i2Cal = 150.15
2024-02-01 21:07:49,908 DEBUG USB0 i2Lead = 3.20
2024-02-01 21:07:50,010 DEBUG USB0 i3Cal = 150.15
2024-02-01 21:07:50,112 DEBUG USB0 i3Lead = 3.20
2024-02-01 21:07:50,214 DEBUG USB0 i4Cal = 60.06
2024-02-01 21:07:50,317 DEBUG USB0 i4Lead = 3.20
2024-02-01 21:07:50,419 DEBUG USB0 i5Cal = 60.06
2024-02-01 21:07:50,521 DEBUG USB0 i5Lead = 3.20
2024-02-01 21:07:50,623 DEBUG USB0 i6Cal = 60.06
2024-02-01 21:07:50,726 DEBUG USB0 i6Lead = 3.20
2024-02-01 21:07:50,828 DEBUG USB0 datalog = 9.80
2024-02-01 21:07:50,930 DEBUG USB0 pulses = 1
2024-02-01 21:07:51,032 DEBUG USB0 pulse period = 100
2024-02-01 21:07:51,134 DEBUG USB0 RF on
2024-02-01 21:07:51,242 DEBUG USB0 temp_enable = 1
2024-02-01 21:07:51,344 DEBUG USB0 JSON Format Off
2024-02-01 21:07:51,448 DEBUG USB0 RFM69CW Freq: 433MHz Group: 210 Node: 17
2024-02-01 21:07:51,551 DEBUG USB0 RadioFormat: LowPowerLabs
2024-02-01 21:07:51,655 DEBUG USB0 Reference voltage calibration: 1.0263
2024-02-01 21:07:51,759 DEBUG USB0 Temperature Sensors found = 0 of 3
2024-02-01 21:07:51,862 DEBUG USB0 Temperature measurement is enabled.
2024-02-01 21:07:52,068 DEBUG USB0 No temperature sensors detected, disabling temperature
2024-02-01 21:07:52,172 DEBUG USB0 AC present - Real Power calc enabled
2024-02-01 21:07:52,280 DEBUG USB0 ---------------------------------------------------------------------
2024-02-01 21:07:53,281 DEBUG USB0 Config format: new
2024-02-01 21:07:55,383 DEBUG USB0 ---------------------------------------------------------------------
2024-02-01 21:08:01,436 DEBUG USB0 40 NEW FRAME : MSG:2,Vrms:195.47,P1:-1,P2:0,P3:0,P4:0,P5:0,P6:0,E1:0,E2:0,E3:0,E4:0,E5:0,E6:0,pulse:0
2024-02-01 21:08:01,436 DEBUG USB0 40 Timestamp : 1706821681.435327
2024-02-01 21:08:01,437 DEBUG USB0 40 From Node : emonTx4
2024-02-01 21:08:01,437 DEBUG USB0 40 Values : [2, 195.47, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
2024-02-01 21:08:01,438 DEBUG USB0 40 Sent to channel(start)’ : ToEmonCMS
2024-02-01 21:08:01,438 DEBUG USB0 40 Sent to channel(end)’ : ToEmonCMS
2024-02-01 21:08:01,549 INFO MQTT Connecting to MQTT Server
2024-02-01 21:08:01,607 DEBUG emoncmsorg Buffer size: 1
2024-02-01 21:08:01,652 INFO MQTT connection status: Connection successful
2024-02-01 21:08:01,653 DEBUG MQTT CONACK => Return code: 0
2024-02-01 21:08:01,755 INFO MQTT on_subscribe
2024-02-01 21:08:11,208 DEBUG USB0 41 NEW FRAME : MSG:3,Vrms:195.44,P1:0,P2:1,P3:0,P4:0,P5:0,P6:0,E1:0,E2:0,E3:0,E4:0,E5:0,E6:0,pulse:0
2024-02-01 21:08:11,209 DEBUG USB0 41 Timestamp : 1706821691.208169
2024-02-01 21:08:11,210 DEBUG USB0 41 From Node : emonTx4
2024-02-01 21:08:11,210 DEBUG USB0 41 Values : [3, 195.44, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.0]
2024-02-01 21:08:11,211 DEBUG USB0 41 Sent to channel(start)’ : ToEmonCMS
2024-02-01 21:08:11,211 DEBUG USB0 41 Sent to channel(end)’ : ToEmonCMS
2024-02-01 21:08:11,502 DEBUG MQTT Publishing: emon/emonTx4/MSG 3
2024-02-01 21:08:11,503 DEBUG MQTT Publishing: emon/emonTx4/Vrms 195.44
2024-02-01 21:08:11,504 DEBUG MQTT Publishing: emon/emonTx4/P1 0
2024-02-01 21:08:11,506 DEBUG MQTT Publishing: emon/emonTx4/P2 1
2024-02-01 21:08:11,507 DEBUG MQTT Publishing: emon/emonTx4/P3 0
2024-02-01 21:08:11,508 DEBUG MQTT Publishing: emon/emonTx4/P4 0
2024-02-01 21:08:11,509 DEBUG MQTT Publishing: emon/emonTx4/P5 0
2024-02-01 21:08:11,511 DEBUG MQTT Publishing: emon/emonTx4/P6 0
2024-02-01 21:08:11,512 DEBUG MQTT Publishing: emon/emonTx4/E1 0
2024-02-01 21:08:11,513 DEBUG MQTT Publishing: emon/emonTx4/E2 0
2024-02-01 21:08:11,515 DEBUG MQTT Publishing: emon/emonTx4/E3 0
2024-02-01 21:08:11,516 DEBUG MQTT Publishing: emon/emonTx4/E4 0
2024-02-01 21:08:11,517 DEBUG MQTT Publishing: emon/emonTx4/E5 0
2024-02-01 21:08:11,518 DEBUG MQTT Publishing: emon/emonTx4/E6 0
2024-02-01 21:08:11,519 DEBUG MQTT Publishing: emon/emonTx4/pulse 0
2024-02-01 21:08:11,520 DEBUG MQTT Publishing: emon/emonTx4/missed 0
2024-02-01 21:08:11,522 DEBUG MQTT Publishing: emon/emonTx4/missedprc 0.0
2024-02-01 21:08:11,523 INFO MQTT Publishing ‘node’ formatted msg
2024-02-01 21:08:11,523 DEBUG MQTT Publishing: emonhub/rx/emonTx4/values 3,195.44,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0.0
2024-02-01 21:08:20,988 DEBUG USB0 42 NEW FRAME : MSG:4,Vrms:195.44,P1:0,P2:1,P3:0,P4:0,P5:0,P6:0,E1:0,E2:0,E3:0,E4:0,E5:0,E6:0,pulse:0
2024-02-01 21:08:20,989 DEBUG USB0 42 Timestamp : 1706821700.988244
2024-02-01 21:08:20,990 DEBUG USB0 42 From Node : emonTx4
2024-02-01 21:08:20,990 DEBUG USB0 42 Values : [4, 195.44, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.0]
2024-02-01 21:08:20,991 DEBUG USB0 42 Sent to channel(start)’ : ToEmonCMS
2024-02-01 21:08:20,992 DEBUG USB0 42 Sent to channel(end)’ : ToEmonCMS
2024-02-01 21:08:21,213 DEBUG MQTT Publishing: emon/emonTx4/MSG 4
2024-02-01 21:08:21,214 DEBUG MQTT Publishing: emon/emonTx4/Vrms 195.44
2024-02-01 21:08:21,215 DEBUG MQTT Publishing: emon/emonTx4/P1 0
2024-02-01 21:08:21,216 DEBUG MQTT Publishing: emon/emonTx4/P2 1
2024-02-01 21:08:21,217 DEBUG MQTT Publishing: emon/emonTx4/P3 0
2024-02-01 21:08:21,218 DEBUG MQTT Publishing: emon/emonTx4/P4 0
2024-02-01 21:08:21,219 DEBUG MQTT Publishing: emon/emonTx4/P5 0
2024-02-01 21:08:21,221 DEBUG MQTT Publishing: emon/emonTx4/P6 0
2024-02-01 21:08:21,222 DEBUG MQTT Publishing: emon/emonTx4/E1 0
2024-02-01 21:08:21,223 DEBUG MQTT Publishing: emon/emonTx4/E2 0
2024-02-01 21:08:21,224 DEBUG MQTT Publishing: emon/emonTx4/E3 0
2024-02-01 21:08:21,225 DEBUG MQTT Publishing: emon/emonTx4/E4 0
2024-02-01 21:08:21,226 DEBUG MQTT Publishing: emon/emonTx4/E5 0
2024-02-01 21:08:21,227 DEBUG MQTT Publishing: emon/emonTx4/E6 0
2024-02-01 21:08:21,228 DEBUG MQTT Publishing: emon/emonTx4/pulse 0
2024-02-01 21:08:21,229 DEBUG MQTT Publishing: emon/emonTx4/missed 0
2024-02-01 21:08:21,230 DEBUG MQTT Publishing: emon/emonTx4/missedprc 0.0
2024-02-01 21:08:21,231 INFO MQTT Publishing ‘node’ formatted msg
2024-02-01 21:08:21,232 DEBUG MQTT Publishing: emonhub/rx/emonTx4/values 4,195.44,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0.0

Robert.Wall · 2024-02-01T21:29:17.246Z

Why the ‘classic’ version? As far as I know, no decision has been made when, or indeed whether, JeeLib will no longer be supported. However I anticipate this will happen at some point. I believe there’s little active development in JeeLib, whereas LPL appears to be actively supported by its own group, which I believe was one consideration when the decision to change was made.

If you have no other OEM kit, I strongly advise you to convert to LPL. This is the ‘native’ protocol the emonTx4 is shipped with, and you can update the emonPi via Setup → Admin → update.

A_H · 2024-02-01T21:59:25.906Z

I had changed the Tx V4 to classic after Trystan suggested rolling back to that (in case the Pi was running ‘older jeelib firmware’). I have reverted back to LPL.

When we say the Pi ‘firmware’, is there a way check just that? From Admin → System Info → EmonCMS → Components:

Is there an indication from that that the Pi is running the correct firmware to interface with the LPL firmare on the Tx V4?

A_H · 2024-02-04T12:24:43.639Z

A_H:

RFM2Pi v1.4.2

Anyone out there know if this is how I indetify that the EmonPi is running the ‘low power’ firmware (so I can interface with the EmonTx V4)?

I’m not running any other OEM equipment, just Pi + EmonTx V4.

Robert.Wall · 2024-02-04T13:30:54.787Z

If anyone has a record of what software is supplied and when, it will be ‘The Shop’ hello@openenergymonitor.zendesk.com
I’m afraid I gave up long ago trying to find my way around Github, I’ve never found any record there of when different versions have been published and only exceptionally rarely any indication of which and when is the “shipped” version for the hardware.

I have suggested that now it’s become possible to have incompatible libraries, the version used by both transmitting node and receiving node should be part of the data that’s printed at startup, but that seems to have fallen on deaf (or “too busy”) ears.

As far as I’m aware, the only sure way is to upload known pieces of software (which use the same library - I suggest LPL) to both the emonTx4 and the emonPi’s front end, where the radio receiver lives.

A_H · 2024-02-04T19:15:42.146Z

Thanks Robert, I really appreciate the help here… it’s not an inexpensive system, so I’m quite surprised by the lack of ‘official’ help. I’ve been trying since early January to resolve this with the team, but there has been very little support.

I’ve upgraded the EmonTx to LPL, and I’m trying to update the EmonPi via Admin → Update.

I’m connected locally (via WiFi) to the Pi, and on the update page I’m using the following settings:

UPDATE FIRMWARE ONLY

Select your hardware type and firmware version
Select port: ttyAMA0
Hardware: EmonPi
Radio Format: RFM69 LowPowerLabs
Firmware: emonPi continuous sampling firmware, lowpowerlabs, v1.1.4

But I’m getting sync and broken pipe errors:

avrdude-original: stk500_getsync() attempt 10 of 10: not in sync: resp=0xc7
avrdude-original done. Thank you.
strace: |autoreset: Broken pipe
ERROR: Not in sync
Restarting EmonHub

Any ideas what could be wrong here…?

emonpiRelease: emonSD-24Jul20

Robert.Wall · 2024-02-04T21:52:26.306Z

A_H:

Any ideas what could be wrong here…?

Unfortunately that error message only tells us that avrdude couldn’t communicate with the “emon” part of the emonPi. It gives us no clue as to why - it could one of many things.

But one slightly worrying thing is the emonSD version - we normally recommend staying up-to-date with the latest release. I don’t think this is the cause of the problem, however; as far as I know, the protocol for uploading the code has not changed. It’s probably worth updating emonCMS in any case.

rupert · 2024-02-05T01:14:21.288Z

@A_H @TrystanLea Some thoughts from my experiences which may help. Various changes that have happened during/since the emonTx4 launch may be causing your problems.

You need to have both the emonTx4 and the emonPi using the same radio format, either Jeelib or LPL. LPL is the latest format and is necessary for continuous monitoring (CM) on the emonPi (i.e. emonPi continuous sampling firmware, lowpowerlabs, v1.1.4).

If you have an emonPI (not an emonPi2), you might want to look at:

Updating an emonPi to emonPi_CM
and
Should I update Emon Pi firmware to CM, and how?
which may help.

In particular, from the first:

Updating an emonPi to emonPi_CM emonPi

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?

I don’t know if this is causing your firmware update problem … You may wish to try updating your emonPi scripts … I don’t know if this would cause more problems!

And assuming that you have the emonPi CM LPL firmware installed, from the second

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

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”. …

It looks like you need to update your emonhub config file for the RFM2Pi (i.e. emonPi) interfacer, and for node 5 (emonPi)

Hope something here helps!

A_H · 2024-02-05T12:16:47.399Z

Thanks for the inputs Robert and Rupert.

@rupert - I can confirm that it’s an emonPi I’m using here.

I’ve updated the config file (interfacers and node for emonPi), emonCMS, and emonScripts (it was already up to date). The baud rate was definitely wrong in the interfacer. But, I still don’t see the radio data inputs.

So, I believe the issue is, as Rupert suggested, that the Pi cannot understand the V1.1.4 data.

One other warning in the update log for emonPi is:

avrdude-original: Using autoreset DTR on GPIO Pin 7
avrdude-original: stk500_recv(): programmer is not responding

I think the next step is to bring emonSD up to date…

Can either of you suggest the most reliable way to do this…?

Robert.Wall · 2024-02-05T12:42:47.420Z

All I can say is, for the emonPi I used when developing emonLibDB, I started with the SD card image downloaded. I tried the RFM2Pi update to that yesterday evening for you, and it went through without any problem. This was really my grounds for suggesting you update your emonCMS.

But starting with a download didn’t give me a problem with historic data because there wasn’t any! In your case, if you have data that’s precious, you need to back it up, then restore it when the new image is working.

Otherwise, I suggest doing the full update via the Admin menu. This has never failed for me so far. I’d still back up existing data unless you don’t mind risking losing it.

rupert · 2024-02-05T14:51:06.153Z

Integrating EmonTx V4 with EmonPi Hardware

Anyone out there know if this is how I indetify that the EmonPi is running the ‘low power’ firmware (so I can interface with the EmonTx V4)? I’m not running any other OEM equipment, just Pi + EmonTx V4.

This seems to work on my emonPi, no guarantees though

for emonPiCM LPL check Go to:
setup/admin/serial monitor
next to start button, choose ttyAMA0 (port), choose 115200 (baud rate)
click Stop EmonHub. terminal response:
service-runner trigger sent for '/var/www/emoncms/Modules/admin/../../scripts/service-action.sh emonhub.service stop'
click Start (starting serial comms resets the atmega328 and it sends the start up messages). terminal response:

emonPiCM V1.1.4
OpenEnergyMonitor.org
Radio format: LowPowerLabs
LCD found i2c 0x27

and then it sends the measurement results:

OK 14 193 225 1 0 147 94 137 0 0 0 0 0 0 0 0 0 138 0 151 17 1 0 10 0 0 0 201 255 255 255 134 0 0 0 17 93 0 0 34 144 0 0 151 4 126 4 138 4 198 16 1 0 (-86)
OK 15 55 16 1 0 204 96 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 1 0 0 0 (-45)

also you can interrupt the results and send the version command (amongst others):
in ‘enter command’ box type v (version command)
click Send. terminal response:

emonPi CM V1.1.4

to finish:
click Stop. terminal response:

serialmonitor stop command sent
Serialmonitor service is not running, click start to start!

click Start EmonHub. terminal response:

service-runner trigger sent for '/var/www/emoncms/Modules/admin/../../scripts/service-action.sh emonhub.service start'

for emonPi_DS_jeelib_classic check (I don’t have this so can’t try it)
as above but choose 38400 (baud rate)
start up message (from looking at code):

emonPi V2.93
OpenEnergyMonitor.org
startup...

I’m guessing from the code that the version command v should work and give:
[emonPi.2.93]

Hope this helps (and works!)

A_H · 2024-02-05T15:39:07.489Z

@Robert.Wall - I don’t have data that I need to keep, so ran a full update, and I still see the same issue - is this a clearer indicatiom that the emonPi SW is the main cause of interface disagreement?

@rupert - I can repeatably start/stop the serial monitor etc., but it only works with the ‘older’ baud rate of 38400. When I start it, I see this:

service-runner trigger sent for '/var/www/emoncms/scripts/serialmonitor/start.sh 38400 /dev/ttyAMA0'
Loading configuration, list (l) command sent:

[RF12demo.13] E i5 g210 @ 433 MHz q1

Available commands:
  <nn> i     - set node ID (standard node ids are 1..30)
  <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
  <nnnn> o   - change frequency offset within the band (default 1600)
               96..3903 is the range supported by the RFM12B
  <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
  <n> c      - set collect mode (advanced, normally 0)
  t          - broadcast max-size test packet, request ack
  ...,<nn> a - send data packet to node <nn>, request ack
  ...,<nn> s - send data packet to node <nn>, no ack
  <n> q      - set quiet mode (1 = don't report bad packets)
  <n> x      - set reporting format (0: decimal, 1: hex, 2: hex+ascii)
  123 z      - total power down, needs a reset to start up again
Remote control commands:
  <hchi>,<hclo>,<addr>,<cmd> f     - FS20 command (868 MHz)
  <addr>,<dev>,<on> k              - KAKU command (433 MHz)
Current configuration:
 E i5 g210 @ 433 MHz q1

So… is that ‘RF12demo.13’ version what I’m running on the emonPi…? And that’s older than anything you expected to see?

Robert.Wall · 2024-02-05T15:49:16.880Z

It looks like you might need to change your emonPi’s baud rate in emonhub.conf.

It’s here:

[interfacers]
### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400                        # 9600 for old RFM12Pi
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,
...

rupert · 2024-02-05T16:17:06.361Z

Well, according to the Docs,
https://docs.openenergymonitor.org/emonpi/firmware.html
the current firmware versions for the emonPi are:
emonPi_CM (uses 115200 baud rate on ttyAMA0 port to talk to the Pi) which is the LPL version,
and emonPi_DS_jeelib_classic (uses 38400 baud rate)

Looking in github at the emonPi firmware

github.com

//github.com/openenergymonitor/emonpi/tree/master/firmware

the nearest candidate to what you have is in the archive folder (!) and is

RF12demo_RFM68CW_Test

which has a startup message of [RF12demo.12] from the code. I can’t obviously see anything that has your [RF12demo.13] message. It would seem that you have pretty old Jeelib firmware in your atmega328, and it’s not compatible with the LPL format that you put in the emonTx4. Out of interest, when did you get your emonPi?

I don’t know why you can’t program your atmega328 with the LPL firmware, after your full update.

The only thing I have noticed is that the RF12demo_RFM68CW_Test has an option for an atTiny84 processor instead of an atmega328, but I don’t think you have that as the startup message would likely be similar to [RF12demo.12 Tiny]

As a last effort, you could try flashing a new SD card to try in the emonPi, using
https://docs.openenergymonitor.org/emonsd/download.html
You’ll have to remove the end cover at the the button end of the Pi to change the card.
The see if you can program the atmega328 with the LPL firmware.

rupert · 2024-02-05T16:45:14.897Z

One last question to make sure we’re talking about the same thing - you have an emonPi (with LCD display, button, silver case, two CT and one voltage inputs) and not an emonBase (NO LCD display, button, silver case, two CT or voltage inputs)?

Robert.Wall · 2024-02-05T17:07:18.331Z

As far as I know, there’s never been an emonPi with a RFM12B radio in it. But if all else fails, it’s worth checking, there are pictures in Docs to identify the different modules. An RFM12B cannot work with LPL, nor can your emonPi do CM and receive data by radio with an RFM12B or when using Classic JeeLib – not without an horrendous error rate. It needs the RFM69CW to process the radio messages itself to give the processor enough time to run CM.

@A_H
If 38400 baud in emonhub.conf doesn’t work (restart emonHub each time you change it), start at 9600 baud and try every value upwards as far as 115200. Watch the log as emonHub starts - it will immediately error if it’s not talking, or you’ll see it respond when it does.

rupert · 2024-02-05T17:15:55.467Z

The RF12demo_RFM68CW_Test code has an option for ‘RF69’ , so hopefully Alan’s emonPi has a RFM69 in it.

A_H · 2024-02-05T18:44:52.430Z

@rupert - I should have clearly stated this earlier - I’m using an emonBase (no LCD etc.). I didn’t realise the community to referred to that variant as emonBase only (rather than emonPi). Does this change things significantly for this issue?

I checked back in my OEM account and I ordered the emonbase in March 2019, and I ordered it with the additional ‘RaspberryPi RF add-on: RFM69Pi - 433Mhz’. I flashed/upgraded the SD card once since then. And, this radio module was working with the emonTx V3 originally.