Integrating EmonTx V4 with EmonBase

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.

Robert.Wall · 2024-02-05T20:06:13.589Z

A_H:

I’m using an emonBase

This makes a big difference. I wish you had used the correct description earlier. I’ve changed the title of the thread accordingly.

You must presume much of the information and suggestions we’ve made are likely to be inapplicable or wrong, e.g. there is now no concerns about running Continuous Monitoring, because the emonBase is incapable of monitoring power and energy.

A_H · 2024-02-05T20:20:54.177Z

Robert.Wall:

because the emonBase is incapable of monitoring power and energy.

What do you mean exactly? Can the emonBase + RFM69Pi module not interface with the emonTx V4?

Robert.Wall · 2024-02-05T20:29:23.048Z

Let’s start again.

Look at the radio module sitting on your Raspberry Pi, look at Docs → Learn → Electricity Monitoring → Networking → Networking → RFM12B & RFM69CW Wireless Transceiver Modules and identify the radio module you have, either an RFM12B or an RFM69CW. I would expect it to be the latter but it’s not a given. This will determine the software you need to load into the processor on the RFM**Pi on which the radio module sits. While you’re there, make a note of the frequency, it should be 433 MHz.

Go into emonCMS → Admin → Update →UPDATE FIRMWARE ONLY and select RFM12Pi or RFM69Pi according to the type you have. This should give you “emonBase RFM69Pi firmware…” (or RFM12B), and update. If it’s an RFM12B you have, you must unfortunately downgrade your emonTx4 back to the Classic JeeLib software, because as I wrote above, the RFM12B can’t use the LPL library.

Robert.Wall · 2024-02-05T20:34:46.591Z

A_H:

What do you mean exactly?

There is no ADC in a Raspberry Pi. It is physically unable to measure voltage or current, from which the power and energy values are calculated. If you add on the GPIO connector (instead of your RFM12Pi or RFM69Pi) what is effectively either a 2-channel emonTx V3 or a 6-channel emonTx4, you then have an emonPi or an emonPi2. Which is how you misled us and I told you the wrong software to load.