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:
If anyone has a record of what software is supplied and when, it will be ‘The Shop’ [email protected]
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.
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
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.
@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:
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
It looks like you need to update your emonhub config file for the RFM2Pi (i.e. emonPi) interfacer, and for node 5 (emonPi)
@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…?
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.
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
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]
@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?
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
the nearest candidate to what you have is in the archive folder (!) and is
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.
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)?
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 - 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.
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.
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.
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.
